Tools to overcome the complexity barrier
by Unsung Zero · 09/05/2006 (9:34 am) · 5 comments
I wrote this last night, and it is still mostly coherent this morning! So here it is:
After reading Dan MacDonald's blog regarding "[url=http://www.garagegames.com/blogs/15718/11205]The Complexity Barrier[/url", I got to thinking about past game development experiences in regards to tools. In my mind, nearly everything is a tool. This includes language, picture frames, software, numbers, and the expected screwdriver. Now, how they are considered tools may not be obvious at first, but they all share one thing in common. They are used as a means of accomplishing a task or purpose. Language transmits information, picture frames frame pictures, software does what it is designed to do (usually), and screwdrivers drive screws.
Ok, so that's all pretty obvious, but what does it have to do with game development?
Say you need to create different enemy type (an example given in Dan's blog) for your game. So you open up your code (with your code editing tool) and add a single enemy type. Not so bad, it only took a few minutes, piece of cake. No extra tools necessary.
Imagine that there is a knock at your door, and it's your mom. She stopped over with her glasses because the one arm has become unscrewed and has fallen off. You could probably fix the glasses without using a tool, or using a makeshift tool. But what if she stopped over every day, with the same request? You would very likely buy a tiny screwdriver, or if fitting your needs didn't exist, you might even create one. So creating a tool that accomplishes a repeatedly necessary task isn't that far off the wall. By not creating or acquiring a tool, you are exerting more effort than necessary to accomplish the task at hand.
Now back to your game:
Fighting the same creature repeatedly wouldn't make for a very interesting game, so you will need to add and edit creatures. You can either do this by hand, or create/acquire a tool which will accomplish this task. Again, by not having that tool available, much of that effort is unnecessary. How much work could be eliminated if you had the proper tools? Where else in your life would this question be applicable?
For those of you who coded or built for a MUD, how helpful and productive was it to have OLC, a player editing system, a spell editing system, a mob editing system? It was a tremendous help to have these tools. You could now alter the game from the command line!
I suppose "having the right tools for the job" isn't a big secret. But why is it that we, as game developers, often neglect to have the right tools? Is it because our players won't see the work that went into the tools? I'm not really sure why. Perhaps we don't realize that it doesn't have to be as difficult as we're making it out to be.
From my experience, I've found that adding the tools you need first, and then creating your game from there is MUCH more satisfying and motivating. I'm creating a PHP/mySQL web browser based game, and I couldn't imagine having to open up the SQL database each time I wanted to edit a player or item. Without the unseen administrative tools, I wouldn't be creating a game; I'd be entering data into a DB for hours on end.
GarageGames did TGB right when they released it with the toolset that they did. Not that the engine itself isn't well done, but what do you read about when someone praises it. It's the ease of use. It's easy to use because the tools that we seem to neglect have been provided. After you use them, try and accomplish the same task in your script editor, and see how much work the tools save.
It's getting late, and I think I will just be repeating myself or Dan's blog. I guess I just wanted to share that nearly everything is a tool, and the right tool at the right time can, and has, literally changed the world.
After reading Dan MacDonald's blog regarding "[url=http://www.garagegames.com/blogs/15718/11205]The Complexity Barrier[/url", I got to thinking about past game development experiences in regards to tools. In my mind, nearly everything is a tool. This includes language, picture frames, software, numbers, and the expected screwdriver. Now, how they are considered tools may not be obvious at first, but they all share one thing in common. They are used as a means of accomplishing a task or purpose. Language transmits information, picture frames frame pictures, software does what it is designed to do (usually), and screwdrivers drive screws.
Ok, so that's all pretty obvious, but what does it have to do with game development?
Say you need to create different enemy type (an example given in Dan's blog) for your game. So you open up your code (with your code editing tool) and add a single enemy type. Not so bad, it only took a few minutes, piece of cake. No extra tools necessary.
Imagine that there is a knock at your door, and it's your mom. She stopped over with her glasses because the one arm has become unscrewed and has fallen off. You could probably fix the glasses without using a tool, or using a makeshift tool. But what if she stopped over every day, with the same request? You would very likely buy a tiny screwdriver, or if fitting your needs didn't exist, you might even create one. So creating a tool that accomplishes a repeatedly necessary task isn't that far off the wall. By not creating or acquiring a tool, you are exerting more effort than necessary to accomplish the task at hand.
Now back to your game:
Fighting the same creature repeatedly wouldn't make for a very interesting game, so you will need to add and edit creatures. You can either do this by hand, or create/acquire a tool which will accomplish this task. Again, by not having that tool available, much of that effort is unnecessary. How much work could be eliminated if you had the proper tools? Where else in your life would this question be applicable?
Quote:"If you (like most do) neglected to build a suite of tools that enable you to make these kinds of changes without writing more code you can still slam right into the complexity barrier." -Dan MacDonald
For those of you who coded or built for a MUD, how helpful and productive was it to have OLC, a player editing system, a spell editing system, a mob editing system? It was a tremendous help to have these tools. You could now alter the game from the command line!
I suppose "having the right tools for the job" isn't a big secret. But why is it that we, as game developers, often neglect to have the right tools? Is it because our players won't see the work that went into the tools? I'm not really sure why. Perhaps we don't realize that it doesn't have to be as difficult as we're making it out to be.
From my experience, I've found that adding the tools you need first, and then creating your game from there is MUCH more satisfying and motivating. I'm creating a PHP/mySQL web browser based game, and I couldn't imagine having to open up the SQL database each time I wanted to edit a player or item. Without the unseen administrative tools, I wouldn't be creating a game; I'd be entering data into a DB for hours on end.
GarageGames did TGB right when they released it with the toolset that they did. Not that the engine itself isn't well done, but what do you read about when someone praises it. It's the ease of use. It's easy to use because the tools that we seem to neglect have been provided. After you use them, try and accomplish the same task in your script editor, and see how much work the tools save.
It's getting late, and I think I will just be repeating myself or Dan's blog. I guess I just wanted to share that nearly everything is a tool, and the right tool at the right time can, and has, literally changed the world.
#2
09/05/2006 (11:02 am)
I start coding quite frequently without knowing exactly where its going, I call it codesketching ;)
#3
09/05/2006 (4:03 pm)
I've actually been spending all my time working on a tool to help me (or anyone) make/edit my games. I believe it will be worth it down the road. I have it setup so that I can click any TGB object (sprite, model, whatever..) and launch a GUI to edit the game logic for that object. When a level is loaded, it loads that logic too. I think it will really help.
#4
I had to read the 3rd paragraph a few times until I realized that the arm was falling off of the glasses and not your mom. ;)
09/05/2006 (6:14 pm)
Tools rock! This blog got me thinking - I think you're right in saying that we often ignore the tools because the players doesn't see them. Or, even better, because you yourself don't see instant progress as a player when you make tools.I had to read the 3rd paragraph a few times until I realized that the arm was falling off of the glasses and not your mom. ;)
#5
09/05/2006 (10:39 pm)
I've been playing with SQLite in TGE quite a bit but since I can't be bothered doing the data entry by hand through script, I threw together a little editor in Delphi (god help me), and it seems to work great! It didn't take long to code, and the time savings has been definately worth it. Not only is it satisfying, but it's time efficient! 
Torque 3D Owner Adam
Adam deGrandis
I probably make a new brush in photoshop at least once for each client I have. Need a maple tree done in the WoW style? That's a new leaf brush right there. Highly detailed metal panelling? Im making a bolt/rivit brush, a welded edge brush, and a rust brush. Hyper violent shooter? Blood splatter brushes 'til the cows come home.
The point you make is great. It kind of gets at a much larger discussion, too, about project planning. You don't start writing code before you know what kind of game you're making. You don't open 3ds max or maya or whatever until you have at least a few sketches of what you're modeling. Its about preparation.
To be glib, learning to take things step by step and to plan ahead is the difference between people who finish games and people who don't.