Now that the basic shell is done, I think this will be the best way to post files in the future, in the Hints & Tips thread.
For everything to work correctly you will need to have the same game-shell I am using so if you haven't got that, it's in the Blitz tutorial starter thread. You need to download the file Part3.zip.

Although you can use Blitz to produce just about any type of program/tool/app you want, games seem to be the most popular. But what is a game? Is the train Sim I'm working on a game?
Not really, but it uses exactly the same commands and functions as a game would, so although these hints and tips are will be of use to "would be game writers" they will also be useful in any situation.

One drawback with games writing, is the constant testing/replaying that needs to be done, it becomes a pain in the neck sometimes, trying to get things to work as you would wish
A company like Electronic Arts will have someone just producing heads, someone else doing the torso etc,
someone else building the game levels, a team of two or three artists and on top of all that another two or three people doing the coding. All of whom will be accomplished model builders, artists and coders.
If they weren't they wouldn't have got the job. Even so it can take 2 to 3 years to produce a game.

But don't let this put you off, the enjoyment comes, I find, from achieving very simple things and as you go along you get better and better. I am still amazed at some of the things people achieve over on the Blitz site and I'm usually the first in line to say, "how on earth did you do that". More often than not they will tell you.

I find it better to produce just one level and then move on to something else, just for a change. If you can ever get a team of two or three people together then go for a full blown game.

My main enjoyment comes from model building and texturing, anything that takes me away from that I'm not so keen on. So my coding skills are somewhat lacking and working with file formats is like watching paint dry, to me anyway.

Anyway on with the hints and tips......

Collision Detection and the HideEntity...ShowEntity commands.

1) First Unzip the Collisions.zip file into your LevelOne folder and you will have a folder called CollisionFiles.
2) From this copy the two files.. Key.x and Keys.bmp to the model folder of your LevelOne folder
3) The Collision-1.bb file needs to be in your LevelOne folder and just drag or copy the Sounds folder also into your LevelOne folder

Now run the file Collision-1.bb.... your task is to find the four keys Red,Green,Blue and yellow...not very difficult because there aren't many places to hide things at the moment.
Only one key at a time is available to you but as you find one key another will appeare somewhere else in the scene, go and find it.
I've included some sound this time and a message every time you find a key. The keys are just an example, you would use just the same routine for health/ammo pick ups etc.

I've documented the code so you should be able to work things out. A new function has appeared called CollisionCheck( ) , take a look

The collisions are detected between the Campivot entity the scene and the four keys. The campivot entity is given a radius with the command...EntityRadius Campivot, 2.9. Try changing this to 3.5 and see what happens.
Imagine this radius as an invisible ball around the camera pivot...when this comes into contact with any object you you have assigned a collision type to Blitz will detect this.

A collision type is something like this....Camera_col = 1......Scene_col = 2 etc.....

From this list of collision types you make another list as follows...
Collisions Camera_col,Scene_col,2,3

When you load your scene you assign the appropriate collision type to the scene as follows...
EntityType scene,scene_col

and with the camera pivot
EntityType Campivot, Camera_col

Thats all you need to do, Blitz will now detect the collision between the camera pivot and the scene and give you a
rolling collision when you walk into a wall or up a ramp.

If you look in the CollisionCheck( ) function this is how you detect the collision with the keys...

If EntityCollided( Campivot,RedK_col)
do whatever
End if

When I loaded the keys, the green, blue and yellow keys where hidden with the command... HideEntity
When you pick up the red key, all that is needed is to include the following line in the above IF/Then statemant
ShowEntity GreenKey
You do the same thing every time a key is picked up...show the next key

Another new command is CopyEntity...
I loaded the file Key.x and hid it with HideEntity (this key has a greyscale texture)
To produce the four Keys all you have to do is....

RedKey=CopyEntity(Key)
Entitycolor RedKey, 255,10,10

You do this for each key in turn. This way you only need to build and texture one key in 3DC, then copy and colour it in Blitz as many times as you like.

Also new are the LoadSound and PlaySound commands and see if you can work out how the messages are printed to the screen.

Thats it for now, if you have any problems or don't understand any of the above let me know.

Bazza

Collisions.zip (13 Kb, 34 downloads)

Nice job with this. I definetly want to try using that program to make games. One problem, though. When you free the key entities after a collision, the code that controls the rotation of that key gets messed up, because, I guess, the entity that might be rotated no longer exists. I fixed it myself by removing the FreeEntity in each collision, but then the memory is still being taken up.

Yes, Polybuilder was having the same problem but it works perfectly with the full version of Blitz.

This is where I'm going to have a problem, I don't know which commands and features are omitted from the demo.
Also I still don't know what the maximume .bb file size is allowed with the demo. Does it mention this anywhere?

