Prototyping - Why is it important for game devs?

Discussion in 'Game Development (Technical)' started by joe, Jan 21, 2011.

  1. joe

    joe
    Original Member

    Joined:
    Sep 28, 2004
    Messages:
    420
    Likes Received:
    0
    Hi,

    I just wrote a few words about prototyping in my blog, and why it's important in game development.

    We currently do this excessive in my fulltimejob at gameforge, so I'd also like to hear your experiences and opinions:

    Why Prototyping is so important in game development
     
  2. MrPhil

    Original Member

    Joined:
    Aug 4, 2004
    Messages:
    671
    Likes Received:
    0
    Trying to be helpful:

    "I got used to work out a prototype if I start to work on a new game."

    Huh?
     
  3. Roman Budzowski

    Indie Author

    Joined:
    May 7, 2005
    Messages:
    839
    Likes Received:
    2
    I stopped prototyping... can't afford it. I let other devs do research for me ;-) Really, prototyping doesn't work for us. Judging shit-looking something if it's going to be successful is like trying to predict something that is mostly unpredictable.
     
  4. joe

    joe
    Original Member

    Joined:
    Sep 28, 2004
    Messages:
    420
    Likes Received:
    0
    okay, let's say you decided to write a game with an established mechanic and you know it will be fun: if you prototype the basic game mechanic you will learn about the bottlenecks and problems you won't think of BEFORE. so i think it absolutely make sense to write a prototype even if you definitely know what you finished game will look and feel like.

    Sure, at first you will invest time into work you will throw away later. But because of the things you learn during prototyping you can write more robust code later and will save a lot of time in maintaining your architecture and codebase.

    @MrPhil
    You don't like my English? ;-) I tried to improve the opening sentence. Thank you for letting me know!
     
  5. Olofson

    Original Member

    Joined:
    Dec 11, 2005
    Messages:
    270
    Likes Received:
    0
    There is another approach that sort of has the advantages of both worlds: Start out simple, with dummies and quick hack implementations. Apart from quickly getting a running prototype, you get some idea of the data flows, and what goes where.

    If/when you realize you're on to something, start refactoring! Instead of just throwing it all away, move things to the right places and clean up the interfaces. Basically, design the lower levels as you go! Use the prototype code as a test bed to see if the "real" parts actually work as intended, to avoid wasting time on proper implementation code that won't work, or won't be used.

    Of course, it helps if you have a natural tendency to clean things up, and a desire to make things as clean and simple as possible. I suppose self discipline and sensible set of coding standards works too. :)

    Me, I just can't remember stupid symbol names and inconsistent designs, so my code can't get all that messy before I have to fix it! A weakness turned into an advantage, I suppose. :D
     
  6. Applewood

    Moderator Original Member Indie Author

    Joined:
    Jul 29, 2004
    Messages:
    3,859
    Likes Received:
    2
    Seeing as you framed your title as a question, my answer is:

    "it isn't - you don't have time to do anything twice, so get it right the first time"

    There's a big difference between incremental tweaking and just writing out a formal prototype and then binning it afterward.
     
  7. Agent 4125

    Indie Author

    Joined:
    May 23, 2006
    Messages:
    193
    Likes Received:
    0
    It's another tool in the toolbox. There is a continuum between going full-blast on a project without questioning your assumptions or validating it in the real world, and endlessly noodling around on half-baked ideas that you never commit to. How you approach it depends on the project and what you think the risks are (wasting time on dead ends vs over-committing to a bad idea.)

    World of Goo is a great example of experimenting with a lot of ideas up front, discovering what worked with real users, and then investing a lot of time to develop a promising idea into a full product.
     
  8. jpoag

    jpoag New Member

    Joined:
    Mar 15, 2008
    Messages:
    806
    Likes Received:
    0
    I agree with this sentiment.

    Rapid Prototyping is certainly a useful tool, but as the saying goes: "If all you have is a hammer, then everything looks like a nail."

    For instance, I'm currently rewriting/upgrading my current engine/tool set and it's a completely different mind set than when I'm writing games. I know what design principles I want to employ and I know where I'm going with the code.

    Instead of prototyping, I'm using a "code"->"unit test" loop. Using MinCPPUnit, I can create small tests for code while I'm writing it. Smaller tests are easier to write than trying to debug a large system. Then, when all the smaller tests are out of the way, I can write a larger scale unit test to visually inspect output.

    Completely different from how I code games. (But I won't go into that)
     
  9. gormlai

    gormlai New Member

    Joined:
    Aug 23, 2009
    Messages:
    27
    Likes Received:
    0
    The thing about prototyping is that it is actually really hard to make good prototypes that tell you if a game will be fun, at least when you just start out doing it.

    I have an engineering background, and the first many times I made a prototype, I actually found it rarely hard to nail the 'feel' of a game. I also often found myself thinking that it would be much easier to judge the fun, if only the game looked better, I could better judge the fun. Today I believe that was the wrong conclusion, and was an easy way out for an engineering mind that needed to find focus in something as intangible as "fun".
     
    #9 gormlai, Jan 22, 2011
    Last edited: Jan 23, 2011
  10. Adrian Lopez

    Original Member

    Joined:
    Sep 7, 2004
    Messages:
    489
    Likes Received:
    0
  11. Roman Budzowski

    Indie Author

    Joined:
    May 7, 2005
    Messages:
    839
    Likes Received:
    2
    My experience tells me that you can't find bottlenecks and problems with prototype, at least for games that use proven mechanics. Incremental tweaking is the way to go for us. It saves as huge amounts of time. We don't do anything twice unless it needs tweaking. Since putting this mindset into life we reduced our development times a lot, mostly doing games in less that 3-4 months (and some as short as 7 weeks).

    I don't say experimenting is worthless, but I believe it can be done with pen and paper.

    cheers
    Roman
     
  12. Applewood

    Moderator Original Member Indie Author

    Joined:
    Jul 29, 2004
    Messages:
    3,859
    Likes Received:
    2
    Experimenting is NOT the same as prototyping, not even roughly.

    If you have a weird idea that needs a test run, then by all means write some quick experimental code and give it a go. But this isn't a prototype.
     
  13. Dogma

    Dogma New Member

    Joined:
    Oct 27, 2008
    Messages:
    52
    Likes Received:
    0
    For the game I am working on now, prototyping is pretty much vital. But we don't just mess around. We focus on two things:

    1) Testing different gameplay styles
    2) Creating a vertical slice of the game

    We need to do this, because we simply don't know what the best solution is to some gameplay problems. We do brainstorm the possibilities before we start coding, and then we code all of them. We keep the one that is the most fun or easiest to use for the player, and throw away the ones that aren't.

    We only need to do this for a couple of "innovative" parts of the game though, it is not like we are trying to invent a completely new game. I think that it is not bad to spend some extra time going through a number of possiblities.

    As for the vertical slice. We are focussing on depth instead of breadth at this point. So we only need two weapons, two enemies, instead of creating dozens of enemies first. But I think(hope) everybody does it that way.
     
  14. Applewood

    Moderator Original Member Indie Author

    Joined:
    Jul 29, 2004
    Messages:
    3,859
    Likes Received:
    2
    They do - it's called game development. :)

    I'm not advocating not trying stuff out as you go. Just that you should try it out in your production game.
     
  15. joe

    joe
    Original Member

    Joined:
    Sep 28, 2004
    Messages:
    420
    Likes Received:
    0
    If it's the first time you implement the mechanic you will find bottlenecks and problems - that's for sure.

    Of course, the more experience you have with a mechanic / game / concept the less value a prototype will have to you - and you won't need one.

    For example, if you are working on your 5th match-3-like game, a prototype makes not much sense, but if it's the first time and you've never done something like this before you probably think something like "a match-3? that's very easy!" - but you will fast find problems you didn't thought of (should the gamefield be locked during a swap / match, how to calculate which gems are entering the playfield...). And if you KNOW about those problems and you start right over you can write much better code.

    Sometimes if I look at code I had wrote years ago, I'm thinking, oh my god - you can solve those things much more elegant and more easily.
     
  16. joe

    joe
    Original Member

    Joined:
    Sep 28, 2004
    Messages:
    420
    Likes Received:
    0
    btw: I love the approach Olofson has suggested!
     
  17. Applewood

    Moderator Original Member Indie Author

    Joined:
    Jul 29, 2004
    Messages:
    3,859
    Likes Received:
    2
    Not getting your argument, Joe. I understand it, just don't get it.

    I set myself a challenge once to write a match-3 in a weekend when I was at my height of moaning about them. I came up against a few problems like those you speak of, plus a few more. And I solved them all after about 3 seconds of thought, probably just like everyone else punting them out. Sure, I didn't see it coming but once I did, it was only a minor, minor bump in the road.

    Pardon my frankness but really, if you need a prototype to stop worrying about "problems" at that level, then you're in the wrong business. A valid prototype testbed for me is for developing a physics engine or a complex AI solution. Somewhere you're genuinely not sure of how to procede past a complex problem that might take weeks or months to solve so you need to know before you develop owt else.
     
  18. Grey Alien

    Indie Author

    Joined:
    Nov 29, 2005
    Messages:
    2,797
    Likes Received:
    0
    I prototyped a match-3 engine back in 2005 and realised that there was more to match-3s than it first seemed. Once it was done it became my first commercial game and I gradually optimized the code and added new features as I made future games (those games didn't need prototypes, like Roman's games).

    If I was designing a new mechanic, a prototype makes sense. If I was coding an existing mechanic that was new to me personally, I'd prototype to get the feel right but probably just develop that into the final code (I wouldn't throw the prototype away). In fact I did that recently with a minigame at BFG and it worked out well.
     
  19. Dri

    Dri New Member

    Joined:
    Oct 21, 2010
    Messages:
    48
    Likes Received:
    0
    I do the same, I create a "prototype" that will be the base for the rest of the code.
    But I'm sure it shouldn't be called prototyping, it's just rapid iteration and agile development.

    Ideally a prototype should be something totally unrelated, to test problems beforehand in an isolated codebase.
    Iterating your prototype toward the final game is just rapid iteration, and is - I believe - more valuable than prototyping. At least most of the time, prototyping can be good for ultra-specific needs, like a new complex AI system or whatever.
     

Share This Page

  • About Indie Gamer

    When the original Dexterity Forums closed in 2004, Indie Gamer was born and a diverse community has grown out of a passion for creating great games. Here you will find over 10 years of in-depth discussion on game design, the business of game development, and marketing/sales. Indie Gamer also provides a friendly place to meet up with other Developers, Artists, Composers and Writers.
  • Buy us a beer!

    Indie Gamer is delicately held together by a single poor bastard who thankfully gets help from various community volunteers. If you frequent this site or have found value in something you've learned here, help keep the site running by donating a few dollars (for beer of course)!

    Sure, I'll Buy You a Beer