Monday, July 21, 2008
Making Game-Making Easier
Archimedes claimed, "Give me a lever long enough and a fulcrum on which to place it, and I shall move the world."
I think Archimedes was a game developer, and the rest of his quote (translated from ancient greek) reads, "... because I really need to move the world 200 units in the positive Y direction so I can stick the new sewer passages in before next week's milestone."
Game development has changed a lot since I first got in the business. Once upon a time (before my time), it was more about programming wizardry. Now it's much more data driven. And while programming wizardry is still a significant part of things, the bottlenecks I keep seeing are found in the tools and the tools pipeline.
Well, the tools are the various editors, modeling packages, and so forth that you can use to make content for your game. One of the problems with tools over the years is that they have gotten significantly more powerful, but not easier to use. In Doom's heyday, a solid level could be cranked out in a single day. Maybe another day or two for polish. Nowadays, a level generating approximately equal amounts of gameplay might take an entire man-month to create.
Herb Flower, of LinkRealms, was talking to me last year about his days with ReWolf, doing a commercial half-life mod. He said that back in the late 90's, the mod scene was vibrant and alive for all of these games. But now - not so much. In part, it is because of the commercial viability of the mod scene - teams are very likely to fall apart over squabbles of who gets what potential share. But it's also in part due to the complexity of making mods. The requirements for what constitutes "acceptible" quality is much higher, and neither the tools nor the modmakers can keep up.
The tools pipeline is a whole 'nother story. This is the path that takes all the content generated by the tools, and imports it into the game. This has been the weakest link in the chain everywhere I have worked, including my own Rampant Games. The process is typically slow, tedious, and error prone. This makes it hard for the artists and designers to actually see and test their work.
Somehow, miraculously, old data finds its way creeping into the build, and things that were fixed days ago become broken again. Something silly like a missing texture won't be detected until twenty minutes into a 30-minute process, which forces you to start over from scratch. Annoyances like that, which compound upon each other, until what should have taken less than an hour ends up taking all day long.
Just think about it - what if making a game level were not much more difficult than sketching it out on graph paper? (And yes, before you say anything, I do know about SketchUp). Could we compress the amount of time it takes to do 90% of the work? Could we begin working on "meta-tools" - tools to make tools - for game development? I look at the (relative) simplicity of putting together Neverwinter Nights modules. Sure, there was some missing power there, but the thousands of user-created mods that came out is evidence of what that level of productivity you could get from designers and content creators when you make it simple, easy, and error-resistant.
(Yes, I have been fiddling around with level editors this weekend, how did you know?)
Frankly, if we want to talk about making better games, we should quit thinking about better pixel shaders or more realistic hair movement. The limiting factor is no longer in those technological elements, but in what I'd consider logistical ones. A skilled designer, animator, artist, or even programmer with a world-class set of tools and a painless, fast, error-free pipeline can be 100 times more productive. Which would mean better gameplay, better polish, and more innovation.
Labels: productivity, programming
- posted by The Rampant Coyote @ 3:32 AM (Permalink)
Comments:
Links to this post:
<< Home
If I remember correctly, Mike Capps (Epic Games) recently said their ratio of artists to programmers is 5:1, and that he pushed the programmers to concentrate on tool development, not engine work, because of the huge productivity multiplier. (This may have been because it was post-UE3 PC ship so the engine was already stable.)
Do we yet have the technology for people to build physical layout structures (out of, say, legos or something) and then send a camera/robot to explore them and import that as basic geometry to be tweaked and refined?
Having never worked in big 3d games, I don't know if this would actually make a difference in speed, but it would sure be a lot of fun to build mini-dungeons in your living room out of spare boxes and turn them into levels...
Having never worked in big 3d games, I don't know if this would actually make a difference in speed, but it would sure be a lot of fun to build mini-dungeons in your living room out of spare boxes and turn them into levels...
I know this isn't exactly what you're referring to, but my 13-year-old son has been using Game Maker (YoYo Games). It's been a good way to ease him into the programming world.
At first, he would simply use the tools as-is, but lately he's been dipping into the code and learning how to make things do what he wants.
It has acted as a lure to bring him into the programming world (or its starting to). I'm pretty sure he wouldn't have simply jumped into a programming language cold. But now that he's gotten a taste, I can see it in his future.
Do you have any experience with Game Maker or something similar? I want to encourage Carson, perhaps lead him toward the next level. Any advice?
Shaffer
At first, he would simply use the tools as-is, but lately he's been dipping into the code and learning how to make things do what he wants.
It has acted as a lure to bring him into the programming world (or its starting to). I'm pretty sure he wouldn't have simply jumped into a programming language cold. But now that he's gotten a taste, I can see it in his future.
Do you have any experience with Game Maker or something similar? I want to encourage Carson, perhaps lead him toward the next level. Any advice?
Shaffer
Tom: I wouldn't doubt it, for the Unreal guys. The quality of that engine is such that I'd expect it would take an army of artists.
Whiner: I'm sure we do, but I don't know if it would be cost effective. But if we could capture that process digitally with an easy interface, that would be REALLY COOL.
Shaffer: Ask Whiner :) Cute Knight, Fatal Hearts, and several others were made with Game Maker. So it's got the power to make some very high-quality games.
As far as the next step up, I don't know the answer to that one. I'm still pissed off at the lack of better tools. I have heard very good things about Blitz3D and BlitzMax, though.
Torque Game Builder - you know, I really do like it, but I haven't checked out the latest versions, and Torque is getting a little notorious for having "issues" - mainly complexity issues for new developers, weird bugs & compatibility problems with certain hardware, etc. So it might not be the best next step. But I really do like it.
Whiner: I'm sure we do, but I don't know if it would be cost effective. But if we could capture that process digitally with an easy interface, that would be REALLY COOL.
Shaffer: Ask Whiner :) Cute Knight, Fatal Hearts, and several others were made with Game Maker. So it's got the power to make some very high-quality games.
As far as the next step up, I don't know the answer to that one. I'm still pissed off at the lack of better tools. I have heard very good things about Blitz3D and BlitzMax, though.
Torque Game Builder - you know, I really do like it, but I haven't checked out the latest versions, and Torque is getting a little notorious for having "issues" - mainly complexity issues for new developers, weird bugs & compatibility problems with certain hardware, etc. So it might not be the best next step. But I really do like it.
Hey, great article
@ whiner
That does sound like a lot more fun! :-)
I have spent hours and hours looking for tools to help out with isometric and pixel art, and I have been pretty disappointed as well. There is World Creator, and for a while I toyed around with it, but it just didn't solve all of the problems.
I am currently using 3d tools to model 2d objects and making a lot of conversions. The time it takes to make certain tiles and walls is ridiculous.
In some cases I programmed a few of my own tools, but due to lack of time, I have to do too many workarounds to use them.
@ coyote
TGB 1.7.2 fixed so many issues I had that I drew up a revised design document and went closer to the original idea I had before fighting tooth and nail with collisions and physics with earlier versions. It still has its problems, but they are actually shrinking pretty quickly now. But like you said, it really isn't a beginners development studio.
@ whiner
That does sound like a lot more fun! :-)
I have spent hours and hours looking for tools to help out with isometric and pixel art, and I have been pretty disappointed as well. There is World Creator, and for a while I toyed around with it, but it just didn't solve all of the problems.
I am currently using 3d tools to model 2d objects and making a lot of conversions. The time it takes to make certain tiles and walls is ridiculous.
In some cases I programmed a few of my own tools, but due to lack of time, I have to do too many workarounds to use them.
@ coyote
TGB 1.7.2 fixed so many issues I had that I drew up a revised design document and went closer to the original idea I had before fighting tooth and nail with collisions and physics with earlier versions. It still has its problems, but they are actually shrinking pretty quickly now. But like you said, it really isn't a beginners development studio.
I dont know about making it easier, see what easer did for fanfiction (eg: fanfiction.net ruined rec.arts.creative.anime).
easier too often means flooding the market with garbage and mary sue crap.
there needs to be some skill required, the old saying, no pain no gain. too easy is no fun. compare agt to inform. agt games flooded the market, all were crap, inform takes much more skill, thus the strength of the games greatly increased.
easier too often means flooding the market with garbage and mary sue crap.
there needs to be some skill required, the old saying, no pain no gain. too easy is no fun. compare agt to inform. agt games flooded the market, all were crap, inform takes much more skill, thus the strength of the games greatly increased.
@Whiner: The field of Simultaneous Localization and Mapping (SLAM) is the closest thing I know of to what you're thinking of. Sebastian Thrun wrote an excellent paper on the subject a few years ago summing up the field.
The problem as I see it is that cameras and robots can only detect boundaries -- the points from which laser light or sonar waves bounce back. Inferring geometries from that can be a daunting task, let alone nice reasonable geometries that a 3D renderer would not choke on. Someone may well have come up with one, though -- Google Scholar might turn up some interesting articles on the subject.
The problem as I see it is that cameras and robots can only detect boundaries -- the points from which laser light or sonar waves bounce back. Inferring geometries from that can be a daunting task, let alone nice reasonable geometries that a 3D renderer would not choke on. Someone may well have come up with one, though -- Google Scholar might turn up some interesting articles on the subject.
Stu:
In general, I prefer user-side filters rather than barriers to entry. But more importantly, ease of development means that it's possible for talented people to make their dream game, whereas now --- it's pretty impossible.
Almost.
Case in point, for me, is the Aveyond games. Now, they are far from technologically advanced. But the RPG Maker system allows a very small team - basically, one talented lady and contractors - to make something that - while not quite rivalling the million+ dollar extravaganzas of the late 16-bit era - are still pretty worthy and impressive.
In general, I prefer user-side filters rather than barriers to entry. But more importantly, ease of development means that it's possible for talented people to make their dream game, whereas now --- it's pretty impossible.
Almost.
Case in point, for me, is the Aveyond games. Now, they are far from technologically advanced. But the RPG Maker system allows a very small team - basically, one talented lady and contractors - to make something that - while not quite rivalling the million+ dollar extravaganzas of the late 16-bit era - are still pretty worthy and impressive.
I have been programming for 25 years. The vast majority of my work has been in the development of tools. One of the things which I have learned is that powerful tools and GUI environments do not work well together. You say you want a powerful tool so that you can build four walls and a roof, complete with doors and windows, at the click of a mouse? Plus have the resulting model ported easily to your game engine? Oh, and the doors must be exactly the right size and animate correctly. Nice idea. You won't get that from a graphical modeling program. Ever. But that's what everyone wants. That's why the industry is stuck in the mud.
Take it from a grizzled old tools developer. You won't get this kind of capability if you're not willing to kick the mouse aside, roll up your sleeves and do some good old-fashioned keyboarding. The only way to make a good tool is to power it through text. That is still the way real computer programs get written. It is also the way to automate game content.
I have tried and failed to convince anyone that 3D models can and should be developed the same way C++ programs get written. Text descriptions. A powerful tool can take a well-written description and build anything you want. It works for the Internet. It works for many other things. It can work for game content.
Unfortunately, people want the point-and-click stuff. Don't you wish that it weren't so hard to get a single vertex in exactly the right place in Blender or Max or Maya? Let alone a hundred such vertices? Well, tough. With a graphical interface, you will pretty much have to tweak those hundred vertices manually. No such thing as writing a few simple lines of code to take care of something like that. Yes, you can try writing something in Maxscript or MEL but the truth is that scripting languages don't work well. They exist only to give the illusion of power.
If I sound cynical, it's because I have a lot of experience with this sort of thing in other industries. People want power but they won't give up convenience. I have seen it so many times. The hours upon hours wasted fixing broken paragraphs in a Word document just to avoid the DOS prompt. Oh well.
Take it from a grizzled old tools developer. You won't get this kind of capability if you're not willing to kick the mouse aside, roll up your sleeves and do some good old-fashioned keyboarding. The only way to make a good tool is to power it through text. That is still the way real computer programs get written. It is also the way to automate game content.
I have tried and failed to convince anyone that 3D models can and should be developed the same way C++ programs get written. Text descriptions. A powerful tool can take a well-written description and build anything you want. It works for the Internet. It works for many other things. It can work for game content.
Unfortunately, people want the point-and-click stuff. Don't you wish that it weren't so hard to get a single vertex in exactly the right place in Blender or Max or Maya? Let alone a hundred such vertices? Well, tough. With a graphical interface, you will pretty much have to tweak those hundred vertices manually. No such thing as writing a few simple lines of code to take care of something like that. Yes, you can try writing something in Maxscript or MEL but the truth is that scripting languages don't work well. They exist only to give the illusion of power.
If I sound cynical, it's because I have a lot of experience with this sort of thing in other industries. People want power but they won't give up convenience. I have seen it so many times. The hours upon hours wasted fixing broken paragraphs in a Word document just to avoid the DOS prompt. Oh well.
# posted by 
: July 22, 2008 1:39 AM
: July 22, 2008 1:39 AM
@ Dan L'ecuyer:
I'm a programmer and an artist and would NEVER want to build content by "kicking the mouse aside" or via "text descriptions"! And "scripting languages don't work well"???!
Your post is so far out there that I can only assume:
A) A complete and utter disconnection from reality on your part and a probably need to get back on your meds,
B) You're a grim pessimist that hates everything, especially things built with GUIs, in which case we should take the entire post with a grain (or 10,000) of salt, or
C) You're totally joking and we should all have a good laugh.
I'm going to give the benefit of the doubt and assume C. (After all, I did have a really good laugh!) =D
I'm a programmer and an artist and would NEVER want to build content by "kicking the mouse aside" or via "text descriptions"! And "scripting languages don't work well"???!
Your post is so far out there that I can only assume:
A) A complete and utter disconnection from reality on your part and a probably need to get back on your meds,
B) You're a grim pessimist that hates everything, especially things built with GUIs, in which case we should take the entire post with a grain (or 10,000) of salt, or
C) You're totally joking and we should all have a good laugh.
I'm going to give the benefit of the doubt and assume C. (After all, I did have a really good laugh!) =D
aveyond is a nice example of what RPG maker can do but it doesnt excuse the truckloads of dross that people have turned out, its too enabling, which would have been great had it not come with stock artwork making most everything churned out look the same.
that it uses ruby rocks even more ;) but still, too much dross, not enough gold.
that it uses ruby rocks even more ;) but still, too much dross, not enough gold.
I get the last laugh, Xenovore. You have proven my point. I was not expecting any sort of rational debate on this topic.
# posted by : July 22, 2008 9:44 PM
: July 22, 2008 9:44 PM
Xenovore: Okay, I'll bite. What is irrational about describing game data textually? Although I am specifically interested in the 3D modelling aspect, just about anything (textures, animation, etc.) could be described textually and then interpreted by some program. Admittedly, some things may seem much less feasible than other things but that doesn't mean that the whole idea is irrational.
Did you know that the game levels in the original Doom game were created textually? Yes, it was easier for id to do it that way rather than invest development time to create a graphical editor. Are you saying that the id guys were irrational?
Did you know that the game levels in the original Doom game were created textually? Yes, it was easier for id to do it that way rather than invest development time to create a graphical editor. Are you saying that the id guys were irrational?
# posted by : July 23, 2008 11:06 PM
: July 23, 2008 11:06 PM
@Dan:
Obviously, describing things textually is, in-and-of-itself, not irrational; we do it all the time in books, conversations, etc. However, what is irrational, is this apparent presumption on your part that creating game content via text would somehow be better, more efficient, more accurate, more cost-effective, more fun, more... anything.
Regarding Doom level development, you are misinformed. No, id did not create the Doom levels "textually"; they developed on top-of-the-line NeXT computers with a full UI and an editor called DoomEd.
To quote John Romero: "In fact, with the superpower of NeXTSTEP, one of the earliest incarnations of DoomEd had Carmack in his office, me in my office, DoomEd running on both our computers and both of us editing one map together at the same time. I could see John moving entities around on my screen as I drew new walls. Shared memory spaces and distributed objects. Pure magic."
Doesn't sound very "textual", does it.
Obviously, describing things textually is, in-and-of-itself, not irrational; we do it all the time in books, conversations, etc. However, what is irrational, is this apparent presumption on your part that creating game content via text would somehow be better, more efficient, more accurate, more cost-effective, more fun, more... anything.
Regarding Doom level development, you are misinformed. No, id did not create the Doom levels "textually"; they developed on top-of-the-line NeXT computers with a full UI and an editor called DoomEd.
To quote John Romero: "In fact, with the superpower of NeXTSTEP, one of the earliest incarnations of DoomEd had Carmack in his office, me in my office, DoomEd running on both our computers and both of us editing one map together at the same time. I could see John moving entities around on my screen as I drew new walls. Shared memory spaces and distributed objects. Pure magic."
Doesn't sound very "textual", does it.
Xenovore: Good catch. Yes, id did have DoomEd. What we don't know for sure is exactly WHEN they had it. I do know that IDBSP required text as input. It might be true that some of the earlier game levels were done as text before DoomEd was actually ready. Anyway, you're right and my example sucks.
I stated that more powerful tools would require text description as input. I did not say that this is "better" or "more accurate" or whatever (though the implication is certainly there). I am not condemning the GUI just to be inflammatory. I am saying that powerful tools require a higher quality of input than what can reasonably be supplied via the GUI. A complex operation which might involve a dozen menu selections in a GUI could conceivably be represented as a single line of text.
The most important aspect of using a textual description versus mouse clicks is context. A text file describing the steps in the creation of a game level or 3D model has context and also history. Recovering from a mistake is a simple matter of editing the text. How do you recover from a mistake in a GUI? An undo feature is very often insufficient due to the fact that the context and the history of the work in progress is more than likely lost or invalidated. Everything which you have done since you made the mistake must also be undone.
If you have done any significant work in level creation then you know that most of the effort involved is mere iteration. That is, you hack away at the details till it looks right. Good planning is essential, of course, but you will always need to iterate. It never ever works out exactly as you envisioned in your head. Iteration is difficult or impossible in the absence of context or history.
If you want to try making your river a little bit wider then you're going to have a problem with the bridge. If you make the bridge longer then you may need to add more support columns. Those houses will need to be moved further away from the shore. And so on. Imagine the possibilities if changing the width of the river could be as simple as modifying a global value in a text file. You can go ahead and try out the wider river and the only cost is the time spent recompiling the level.
As stated by Coyote at the beginning of the article, iteration is the problem. What do you recommend to fix this?
I stated that more powerful tools would require text description as input. I did not say that this is "better" or "more accurate" or whatever (though the implication is certainly there). I am not condemning the GUI just to be inflammatory. I am saying that powerful tools require a higher quality of input than what can reasonably be supplied via the GUI. A complex operation which might involve a dozen menu selections in a GUI could conceivably be represented as a single line of text.
The most important aspect of using a textual description versus mouse clicks is context. A text file describing the steps in the creation of a game level or 3D model has context and also history. Recovering from a mistake is a simple matter of editing the text. How do you recover from a mistake in a GUI? An undo feature is very often insufficient due to the fact that the context and the history of the work in progress is more than likely lost or invalidated. Everything which you have done since you made the mistake must also be undone.
If you have done any significant work in level creation then you know that most of the effort involved is mere iteration. That is, you hack away at the details till it looks right. Good planning is essential, of course, but you will always need to iterate. It never ever works out exactly as you envisioned in your head. Iteration is difficult or impossible in the absence of context or history.
If you want to try making your river a little bit wider then you're going to have a problem with the bridge. If you make the bridge longer then you may need to add more support columns. Those houses will need to be moved further away from the shore. And so on. Imagine the possibilities if changing the width of the river could be as simple as modifying a global value in a text file. You can go ahead and try out the wider river and the only cost is the time spent recompiling the level.
As stated by Coyote at the beginning of the article, iteration is the problem. What do you recommend to fix this?
# posted by : July 24, 2008 11:46 PM
: July 24, 2008 11:46 PM
Two reasons why this post interests me: as a ZDoom weapons modder, I am extremely glad for the rapid development tools and eased coding standards that ZDoom offers for modders (DECORATE is essentially a text script compiled at runtime, and as such is easy to check even minor changes, and ZDoom also supports raw lump files in a ZIP archive, making it so all I have to do is save my text file into the ZIP and I'm good to go), but am surprised at how much testing needs to go into a level even today with no less than two popular editors in existence!
The second reason this post interests me is because of how the Offset Engine almost advertised its intentions to streamline this process. Perhaps the eggheads who built it really were onto something even more important than an epic fantasy storyline?
Post a Comment
The second reason this post interests me is because of how the Offset Engine almost advertised its intentions to streamline this process. Perhaps the eggheads who built it really were onto something even more important than an epic fantasy storyline?
Links to this post:
<< Home