Actually I wouldn't normally do a routine like this in this way, but I didn't want to complicate the code any further.

After creating all the keys I would normally do something like this....

Key=RedKey

Then in the collision detection for the red key after the FreeEntity command I would put...
Key = GreenKey

That way you only need one line of code to turn all the keys as they appeare ie....

If EntityVisible(Campivot,Key) then TurnEntity Key, 0,5,0

Again I don't know if something like this will work with the demo.

I do make sure everything is working OK before I zip the file, so if anything like this happens again let me know and I will try and sort out a 'work round'

This doesn't help with the tutorial though.

Bazza

This message has been edited. Last edited by: Bazza,

Variables....
This is something I should have covered at the very begining, especially Global variables, so here it is...

Blitz has two types of variables Global and Local.
If you want to use a variable within your main program/loop And within a function you must make the variable Global....ie...

Global, Campivot

You will then be able to access the variable from within your functions. If you remove the above line from the any of the GameShell.bb files, go into de-bug mode and run the programm you will get an error something like....
"Entity does not exist"

This is because the function UPDATE_GAME is looking for the variable Campivot when you press an arrow key, but because it hasn't been made Global it can't be accessed by the function, so you get the error.

This will catch you out time and time again and you don't always get an error message. So if you are having problems with things not working as they should, check this out first.

A Local variable can be used anywhere, you don't have to do anything to make a variable local, it is so by default.
You could do something like this in your set-up, main loop, functions etc......

For n = 0 to 9
Print "Hello World"
Next

The variable 'n' isn't Global so you couln't use it to pass information to other parts of your programm, but you can use a local variable " on the fly " as you wish.

And one other that will catch you out is fogetting to make a variable floating point. If you want to perform some kind of floating point operation on a variable you must use the # sign when you define the variable..ie....

a# = 2.6

Once you have defined 'a' to be floating point with the # sign you can just do this...
a = 3.5
You don't have to use the # sign again, but I find it best to do so as it reminds you the variable is floating point.

Hope this makes sense.

Bazza

To demonstrate the variables hints and tips, here's a fade in/fade out routine.

It's sort of a Dr.Who Tardis thingie, that continually rotates, fades away and then re-appears. There isn't any collision detection this time, thats for you to do.
I've also added an ambient wind sound and looped it
And a little exersize...when it's full visible try and make it stay that way for 5 seconds before it fades again.

Be careful with these sound files, I usually get them off the net, so some could be copyright, you never know.
So change them to make sure, then you will be ok to use them.

1) First Unzip the DocterWho.zip file into your LevelOne folder and you will have a folder called FadeFiles.
2) From this copy the two files.... Tardis2.x and Tardis.jpg to the model folder of your LevelOne folder
3) The DrWho.bb file needs to be in your LevelOne folder
4) The Wind2.wav file needs to be in the sound folder

First I set up two variables and made them both Global.......Fade#.... and Fadeflag...

The Fade# variable needed to be floating point, it adjusts the alpha level of the Tardis between 0 and 1
in steps of .01

The Fadeflag variable is set to either 1 or 0......0 = visible(full alpha) 1 = Invisible (zero aplha)

When the alpha level of the tardis reaches zero using the Fade# variable the Fadeflag is set to 1
Likewise when it reaches 1 it is set to zero.
You can now detect wether the Tardis should be faded in or out, if its 0 we fade it out, if it =1 we fade it in.

I've put the code in the UPDATE_GAME function but if you were writting it into a game it would be best to have it's own function.

Have a look at the code, it's quite an easy one to understand but at the same time looks quite effective.

You do have to find the Tardis first of course.

Let me know if ther are any problems.

Bazza

DocterWho.zip (32 Kb, 36 downloads)

Weapon pick ups........

This is very similar to the keys routine so it should be easy to follow. I've changed the lighting a bit to make it a bit more sinister, and if you load in the wind sound this should add to the effect.
I've unwrapped the shotgun so you can produce your own artwork if you wish but I would make a copy of the original file.... SgunSkin.bmp first.
I've had to reduce the colours to 256 to keep within the 80k forum limit, so I,m sure you can improve on my effort.

Use the shotgun model and texture as you wish. BUT again, be careful with the pick up weapon sound, I don't know where it originated from, so change it at some point.

First the files.......
1) First Unzip the WeaponsOne.zip file into your LevelOne folder and you will have a folder called WeaponFiles.
2) From this copy the two files.... Shotgun.x and SgunSkin.bmp to the model folder of your LevelOne folder
3) The Shotgun1.bb file needs to be in your LevelOne folder
4) The Pickup.wav file needs to be in the sound folder.

This routine lets you pick up the shotgun, (a bit like the keys), prints a message to the player and positions the shotgun in front of the camera ready for use.

