Do you really need a complete engine to begin designing gameplay?

[vimes]

These days, there are a lot of dev teams declaring such things as : " Yeah, now, the 3D Engine is done, we can begin thinking about the gameplay" or "As you can see, there's a lot of physical interactions with NPCs which will surely be a central point of the gameplay that OH! MY! GOD! we haven't yet implemented despite the fact we're 3 months from the release day!!"

My point is.. do you need a complete 3D engine to create a gameplay and begin implementing it ? Shouldn't it be the other way around : defining a gameplay and then see what kind of engines are needed ?

Right now, some friends and I are developing a little VR application and the gameplay was thought, defined and partially tested long before we chose the 3D Engine .. is this wrong, dad ? Is this right, or did I miss some crucial point regarding this matter?

[Ryam BaCo]

i have too less experience with 3d engine development in teams, but i think that all the big publishers will also think about gameplay first, then lincense or program some sort of engine and extend their main ideas of gameplay with the features offered. i think that there is a big difference between what you see on the very first game-versions and what is/was planned. the programmers may need to implement some sort of engine first so that you can see some sort of result and that the developers transfer the message of "woho! this is promising! i'll buy it!" to you. some sort of "oh! look at this document! what an awesome game concept! and...look!!!...the title is...pink!!! hahaha!" isn't really erotic.

but i think that i'm writing crap now. i'm tired.

[shbazjinkens]

Game engines are probably a priority before coding the game because that is almost definately the hardest part (if you code the game engine from scratch). People expect Normal maps, shadows, and real-time lighting now. If the game has the most awesome story in the world it won't be successful unless the engine is up to technological standards. Sad, but true. I attribute the resale value of old games to nostalgia and the fact that at the time it was cutting edge and popular. Otherwise many of the adventure games being released using AGS at no cost wouldn't have the "no" in front of "cost."

There's a guy on this forum who knows loads about the programming end of 3d engines, so maybe I'll be proven wrong.. but that's the way it seems to me.

Games made with pre-built engines don't have this dilemna. Another reason that some game companies spend so much time developing their engine is so that it will have sale value to other companies or individuals who want to use it without coding their own (and it has to be very good to beat out the competition).

[Jake]

