Prototyping for beginners

edited in General
With all the talk about prototyping lately I began to think about prototype cycles, specifically the time investment into a specific prototype. Because I honestly want to become a great prototyper, but at the moment I'm struggling to figure out exactly what it means to prototpye something. I did some searching and found this article over at Gamasutra:

How to prototype a game in under 7 days

It's not exactly a how to guide, but I feel that it makes some strong points on how to prototype.What was interesting about the article to me where the two constraints they put on themselves.

What are your thoughts on things like time and team investments on prototypes. Also how much assets do you create for a prototype? And another thing, do you balance time learning a tool vs actually creating the prototypes?
Thanked by 3Tuism Karuji edg3


  • Really cool article. Personally prototyping is my favorite part of making games.
    It's funny how my games that I plan out on paper usually end up being way more complex than the prototype or even the final game for that matter.

    Making games quickly also means to don't come to the point where you fuss over all the little things that dont matter and ruin the bigger picture in the process.This happened to me while making fling fu.

    Thanks again for highlighting this cool article :)
  • Oh good lord! The Experimental Gameplay project will never die!

    Learning what's important and what's not is best done with practice and the 7-day constraint and even the 48-hour or 8-hour dev jams are a great way to do it!
  • I'm constantly being reminded of how I should make quick prototypes :) Very good article. A good reminder. And a great model we should be following with our own comps! The pixel art comp echoes a lot of this stuff :)
  • Personally I think the most important thing with any prototype is knowing exactly what it is you're testing. That way, if you're spending a lot of time on something you can take a step back and ask yourself if this is strictly necessary in order for that test to work.

    That and maximum sarcasm.
  • Right, so what I'm getting so far that this is a fuzzy beast for everyone with words like "quick", and "little things". I guess it is really situational and it's(like @aodendaal said) something that you need to practice and get better at.

    So let me rephrase the questions I have a little bit. Let's say I am totally new to game dev(any aspect), and I don't know any tools or much of game design theory. How should I approach prototyping? I think that this situtation is a major source for largely useless design docs. Anyone(that can read/write) can create a design doc, and it does give the perception of creating a game.

    I know that you can create things like board games and card games which is probably where everyone should start and probably never stop creating one every now and then. And I probably just answered my own question :/ ...but anyway, thoughts?

    PS @dislekcia...Really? Are you sure...? :P
  • When @dislekcia says maximum sarcasm, what he means is to use placeholders for EVERYTHING. It took me a while to understand that. I still disagree with the semantics but the principle is sound :P
  • edited
    Well I can't say it much better than already has been said.

    If anything has been left out it is this: The best/only way to test your implementation of your idea is to get people other than yourself to play it.

    When we do a 48hour jam the rule of thumb is that people should be playing some part of the game on the first day, otherwise the eventual game will probably suck (because we'll have spent all that time implementing and we won't have iterated on the idea at all).

    Because the odds are that the idea that we had at the start, the way that we had imagined it, that was untested and based only on our mind-thoughts, was awful.

    So when prototyping get your prototype to a testable state ASAP so you can start iterating on it (assuming the idea doesn't prove to be utterly fundamentally flawed).

    Obviously some things are hard to prototype quickly, like skill tree progression for a 14 hour RPG. (In cases like this one might have to resort to building a redacted version of the idea if you want early feedback.)

    I'm not sure if I'm being clear. I mean, a prototype doesn't end with testing the idea,it definitely shouldn't end if it shows potential and there are still significant possibilities/questions surrounding it. Make something that can be tested, play it, get other people to give feedback, remove things that don't work, or improve them, or add something or refine something and start the cycle again.

    I guess what I'm saying is that I see prototyping as an evolutionary process. Mutating something, evaluating it, and culling what sucks over and over again. I don't see a prototype as a project, where time and team investment are important considerations, it's a journey to an unknown destination and each step of the way is an experiment that might fail.

    I mean, it sounds a bit directionless I guess. But that is why some people use phrases like "Finding the fun". Or "Uncovering the nuggets of golden enjoyment embedded in a shitty palimpsest of shitty ideas".

    You mention design documents...

    Approaching it from the point of having a design document and implementing whatever it says in the document is anathema to prototyping.

    I'm saying that design documents are not only superfluous, they can be harmful. Certainly in a prototyping situation where the goals are unknown and giving your team a false sense of achievement while ticking things off a list, while cannonballing towards a thumbsucked goal, can only cause problems.

    I mean, planning is not a bad idea in principle, and you may have to do some planning to complete most games. But, when it comes to prototyping, if you aren't being playful, and considering other possibilities, and just trying out stuff, all you'll manage to do is implement the idea you had at the start that was totally untested, and so your probability for creating something people like is lower (not zero, not negative of course, but lower, which is bad when you're trying to get the most value from your time).

    I'm saying that design documents are good for getting stuff done, but not for being creative and flexible and exploring. And unless you are a developer of significant experience chances are that you will need to explore a lot of possibilities before you find the golden nuggets embedded in the shit.
  • @BlackShipsFillTheSky,you are being as clear/unclear as anyone here basically. :)

    In my opinion prototyping is the best way to develop games or anything creative for that matter. It gets you to a point where you find something that you enjoy working on that other people will appreciate. That is why I want to become better at it.

    But it feels like there is a very fine line when doing rapid prototypes. You have to have considerable insight into when to blow up an idea and persue another avenue. In my mind the "bad" prototypes need to be destroyed as soon as possible to avoid making too big of an investment in them. What I'm trying to figure out here is how to get better at destroying stuff sooner rather than later. Or put another way, not to invest too much time/effort into ideas that will eventually be killed of anyway.

    Getting other people to play as soon as possible is probably the best way to assess the viabilty of an idea/implementation. So I'll try to push my prototypes on more people, people that will hopefully have the decency to tell me the truth about what they think.

    But yeah, looks like it's really dependant on what you are trying to achieve and then making the correct judgments. Which only come with experience. So I guess I'll just make as many prototypes as I can until I can make prototypes :P
  • edited
    @Rigormortis Yeah that's the approach. The solution is somewhat tautological, in that the approach to learning how to prototype is to prototype it through prototyping :)

    And yes, without a heck of a lot of experience it's impossible to test anything without getting input from outside sources. Part of the goal of getting players playing your game is to understand the divide between the way you see your games and the way others do, and through experience to close that divide so that you can prototype faster.

    I can't stress enough how important getting players to play your games is. There are so many skills that you can only learn through getting that feedback. It's too easy to trundle along assuming you are a game-dev god, receiving no feedback and so adversity, and so learning nothing.
  • To put what I said about having a specific goal for rapid prototyping into perspective, here's an example of an idea I've been messing with for a while now:

    The game idea itself is a real-time 2-4 player iPad tactical paint-based area control game. I'm fascinated with same-device multiplayer and what that means in terms of controls and gameplay considerations. I've had a rough design for this particular idea knocking around for like 4 months now... It's gone through several "Hey, wouldn't it be cool if-" mutations in my head already, each time that happens I'll dedicate 5-10 minutes to capturing the core of the idea on a piece of paper so that I don't have to remember it. Because I never remember it all perfectly anyway.

    But I didn't start prototyping it because the core mechanic, the territory control idea that was the "Aha, maybe there's something in this" moment when I was first rolling the thing around in my head, wasn't something I felt I could implement smartly. Except now I think I have an idea on how to calculate covering space with a general purpose algorithm, so now I have something to prototype.

    The whole point of the prototype would just be to test out that alg. See if I can get it working like I want it to, all the actual painting will just be mouse-clicks. Then, once that system either works or doesn't work, it'll be on to the next phase. If it works, testing the different player input methods I have in mind. If it doesn't work, back on the shelf :)

    Maximum sarcasm: Is essentially a tactic for optimising effort spent by making sure you're not wasting time painting the fence before you know what colour it needs to be. The trick is to think sarcastically when you hit a time-intensive problem: "Shit, now I need fully animated models to get to the next part because otherwise how are players going to know that they just opened that door?" ... "Hah! Just have a door opening sound and then I can stick with these stupid cubes. That would actually be funnier if I said the sound and then put that on the screen in text 'Creaaaaaaak!'" Boom, saved yourself like x million hours of work that wouldn't have helped you test your prototype's main goal.
  • edited
    Maximum sarcasm: Is essentially a tactic for optimising effort spent by making sure you're not wasting time painting the fence before you know what colour it needs to be. The trick is to think sarcastically when you hit a time-intensive problem: "Shit, now I need fully animated models to get to the next part because otherwise how are players going to know that they just opened that door?" ... "Hah! Just have a door opening sound and then I can stick with these stupid cubes. That would actually be funnier if I said the sound and then put that on the screen in text 'Creaaaaaaak!'" Boom, saved yourself like x million hours of work that wouldn't have helped you test your prototype's main goal.
    Use placeholders for everything :) Ever :) Even sound effects that help understanding. Stick text on it that says "door" if you have to :)
  • Tuism said:
    Use placeholders for everything Ever Even sound effects that help understanding.
    Almost like the riveting sound effects in my SCHMUP :P

    @dislekcia, thats something I need to work on as well. I tend to try and mangle an idea until I feel that it works instead of playing around with certain parts about it in my head. And I also need to write stuff down more often.

    @BlackShipsFillTheSky, are there any "go-to" places(except here of course :P) where you would try to push your games for people to play? Basically a place where you get good feedback but also lots of exposure?
  • @Rigormortis: If you've got a web-playable build, Kongregate is good. Although they do have a penchant for flash-based games. Um... You could always ask for players on Reddit? Generally I just wait for a prototype to be so much fun that it "escapes" here and gets coverage somewhere else. Like what happened with DD, although I do realise that was a unique situation.
  • I don't think our little community facilitates "escapes" by itself... Like, Broforce, if it were only posted here, do you think it would/could have "escaped"?

    One of the reasons I personally believe we should ramp up to a more generalist approach that's friendly to non-frequent users :)
  • @Tuism: Ninja Crash got covered on without an email from anyone here... Personally,I like the idea of breaking-out being a function of how many people genuinely love your game. It doesn't matter HOW it breaks out, be it twitter mentions, journalists looking for fun games, whatever. Just the fact that it has is a really, really good sign.
  • @dislekcia, yeah...thats kind of what I thought of before I asked the question. It's not so much as telling people "here is my it". It's creating that thing that they ask you for.
  • @dislekcia I totally agree, a good game will spread by itself, and should be what we all aim for :)

    But does that mean Ninja Crash "escaped" cos someone from indiegames browses our forums regularly? Or was there another channel through which they saw it/heard of it? That's my point. If the former, then effin' awesome and I shall keep quiet :)
  • edited
    DD got punted to by one of the Game.Dev users (DukeOfPrunes) if I recall correctly.

    With regards to place holder stuff. Sometimes for us the thing we're prototyping is the look of the game. So obviously maximum sarcasm is case specific, quite often I employ placeholder code to get art going right.
  • placeholder code to get art going right.
    hahahha!! That I need to do more :P

    (if you saw the moster I'm working on now you'd bitchslap me upside the head for breaking every rule above. Am making more coloured blocks :P)
  • edited
    TBH I we don't really use maximum sarcasm very often. So much of what we do is about the feel of the game, and placeholders often hold back the thing we're trying to test.

    The point really is "Don't spend time on things that aren't what your game is about and don't get you closer to being able to evaluate the idea you are trying to test".

    And this is especially important in game development because the complexity of the game negatively affects the speed at which you develop it. Compile times increase, times spent searching for assets increases, bugs get harder to track etc.

    And, obviously, a placeholder is MUCH faster to develop in the first place.
  • I think whats @BlackShipsFillTheSky is saying is a good point - the feel of a game is something that that can defy the prototyping process.

    I'm not saying prototyping isn't a worthy endeavour - god no! But how do you really test those intangibles that really don't make themselves felt until a lot of craft has been put in: platformer controls for instance - makes or breaks a platformer! Or that video about juice: simple break out clone goes from boring to fun due to features that have no place in a prototype.

    Also I think that maybe sometimes art work can be the motivation you need to actually work on something?

    Anyway, i've found game jams and forced deadlines do absolute wonders for me - still struggling to replicate this success when not working within a set of constraints.
  • I'm not saying that the feel of the game can't be part of a prototype.

    I'm saying that when working on a game idea that relies on juice the feel of the game is part of the idea that must be prototyped.

    (Although that's a matter of semantics, as in what's a prototype and what's not. I consider anything that's an unknown before you implement it to be a prototype, and for me the feel of the game is usually a big part of the question that needs answering).
  • I finally got around to reading the article, and they mention how art and shine can't save a game but, that it can still be important. I think they really said it better than I was trying to say ;)
  • Anyway, i've found game jams and forced deadlines do absolute wonders for me - still struggling to replicate this success when not working within a set of constraints.
    I have exactly that same problem. Work on anything outside of game jams is really slow at the moment for me.
  • edited
    To be clear: I'm certainly not arguing against Maximum Sarcasm. I'm definitely saying use as much sarcasm as you can. I'm just arguing against the idea that might have been conveyed that placeholders can be used indiscriminately (in case that idea was conveyed).

    I'm just saying there are times when, even in a rough prototype, the art and shine cannot be sarcastic. It depends what the thing you're trying to test is (like @Dislekcia said, knowing the goal is critical).

    Like: I often consider a mockup of the art of a game a prototype. Obviously there you can't avoid art. But you can move things around in photoshop, turn layers on and off, and make sound effects with your mouth (like a puppet show) to simulate the programming.
  • edited
    Also, it is possible to perma-jam. If you're prepared to shunt real-life to the side.

    (As I understand it.) The main aspect of jamming that gets lost as soon as you set your goals on a final product is the anything-goes aspect (that and distractions). Assuming you aren't spending your time on facebook or makegames, all of the increased development time in normal production comes from agonizing over decision and fiddling with details.

    And you can avoid all of this by just not caring.

    I'm not saying jamming means making crappy games, just that you walk into a jam with the skills you've got and use those rather than trying to improve (beyond whatever is absolutely necessary). The introspective learning phase only happens after you stop jamming.

    If you want to jam something it helps to remove yourself from your usual environment. Agree with a friend to have a jam for a day or a couple days (on whatever project you like) and take your computer there and support each other. It's super fun.

    (I should jam more)

  • edited
    There was an article on lifehacker - be more productive. Become unreachable :)

    I think besides the "mindset" of rapid prototyping, that's a really important part of a Jam. You go into that space, you do that thing. You got all these people around, with whom you're less likely to facebook and browse forums, and that simply makes you more productive.

    It's like gymming. People don't go to the gym cos they can't exercise anywhere else, it's so that you are forced to exercise. Much like at a Jam.

    A real bro pumps iron at home no problem :) so does an experienced GM (game maker). Of which I ain't yet @_@

    On tha note, @Nandrew you're my hero. There are other heroes around here, but he's the only hero who's put up like 4 prototypes in the last like 2 months. I think. Whew.
  • I'd love to do a jam exchange program in Cape Town.

    Every 2nd week end or something the jammers involved swap venues or something. Free Lives visits (insert cool people) and then the next event (insert cool people) visit Free Lives.
    Thanked by 2Rigormortis Nandrew
  • @BlackShipsFillTheSky, that is such a cool idea. I would love to take part in something like that. Any one up for it this side?
    Thanked by 1EvanGreenwood
  • I'd give it a shot... Though when I start working (you know, a day job) it'll be much more difficult. Plus I got no coding mobility just yet. And as for a venue, well... @Elyaradine... Luma? :P Or Microsoft again/as well/instead?

    Dunno, spitballing :)
    Thanked by 1EvanGreenwood
  • From the times I've asked before, Luma's rather sensitive about letting people in. Dave at Microsoft's been super keen to help with hosting jams though. We just need to let him know a little while in advance so he can book, at which point we can have a conference room for the whole weekend if we wish. The (tiny) downside is that the place closes at around 11pm and opens at 9am (or something like that), so for stuff like 48 hour jams, you get more like 28 hours if you don't work also work at home.
    Thanked by 1EvanGreenwood
  • I'll see what I can do at my place. We have a ton of open space since we just converted our old factory into a house. So I can check on that for a JHB jam.
    Thanked by 1EvanGreenwood
  • edited
    Dooo it!

    I've done it a couple time with just working on my current project. Stuff gets done! (And prototypes of new ideas are priceless of course).
  • Ya,Ya,Ya! Maybe we can put it on the agenda for the next meet up and find out if there are any more people that want to do something like this?
    Thanked by 1Tuism
  • edited
    if there are any more people that want to do something like this?
    Ye, am super keen for this. Been so busy at work lately, need some inspiration and motivation to keep me in the game.. so to speak.
Sign In or Register to comment.