If you are a new game programmer, and are human, you are likely to have hit a snag in most of your games, and given up. I mean of course, it's difficult to write a whole game from start to finish, but, here's the good news. You dont have to make a game from start to finish!
Here's an example. Lets say you made the new FPS Creator. You havent made a game, OK, but using it, you can through together a quality game that would take one a few days/weeks to hardcode.
The reason for this is because FPS Creator, The 3D Game Maker, and other things use a
Game Engine.
Game Engines come in
two forms.
1 - Graphics engines, sound engines, file I/O, internet access, etc
2 - Object handling, event handing, scripting, etc
DBPro itself isn't just a programming language. It's an engine, controlled by a programming language. If it wasnt for DBP you wouldn't get numbered objects, or object loading at all, or primitives, or sound capabilities (i.e. 3D sounds), etc. But this alone is hard to use. It does make it easier for us, but it's not very specific. It's just a wide range of commands that can be used to make any game you wish.
Now, lets think of the other type of Game Engine. It would be specific to the type of game you want to make (unless it's like T3DGM, but that's hardly usable, lol). For examples sake, lets think of an FPS, since they are relativelly simple.
Your FPS should handle:
- Multiple guns
- Bullets / Shooting
- Enemies
- Levels
- Physics
Other, more general things, could be:
- Dynamic level loading
- Scripting
- INI files
- Scripted entities
- HUD
I'll skip the chit-chat, and go straight to what a good structure might be for this:
FPS -> Guns -> Load gun
-> Delete gun
-> Swapping -> Swapping animation
-> Swap
-> Shooting -> Move bullets -> Hit wall
-> Hit enemy
-> Hit friend
-> Recoil animation
-> Enemies -> AI -> Run
-> Walk
-> Evade
-> Attack
-> Kill
-> Respawn
-> Add enemy
-> Remove enemy
-> Levels -> Load
-> Delete
-> Entities -> Load
-> Delete
-> Run script
-> Stop script
-> HUD -> Show ammo
-> Show rounds
-> Radar -> Track enemy
-> Track friend
Everything at the very right of each list (i.e. FPS -> Shooting -> Move bullets -> Hit Enemy) would be a regular DBP Function/Endfunction. With this kind of design, it is possible to have 100s/1000s of lines of code, but no game. But with ease, you can make something great. Here's one I would make with that particular structure (pseudocode obviously):
Setup
FPS -> Guns -> Load Gun ("GUN1")
FPS -> Guns -> Load Gun ("GUN2")
FPS -> Levels -> Load ("LEVEL1")
For 1 to 10
FPS -> Enemies -> Add enemy
Main Loop
If 1 button
FPS -> Guns -> Swapping -> Swap ("GUN1")
FPS -> Guns -> Swapping -> Swapping animation ("GUN1")
If 2 button
FPS -> Guns -> Swapping -> Swap ("GUN2")
FPS -> Guns -> Swapping -> Swapping animation ("GUN2")
etc...
etc...
etc...
Now you see, with just a few lines of code, I could have a really good game going.
That particular game lacks structure though. It is important to structure your game so the code never changes if you ever want to change the game a bit. This is where file access comes in very importantly. There are some neat scripting plugins around (including Barnski's Lua which is free) which you can use to tweak things, such as the player's speed, how many enemies there are in a level, etc.
And that is how a game engine should be made. Sorry for the lack of code, but this kind of stuff applies to all programming languages, so it should be quite simple to port. It's the understanding that matters most in these realms.
Enjoy
"It's like floating a boat on a liquid that I don't know, but I'm quite happy to drink it if I'm thirsty enough" - Me being a good programmer but sucking at computers