Is There Such a Thing as TOO Flexible?
Author
Hi.
I'm working on an engine to build a demo game off of. I was hoping to show off my programming and art skills but it turns out that all of my time has been consumed by the programming aspect of the demo creation (time to get the demo together is 3 weeks total)
Anyways, I was programming the animation code for my engine and decided not to hardcode the paths and names of the images to be loaded and have defined them in a regular text file instead. This lets me create custom animations on the fly using vectors and file i/o. This had me thinking though, why not go further with this and make it so the objects to be used aren't hardcoded. Have something like the following:
Graphics Core:
Function Load_Object_Cache():
- Open the file Object_Def.txt (short for object definitions)
- Read in names one by one and create an instance of the Object class who's name is the value of the current string being read
Function Spawn_Object():
- An object needs to be put in the game world! Look in the Object_Cache!
- Compare the value passed in the argument to Spawn_Object to the list of class instances in the Object_Cache.
- If the Object is found, open Object_Name.txt where Object_Name is the name of the current class instance. Otherwise, return an error.
Opening Object_Name.txt:
===Contains Object Class Values such as speed of object, health, etc...===
- If the file can be opened, load up its values into the variables of the object with the same name as the file. Otherwise, create this file with a list of the variables that need to be defined.
This means that if we define default starting position, health, etc, in this file and if the file doesn't exist for the object, the engine will create one for you to fill out. Once it's filled out the engine will deal with what you've typed
Function Load_Object_Animation():
-get the text file defined by Object_Name.txt and load the series of strings for each frame of animation. This should be called Object_Name_Animation.txt where Object_Name is the name of the current object we're dealing with.
-If this file doesn't exist, an error will be tossed and the object will be deleted so it's not interacting invisibilly with anything else.
- this file will contain a series of names. These names are the names of the image files to be loaded for the animation sequence.
I.E.
anim1.png
anim2.png
anim3.png
/END QUICK WRITEUP OF THOUGHT PROCESS.
as you can see Id only be hardcoding the managers and the actual definitions would be defined in external files. This lets me have the engine be something entirely different depending on how I define my objects and their properities in the external files.
I could even condense it down to having one file in an xml type format and loading the objects, variables, and images that way instead of having everything scattered across several individual files.
But would I be going overboard if I were to code the engine this way instead of hardcoding the definitions into the source code?
Thoughts?
Quote:But would I be going overboard if I were to code the engine this way instead of hardcoding the definitions into the source code?
No, this is not as uncommon as you might think. It's called a data-driven design. The extreme end would of course just be an interpreter with all of the program behavior defined in some scripting language, but a good middle ground is a mixture of hard-coded "nitty-gritty engine details" and data-driven "high level" behavior.
I'm a firm believer that the best engines are data driven. I like the engine to be as flexible as possible. However, keep in mind your time constraints. It's better to succeed in your demo with some hardcoded values than to make half of a kick ass demo. It is way too easy to over-engineer a simple problem.
That said, I get a migraine every time I see people hardcode, use magic numbers, and just be all around lazy in their coding. The slight extra time it takes to code correctly will save you magnitudes more time down the road.
That said, I get a migraine every time I see people hardcode, use magic numbers, and just be all around lazy in their coding. The slight extra time it takes to code correctly will save you magnitudes more time down the road.
Harcode execution-time critical code.
Hardcode all basic gameplay concepts that sums up the gameplay of your game.
Give designers the freedom over all other gameplay aspects regarding behavior, variables, object properties.
Build behavior from bricks (many small behaviors which are hard-coded but combined in designer's defines - properties like move, attack, build, inventory and so all other abilities) so you build up an object from those. Never have magic numbers of hard-coded properties.
Ultimatly take a look at Warcraft III map editor - it's a good example where to draw the line between what to give control over and what to hardcode. FPS games give more freedom but are way more complex in control for the beginning.
Hardcode all basic gameplay concepts that sums up the gameplay of your game.
Give designers the freedom over all other gameplay aspects regarding behavior, variables, object properties.
Build behavior from bricks (many small behaviors which are hard-coded but combined in designer's defines - properties like move, attack, build, inventory and so all other abilities) so you build up an object from those. Never have magic numbers of hard-coded properties.
Ultimatly take a look at Warcraft III map editor - it's a good example where to draw the line between what to give control over and what to hardcode. FPS games give more freedom but are way more complex in control for the beginning.
Flexibility is nice. While working on my game for a while, I've just made it almost 100% dynamic. For instance objects are created on the fly by loading in binary files that contain all their animation objects and boundaries and such. Very nice to have everything "flexible". However it is very time consuming.
For my objects I have a boundaryManager, textureManager(animation manager), and a prototypeGameObjectManager which constructs objects in the game almost dynamically. If a map needs an object called "royal guard" or something it finds the binary file and loads it in, if when it's loading the prototype it can't find the boundary files already loading in the boundaryManager it loads them in and the same for the textureManager.
(however MMO games act differently in some respects to normal games, so my design system might not be suited for a single player game very well.
For my objects I have a boundaryManager, textureManager(animation manager), and a prototypeGameObjectManager which constructs objects in the game almost dynamically. If a map needs an object called "royal guard" or something it finds the binary file and loads it in, if when it's loading the prototype it can't find the boundary files already loading in the boundaryManager it loads them in and the same for the textureManager.
(however MMO games act differently in some respects to normal games, so my design system might not be suited for a single player game very well.
Author
Mine will, in the end, probably be a binary file containing the perimeters of the objects to be loaded. Currently I'm handling only images in this "data-driven" way because I hated seeing
Init_Image(anim1)
Init_Image(anim2), anim3, etc...
and then having an new sdl surface to deal with the image currently being requested and point to the next in the array of "anim[n]"
My object handling system looks like this in psuedo-code:
I'm going to focus on getting the game done for now. If I find myself with extra time on my hands through the act of some miracle, I'll try making the engine a little more flexible.
Init_Image(anim1)
Init_Image(anim2), anim3, etc...
and then having an new sdl surface to deal with the image currently being requested and point to the next in the array of "anim[n]"
My object handling system looks like this in psuedo-code:
int Spawn_Object(){ Object_Class Object; //create the instance of the object class called Object SDL_Surface *temp; //create a temporary sdl_surface for future use string reading; //create a string to load the current line in the animation text file ifstream infile("animation_list.txt"); //open the animation text file to start loading images into the animation vector while(not at the end of the file){ while(get a line, put that line in string reading){ temp = Load_And_Optimize_Image(reading); //our temp sdl_surface is equivilant to the return value of our image loading function//what our image loading function actually does is use IMG_Load(filename) where filename is the current value of the string reading. //The function then optimizes the image for the current screen resolution and returns that back. reading.clear(); // free our string so its good for more info! Object.animation_vector.push_back(temp); //toss our new optimized SDL_Surface into the animation vector of the current object. } Object_Container.push_back(Object); // toss the current object into the object managing vector. }}I'm going to focus on getting the game done for now. If I find myself with extra time on my hands through the act of some miracle, I'll try making the engine a little more flexible.
Absolutely, there is such a thing as too flexible. Flexibility has a cost associated with it:
* It takes longer to code.
* It makes debugging harder.
* It makes testing harder.
So, when adding flexibility, you need to ask yourself, "Will the benefits of this flexibility be worth the cost to add that flexibility?" In your case, since it sounds like you have to get a demo up in three weeks, you don't have a lot of extra time to spend on flexibility, so you should only take the flexible approach when it is nearly free (like storing paths in a text file instead of in the code). The cost of making a generic object-processing engine is probably pretty high, so I don't think you have the choice in that particular decision point.
Of course, after you write the demo, you'll probably have more insight into what the costs would be, and perhaps a different decision will be the right one.
Hope that helps,
Geoff
* It takes longer to code.
* It makes debugging harder.
* It makes testing harder.
So, when adding flexibility, you need to ask yourself, "Will the benefits of this flexibility be worth the cost to add that flexibility?" In your case, since it sounds like you have to get a demo up in three weeks, you don't have a lot of extra time to spend on flexibility, so you should only take the flexible approach when it is nearly free (like storing paths in a text file instead of in the code). The cost of making a generic object-processing engine is probably pretty high, so I don't think you have the choice in that particular decision point.
Of course, after you write the demo, you'll probably have more insight into what the costs would be, and perhaps a different decision will be the right one.
Hope that helps,
Geoff
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement