by date
Tools to overcome the complexity barrier
Tools to overcome the complexity barrier
| Name: | Unsung Zero | ![]() |
|---|---|---|
| Date Posted: | Sep 05, 2006 | |
| Rating: | Not Rated | |
| Public: | YES | |
| Comments: | YES | |
| RSS Feed: | or Subscribe with . | |
| Profile Page: | View profile page for Unsung Zero |
Blog post
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.
Submit your own resources!| Adam deGrandis (Sep 05, 2006 at 17:03 GMT) |
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.
| Jeremy Alessi (Sep 05, 2006 at 18:02 GMT) |
| Joe Rossi (Sep 05, 2006 at 23:03 GMT) |
| Tom Eastman (Eastbeast314) (Sep 06, 2006 at 01:14 GMT) |
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. ;)
| Rob Parton (Sep 06, 2006 at 05:39 GMT) |
You must be a member and be logged in to either append comments or rate this resource.



Not Rated