I've also given the shotgun a "hunting" motion when you move forward and backward. I'ts in the function Move_Gun. I wouldn't normally do it this way, I would normally do an animation in 3DC, load it into Bltz....then all you need do is to add this to the forward and backward keypress routines.

The flag variable "Shotgun_flag" is used to check if the player has found the weapon...
0 = weapon not found
1= weapon found

It is also used again in the Move_Gun function....when the shotgun is fully back, the flag is set to 2.
The variable "count" does just that,. when it reaches 6 it sets the shotgun_flag back to 1.
Each time it counts it moves the weapon either backward or forward depending on how the variable
shotgun_flag is set.

I suppose next up will be, how to fire the weapon. This can get a bit complicated depending on the type of weapon, the number of bad guys on screen and the amount of bullets flying around.
All have to be tested constantly. To do this you have to learn something called TYPES.
It will take me a couple of days to do a tutorial for this so in the meantime have a look in the Samples/Examples folder and see if you can get some idea of how TYPES work.

If you can get a good understanding of Variables, Collisions and Types your 90% home and dry.

So.....go and find the shotgun, if you have any problems let me know.

Bazza

WeaponsOne.zip (39 Kb, 34 downloads)

Types....Data.....Collisions without collision detection....

Up to know things have been fairly straight forward but it's all about to change....
Writting a tutorial on firing weapons and detecting all the collisions is going to be about 2 days work. So here is what I've decided to do....

I've written this demo to show you what you are letting yourselves in for.
It does take quite a bit of getting used to and at times seems utterly confusing... trying to get things to work as you would like, sometimes isn't easy...but if you want to write games.... this is what you have to learn.
You won't find it easy to start with, but if you stick with it you will get the hang of things.
Short demo's are much easier, but even this one has taken about 3 hours work total.

Download the file Doors.zip and take a look...
If you would like me to continue, I will do so, but you will have to let me know. Either post, send me a PM or an e-mail.

1) First Unzip the Doors.zip file into your LevelOne folder and you will have a folder called DoorFiles.
2) From this copy the two files.... Door.x and Tile.bmp to the Model folder of your LevelOne folder
3) The Doors1.bb file needs to be in your LevelOne folder
4) The DoorOpen.wav file needs to be in the sound folder.

Run the Doors1.bb file and take a look... the exits from the main room now have four doors. As you come into contact with each door it will open (I hope), remain open for about 2 seconds and then close. If your quick enough you can have more than one door moving at once.

This is where TYPES come in.....they're the best thing since sliced bread, a bit similar to a STRUCT in C+ (so I'm told).......

TYPES let you have multiple objects moving around the scene at once.You can get and pass information both from them and to them. If you look above the collisions in the Doors1.bb file this is what you will find....

Type Doors
Field Obj...........each door object
Field Rot...........each doors rotation
Field X#............each doors x position
Field Y#............each doors y position
Field Z#............each doors z position
Field state.........each doors state (open or closed)
Field timer.........each doors timer (used to keep the door open)
Field count.........each doors counter
Field doorchnl.....each doors sound channel
End Type

Think of this as a list of variables that EACH door carries, you can have as many Fields (variables} as you wish. The good thing about this is that you only have to set the fields once in a TYPE, no matter how many doors are created.
This really comes into it's own when you have a lagre amount of bullets,aliens etc on screen and you need to keep track of them all.

Look at the code where the doors are created.....the line......dr.doors = New doors
The "dr " at the front of the line is just a prefix for each door, you use this to access each variable ie...

PositionEntity dr\obj, x,y,z

To create the doors I set up a For/Next loop....The data for positioning the doors is just after this loop, one line of data for each door.

The line just before the loop...Restore Doordata......tells Blitz where to look for the next set of data.
Before the data statements is a label .Doordata, this is what we tell Blitz to look at when it reads the rotation and position of each door.

In the Update_game function you will find the code for opening and closing each door. Again it's done by setting up a For/Next loop and checking the state of each door.

This isn't done with collision detection as such...look at the line...

If Entity Distance ( campivot,dr\obj ) < 4

This checks the distance from the camera pivot to each door...if it's less than 4 units the door will open.

This is really the best description I can give on TYPES but you MUST understand them if you want to write games.
I've documented the code the best I can, if your not sure about anything post your question.

And again, If you would like me to continue let me know.

Bazza

Doors.zip (23 Kb, 26 downloads)

Bazza

Please continue. I'm getting the hang of things alot quicker. this time 'round.

Everthing is working, and I understand most of the code. When I do a little changing to the code, things work well and I learn more.

Just keep studying.

James

Pleased you're getting somewhere.

I'll make a start with the weapon firing demo.

Bazza