Data Driven Game Engine
Status: Pre-Alpha
Brought to you by:
xmkrx
Menu
▾
▴
I started thinking about some common implementations for game engines. As far as i know, the easiest approach to designing an RPG or adventure game is to have stored levels. Obviously, but, how do you implement this? That's the very first thing that i had to do when i worked on a RTS for VB about 2 years ago. I realized early on that the game engine was infact, not A game engine. It was basically 30 different game engines existing on 30 different forms! I had to add the basic engine functions and commands to every single form! So came to a simple conclusion, i needed a data driven game engine. Basically, the simplest method of storing inforamtion is with numbers. If you can encode an entire map as numbers then you only need one Form in your project. That form simple has to read the encoded map, decode it, and present it to the user. When the user reaches a new area, a new map is referenced and decoded. When i say encoding and decoding i mean something like this:
1111111111111111111111111111
1222222222222222222222222221
1222222222222222222222222221
1222222222222222222222222221
1222222222228888888882222221
1222222222228888888882222221
1222222222228888888882222221
1222222222228888888882222221
1222222222222222222222222221
1111111111111111111111111111
Assuming 1=rock, 2=grass and 8=water then, you have a fairly simple map enclosed in rock with a little lake in the middle. This makes collision detection fairly simple since it is only neccesary to identify what kind of tile the player is trying to walk into. If the player tries to walk into [1] and [1] has been labeled .blocked then he won't be able to pass it. Insanely simple.
This approach to the game engine allows you to have an almost infinite amount of maps with almost infinte kinds of textures. As many as you can count to! The only requirements are that 1:an effective way of accessing the stored maps is designed, which is not harder than reading text files into variables and 2:a procedure which identifies all types of tile in relation to their numbers and proceeds to display them on the screen row by row. BLitting works best here.
The other half of all this is the all important map editor. Map editors are so easy to make on VB that most C games use VB map editors. All the map editor will have to do is display various tiles and properties and when the user clicks save map or compile map the program will convert his map into a large number file containing all the map and properties in number format. As long as your game engine can read the data your good to go. Then you can get rid of the complexities of level design and work on the game/engine features. Essentially, it's best if the level editor does the bulk of the work, transcribing the data into a file(S). That way you can make the entire game and the game engine is almost like a compiler, it just runs everything and displays it.
Tell me what you think.
JLC
trancetrippin
Sounds good, i'm checking planetsourcecode.com for examples on map editors, since honestly i have no clue where to start on that, one question, how would i do collision detection with a generated map?