Also (from what I've read and heard and inferred.. never made my own game obviously), most of the game's design is done on paper first, and some stuff is prototyped (even possibly including funky NPC/AI stuff) but isn't necesarilly prototyped with the final engine. I think usually when guys say "oh and we'll have this awesome thing right here but we haven't done it yet" they don't ever mean "we haven't done any of it yet," they just mean "it's sitting off half-done somewhere else in the office, but isn't yet in any condition to be dropped into this otherwise final-condition demo level.

That's my take anyway.

[Jayel]

While I beliefve that a game should be thoroughly designed on paper before any coding is done, I can see how you could develop a 3D engine and build a game around it later and get away with it...

A lot of the framework for a 3D engine can be reused and modified to suit your game's needs. for example resource handling, rendering pipeline, script interpreter etc should be more or less independent of what type of game you're making.

[SiN]

since idle thumbs is a kick-ass site, i finally decided to register ... hi guys!

right then, im a game programmer, not professional or anything, but i do this stuff for fun at home. heres my take on the issue.

While I beliefve that a game should be thoroughly designed on paper before any coding is done, I can see how you could develop a 3D engine and build a game around it later and get away with it...

bad, bad idea. see, despite what people think, u CANT have an excellent game on paper. everything needs to be prototyped. everything. there have been many occasions where ive thought "hey, thats a really cool idea", but once i coded a prototype, it turned out being the most terrible game ever!

so what usually happens is that an engine and the gameplay are worked on at the same time. engines are designed to be extendable, so whenever new features are needed, the engine programmers simply expand on the base engine.

what jake said about features ...

"it's sitting off half-done somewhere else in the office, but isn't yet in any condition to be dropped into this otherwise final-condition demo level.

... is spot-on. although my friends have had the pleasure of seeing some of my half-baked messes in action. when ur presenting something to ur friends its different, u can laugh about the hilarious bugs and missing features (and terrible "programmer art" textures, but thats another story) with them. when u present to the press (which i naturally havent done) everything has to look classy, which is why great, but unfinished features are usually left out.

hope that helps.

SiN

[Jayel]

bad, bad idea. see, despite what people think, u CANT have an excellent game on paper. everything needs to be prototyped. everything. there have been many occasions where ive thought "hey, thats a really cool idea", but once i coded a prototype, it turned out being the most terrible game ever!

Oh yeah... you're right.

I only programmed two games in my life and it shows.

[shbazjinkens]

Oh yeah... you're right.

I only programmed two games in my life and it shows.

No not really.. I still agree with your original statement.

How would pre-made engines like Torque work if you couldn't create the engine first? People who use those don't create the engine, but the engine is pre-existing to the game.

You can also design entire games on paper and have them turn out great, because of how well-planned they can be. If you have problems after that then it's not a fault in the game, but in your ability to know what is and isn't possible or perhaps just how to approach a certain problem. Tons of people do this, it isn't some ill-planned idea.

The engine and the game are developed side-by-side because they have programmers and they have artists, and not a full crew of multi-talented people. Both groups are always going to be working if they want to get paid.

[SiN]

How would pre-made engines like Torque work if you couldn't create the engine first? People who use those don't create the engine, but the engine is pre-existing to the game.

Good point. while i use c++ now, prior to this i used to use DarkBasic, same deal as torque, a pre-built engine. but even with that, the coder creates his own engine over the pre-existing, although not to the extent that u need to in the industry. i mean, even things like custom map formats, loaders, ai and scripts deserves to be called a "mini-engine". and those need to be created along-side with the gameplay coding.

You can also design entire games on paper and have them turn out great, because of how well-planned they can be. If you have problems after that then it's not a fault in the game, but in your ability to know what is and isn't possible or perhaps just how to approach a certain problem.

u cant plan everything and know how much fun its going to be, unless you are God. again, no matter how well planned out they are, theres no guarentee they r gonna be fun ... perhaps with mini-games its easier, but its not a sure-fire thing. a good example is Republic : The Revolution. an excellent idea on paper, but in execution it turned out being rather uninteresting.

Tons of people do this, it isn't some ill-planned idea.

any good examples? ive read my fair share of designer diaries, they all say that either

A) we wrote out an extensive design doc. many things stayed the same, but many things change

we wrote out an extensive design doc. many things stayed the same, but there were some changes

C) we wrote out a basic design doc, and improvised the rest

and moreover, most developers will tell u that their final products turned out being very different from their original concepts, and it was for the better.

@Jayel:

out of curiousity, why'd u stop coding games?

SiN

[Jayel]

well yeah it really depends on what kind of games you're mkaing.

Me, I only try to create RPG games. When you have a clear vision of the game youre making with tried and true gameplay (eg ad&d rulesets), then it'd advantageous to plan everything out before you go into actual production,

but on the other hand you're trying something unique and new, you'd damn better create a prototype and make sure what you're creating is FUN before you spend a lot of time on architectural plans.

SiN:

I didn't stop coding games, really. I'm too busy with school to focus on any game programming at the moment. I did a bunch back in highschool though.

As a matter of fact, " only programmed two games in my life" is not an accurate statement, because I've programmed dozens if you count all the miserable attempts and pathetic failures.

[Marek]

I totally, utterly, profoundly agree with the idea that you need to prototype things and already start producing stuff when the Big Design in your head is only half-done. I only ever worked on one (mostly depressing) indie-level game project but that's pretty much THE main thing I learned on it. Despite my feverish attempts to deny it, you can't design games on paper. A game design doc should be like ... erm, 20 pages long or-so. That's already too much for smaller indie-type games. Something like 5 is probably enough for those.

Only when you prototype things you can go "deeper" into the design, because you can see where the gameplay easily breaks, or see if it's actually as fun as you imagined it would be. If you stay in the imaginary world of game design docs, you'll never really get to the bottom of it. Also, prototyping is a great way to settle arguments over the design (if you're in a team, anyway). You just make it and evaluate it together. You can go on endlessly along the lines of "yeah, but I think feature A will work great!" but when you've actually made it (no matter how shoddily coded it is) you can clearly see for yourself if it works or not, and it settles 95% of all disagreements.

There was a tutorial at GDC that Chris and I went to. It was the one by Katen Salie and Eric Zimmerman. We were asked to design games in small groups using various 'board game' props as assets. By just coming up with some rules and playing them out you could find really obvious loopholes in your original thinking and adapt the gameplay on the fly. It was just a silly design exercise, but I liked how fast the rules would evolve in just 10 minutes of brainstorming and playtesting.

Since prototyping is very important to games, I still think that more middleware needs to exist so that game developers can whip up stuff much easier. I mean, when the team who did Battlefield Vietnam decided to do a Vietnam-themed game, they were like "shit, okay, how do we program an engine modification that shows tons of foilage and grass, with smooth draw distance, and a way of editing it that makes it easy for level designers". So they made a complex proprietary system of a checkerboard-style field of blocks that served as containers for trees and the closer you were blah blah blah, and they created some random grass thing, and a thing that converted bitmaps to levels and shit like that. I mean, what?! There's a fair amount of jungle-based games out there already, but everyone is re-coding the wheel. That stuff should be on the shelf. Okay, obviously that's mostly a graphical aspect making for a poor example in this post, but still, I doubt the full extent of the gameplay wasn't apparent until you could actually hide behind the trees, crouch through the grass, etc. Things like driving a vehicle and bumping into trees are hard to foresee when your levels are still flat terrain.

If the game industry gets that sort of stuff out of the way, programmers can focus more on coding truly new features, such as Prince of Persia's rewind feature, which as I recall required a giant animation file to be stored so that it could be played back.

One thing I'm curious about... people like Will Wright and Sid Meier often speak fondly of the "old days" in which they could whip up a prototype in a few days. I wonder if those guys still touch any code. I'm really curious if they still do prototypes themselves to this day. If I had to do an interview with them that would be one of the first things I'd ask.

Okay, nap time, all that talk of prototyping has made me drowsy.

[Chris]

One thing I'm curious about... people like Will Wright and Sid Meier often speak fondly of the "old days" in which they could whip up a prototype in a few days. I wonder if those guys still touch any code. I'm really curious if they still do prototypes themselves to this day. If I had to do an interview with them that would be one of the first things I'd ask.

I wonder about that too sometimes. I suspect that as designers they have a hand in scripting, but not things like engine programming. When I was at Double Fine (ha ha ha), I observed that Schafer was able to script things out (which I suspect he does for things like cutscenes) but I doubt he gets into the "real" programming too heavily; those skills probably fall out of use when developers (like Schafer, Meier, Wright) become designers/

[SiN]

One thing I'm curious about... people like Will Wright and Sid Meier often speak fondly of the "old days" in which they could whip up a prototype in a few days. I wonder if those guys still touch any code. I'm really curious if they still do prototypes themselves to this day. If I had to do an interview with them that would be one of the first things I'd ask.

well, i kno for a fact that Peter Molyneux programmed the villager AI on black & white 1. turned out pretty good, but apparently he was the buggiest coder on the team . when he wanted to do a bit of coding for b&w2, the team didnt let him! but for the most part, i doubt the designers do much programming, at best, they work on one section (like the villager AI example above) but the days one coder being able to code a whole (or even multiple) parts of a commercial game are near-gone. i suppose its better that way though, since a single coder cant create the vision of these amazing designers.

Me, I only try to create RPG games. When you have a clear vision of the game youre making with tried and true gameplay (eg ad&d rulesets), then it'd advantageous to plan everything out before you go into actual production,

even then, u need to drop it into code to see how the game flows ... even with adventure games, u wont know how well the game flows until u get play testers (or u) test it out. while some puzzles may look great on paper, it may actually turn out being rather tedious ...

A game design doc should be like ... erm, 20 pages long or-so. That's already too much for smaller indie-type games. Something like 5 is probably enough for those.

yeah, design docs really shouldnt be that extensive, unless its a really advanced game, or u start scethcing out levels and stuff in it too. i usually have a 1-2 page design doc, outlining the main goals of the game. hell, one earlier (but really fun) games i made just started when i told my friend "we should make a game with cars" ... that was the only time i worked somebody else on a game, so we just improvised EVERYTHING ... turned out being LOTS of fun to play.

There was a tutorial at GDC that Chris and I went to ...

i hate u ... sorry to off-topic a bit, but how might an enthusiastic game coder like me, be able to get to the GDC, and how much will it cost me?

Since prototyping is very important to games, I still think that more middleware needs to exist so that game developers can whip up stuff much easier.

the problem i see with middleware is how same-ish games will begin to look (and more importantly) feel. i love the way each game feels unique now ... the handling Halo's warthog, im sure feels very different than UT2k4's equivilent. i would hate to see all the games feel over-similar ... i prefer seeing unique technologies grow. although, obviously not at the price of gameplay

SiN

[Marek]

I wonder about that too sometimes. I suspect that as designers they have a hand in scripting, but not things like engine programming. When I was at Double Fine (ha ha ha), I observed that Schafer was able to script things out (which I suspect he does for things like cutscenes) but I doubt he gets into the "real" programming too heavily; those skills probably fall out of use when developers (like Schafer, Meier, Wright) become designers/

Yeah, that shit with the conspiracy guy and the randomized conversations really seemed like something Tim might have coded himself. I have little doubt about Schafer still doing that stuff since he was so heavily involved in that as a SCUMMlet. Just wondering if designers still try out the really big features of a game in a rough prototype, i.e. Sid Meier setting up gameplay dynamics for his dinosaur game, or whatever.

well, i kno for a fact that Peter Molyneux programmed the villager AI on black & white 1. turned out pretty good, but apparently he was the buggiest coder on the team .

That's really interesting. I didn't know that.

i hate u ... sorry to off-topic a bit, but how might an enthusiastic game coder like me, be able to get to the GDC, and how much will it cost me?

Erm, GDC is horribly expensive. Check your PM inbox.

[vimes]

Nom d'un ptit bonhomme, this is the second most educative topic I've ever read. Thanks for everything!

[spaceship789]

the problem i see with middleware is how same-ish games will begin to look (and more importantly) feel. i love the way each game feels unique now ... the handling Halo's warthog, im sure feels very different than UT2k4's equivilent. i would hate to see all the games feel over-similar ... i prefer seeing unique technologies grow. although, obviously not at the price of gameplay

Most same-ness comes from most middleware games being multiplatform, and only using use the set of 3Dgraphics subset common to all the platforms. Microsofts XNA will be good middleware. It allows you to preview the graphics on the XBox while building it the 3D app of your choice.

This means more artists, and 3D app gurus will be doing the prototyping, and setting the agenda. More time on gameplay - not that the BF:V guys don't do a fantastic job already!

[Jayel]

And let's not forget that most middleware are very customizable with lots of parameters. No two application need be the same.

For example DeusEx2 and HalfLife2 both use Havok physics engine, but objects in DeusEx2 are massless and throw like they're made of sponge, while those in HL2 (from what I've seen in the videos) seem much more solid and dynamic.

[toblix]

If I could have sex with computer code, I'd do Havok.

[Ginger]

I'm in a good mood today as I've found out the lump on my bullock is non malignant, w00t the ginger is not going got have his balls chopped off (that is, as long as I don't nause Scottish bob too much)

Sorry if that was too much information. Good thread btw. Another problem with design docs is that a massive amount of designers (most of those that I've worked with) are like a 4 year boy writing a story; they have no parameters on where their ideas go, they do not listen to what the programmers tell them they can & can't do.

I was chatting with the lead designer of a game and he showed me the design document of a past game that he worked on, it was a loose movie licence. It was such that main character was able to perform about 100 different actions, there was no consideration for button mapping (it was a console game) and no respect for the programmers telling him that his ideas were completely infeasible. In the finished game (when the designers had conformed to the parameters set by the code) the level design was as pedestrian as I've ever seen. Anyone can be creative when there are no boundaries but the key to good level design is being creative within the limits of the code.

Given the increasing gamer demand for the complexity of their games, I think the number of designers who posess both the required technical scripting skill and creativity to adequate levels is minimal. Rather than having people who are fair to half arsed at both (which is a description of a large proportion that i have worked with) i think having a creative person coming up with the ideas and working with a coder who does the scripting (when those that have both skills can not be found) will lead to an increase in the average quality of design throughout the industry. However this will probably only become financially feasible once middleware becomes the design standard

[Alex]

I've found out the lump on my bullock is non malignant

Yes, by now you've probably realised the bullock was a cow and the 'lump' was its udders.

[Ginger]

indeed the woes of of pressing replace on a spell check without looking at what it is suggesting