Prototyping for beginners
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, tools...how do you balance time learning a tool vs actually creating the prototypes?
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, tools...how do you balance time learning a tool vs actually creating the prototypes?
Comments
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 :)
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!
That and maximum sarcasm.
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
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.
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
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.
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.
@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?
One of the reasons I personally believe we should ramp up to a more generalist approach that's friendly to non-frequent users :)
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 :)
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.
(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)
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'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 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'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.
(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)
http://lifehacker.com/5953914/how-being-unreachable-makes-me-more-productive?tag=productivity
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.
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.
Dunno, spitballing :)
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).