ID:1595898
 
Keywords: requirements
How do you define the requirements of your game?
Usually in words.
What do your words- an obvious style of communication (may also use pictures.) usually talk about? I'm concerned about the ideology you may use. Preferably if you actually have games here. Otherwise I'm just going on what you say- undesirable but manageable. Telepathy, nice but seriously what format do you use in your pre production process?
I like to try to use sentences
As a single dev, usually a one or two line "mission statement" if I ever need it written down at all.

"[Game Name] is a top-down strategy game, focusing on unit building and rapidly expiring alliances between players in a round-based format."

That pretty much tells you all you need to know, and if you dream up a feature while you're coding away, and want to sanity check, you can come back to the mission statement and ask yourself "Does that idea make sense in this game?".

Big requirements gathering exercises are large multiple developer (5+) team things, don't bother with it as an indie.
I'm gonna be honest here, and pop my mod hat on. The kind of answers you're getting (both here and in other topics) are largely a product of how lazy the question is, your past questions (and their laziness, similarly), and the lack of apparent development you seem to do following these discussions. I am not alone I think, in being rather sceptical of your development intentions (or even topic intentions), and wary of putting the effort into a proper reply accordingly.

Moderatively, your topics look like fluff at best, and discussion troll-bait at worst, and have done for a while. Your key does you zero favours, in this regard. They are always topics I'd expect to be ultimately down to personal preference (like this), or something you can expect to be contentious on the forums ('good ways to climb trees as a ninja, a totally not Naruto ninja *nudge nudge*').

Without seeing a sense of development from you, or at the very least elaborating your problems in terms of verbose, detailed, concrete examples from the game you are currently developing, I'm going to start deleting these kind of topics of yours going forward.
I disagree, I think making clear requirements of a game is necessary for fast and efficient game development. Also, Simon Allardice seems to think it's essential to object oriented programming. He mentions there are many ways to acquire requirements, so I was wondering what everyone else did, if they did anything at all to gather requirements. Extra credits makes it seem as most don't gather requirements before building but wanted to be sure?
Simplicity is not laziness- quite the contrary. It's efficient and well managed.
Simon Allardice did big corporate, safety systems and low level API work for most of his 25 years, his working experience is pretty much the antithesis of indie game development.

You need big requirements documents in his contexts, and huge specs. Same way you need them in air traffic control, or 40+ component TV systems, as I've worked it.

You sure don't need the 200 page requirements document in a prototype friendly, single developer indie context, like ... say, BYOND. Because in the time it takes you to write the document (which is probably wrong and not self-consistent, like all requirements documents of size), you could've prototyped it in BYOND, and played around, and determined if it made any game sense to have.
Simon Allardice says you don't need to make the requirements that big, but approach from an agile development approach- so an ongoing basis. He actually doesn't promote fluff but what is just the bare amount to move on to the next process.
So ... a mission statement?
But your point is clear and I think most don't support the planning process if big heads like you are telling them not to. You can delete this topic or whatever.
Lord knows, the planning process is /all/ some people do here. I think I've read as many design docs for games that have never seen the light of day, as I've played games abandoned in favour of a remake that was never released at this point. No more true has that statement been, as when it comes to anime fangames I've seen.
Yeah, I've encountered a lot of what Stephen001 has, and it's definitely a serious problem around here. I almost fell victim to the remake thing a few times.

I've looked into the whole planning thing, and I've found that it really is only beneficial if you're not working solo. Even then you have to keep it simple, and straight to the point. Nothing too extensive.

When it comes to solo. I like to do similar to what Stephen001 suggested. I'll list the name of the project if it has one, a short description of what it's like, and leave it at that. Then when I get to actually working on the game, if it seems worth pursuing, I might make a list of systems or major features that I need to make just to be able to remind myself and scratch things off as I go.

Then I can go into smaller, broader things to start finishing the game, move on to polishing, etc. This is just what I personally do, and I don't do the list every time; just sometimes. I might not seem like the best person to hear from since so little of my work is currently visible, but I've done a lot behind the scenes, and I've observed many others.

TL;DR

A little planning is fine. Such as a short description of each project you may create, or a to do list for the game you're creating, but for the most part just go for it. Too much planning is the downfall of far too many people on BYOND. It'll get you more words than progress and completed projects.
Well, there's two sides to it. I began working on a design document, mainly to write down my plans, but also to make sure I knew roughly what I wanted it to look like.

Mid-way I quit and began coding. Which is pretty much what has been my hole in the ground, being all "Hey, this seems nice, lets add it!" and eventually being left with no purpose.

Soo, my advice, if you are someone that wants to get to work quickly, and are a bit quick to lose focus.. Try and write down at least something of a plan. I should've done it, but failed to finish it due to impatience and stupidity on my end :P
Well, that's the mission statement.

By the sounds of it, your issue wasn't one of not correlating the requirements, but one of not critically analysing the ideas you had at the time, against an overall mission statement.

I assure you, you can still write a full an exhaustive set of requirements off the back of "Hey, this seems nice, lets add it (to the design doc)!", and still end up where you were in dev, because it's not the form of design that's the problem.

With the mission statement, you go "Hey, this seems nice, does it fit the mission statement?" and consequently, you naturally evaluate the priority, going "Yeah actually, that makes a big difference on my aims!" or "Mmmm, it's not really relevant ... nevermind, I'll come back to that later / not do it."
A mission statement in of itself doesn't specify point of view or design concepts. For that you need "exhaustive" planning. This plan should result in manageable self sustained pieces that form a project.
It gives you overarching objective, by which you can evaluate the rest. Given the turn-around on writing code versus design documentation + code, you can pretty well prototype, play and see if a design concept works quick enough, and ditch it or keep accordingly.

You can very comfortably (and most do, on BYOND) write an "exhaustive" plan for a game that's ultimately a bore, or misses it's mark. Much of the point is the ideas you come with are just that, ideas, not requirements. You requirements are the game must be fun, and meet the overall arch-type you laid out in the mission statement.

The rest is essentially free to fluctuate depending on what works in the prototyped "I'm actually playing it now and this mechanic feels pointless given the other stuff / purpose of the game" real world.

Much of the documentation you'll find online regarding game design documents (even if you throw "indie" into the mix) either focus on a pitching approach, team communication, or include engine considerations that you just don't have in BYOND.

Ordinarily, they'll dedicate a paragraph to mission statement / intro, a paragraph or two to "what's the vague gameplay gonna be like" i.e you're gonna have driving sections, or it's round-based shooting etc, a small section on art direction to basically show off reference art so you can remind yourself of the vibe you're going for when making art, inspire etc.

Then you get all these "Well I need a 2D renderer, day/night system" type stuff, which either 1. doesn't apply in BYOND as it's given to you or 2. like the day-night example is in practice about 10 lines of DM, then tweaking according to your play-testing.

This is where someone like SuperAntx is useful to speak to, or WritingANewOne if you want to discuss counter-cases, as we discussed this in BYOND Anime back in 2010, and discussed the level (or not, compared to the 'big' fan-game RPGs in production at the time) of prior design that went into Decadence, and the development and design process. Decadence released, the fan-games didn't.

Prototype, iterate.
Yes you need to know how to plan for a plan to be effective. There is currently a reliable source for learning to plan right.
I look forward to seeing that.
Page: 1 2 3