Game Design Thread and Volunteers

Okay, so, um, I've decided to finally get out of this creative rut that I've been in for a little while and do something I've meant to do for ages but haven't, for some reason.

I like to write stories, and I like to create strange worlds and creatures and aliens and so on and so forth. However, I also love video games and hope to one day design them. I can act/voice-act a bit, I have some very limited experience with 3D modelling and sprite work, and I can write stories/design things. I've also had training in business, finances etc.

Unfortunately, I cannot compose music, nor can I draw, nor can I program.

So, here is a proposition. I am looking for volunteers to help me on a game project: nothing absurdly huge and I have several projects that could be done (either the project we work on is small, and it gets done completely, or its big and we just create a prototype/demo etc.). I'm not planning to necessarily any money off of this, at least not immediately: these projects are intended to...

1) Develop experience for all involved, and...
2) If the project is big, use the prototype/demo as a basis for gather more support/funds.

First, however, I would like to know which of these projects people would like to help me with:

• A 2D stealth platformer in the vein of Metroidvania games, where you mainly avoid enemies rather than fighting them. You play as MOTHER 0028, a kind of nomadic spaceship/super computer, when one day something causes you to crash on an uninhabited desert planet: using a robotic drone, you set out to find the cause of the trouble and rescue the mostly brain-washed crew. I haven't thought of a decent name yet, but it'd probably be relatively short: maybe about four big areas to explore (ship wreckage, desert wastes, underground caverns and facility) and about six or so important upgrades and a single 'boss fight'.
• A visual novel/adventure game where you play as a primitive human who essentially gets abducted in order to make contact with various more advanced alien races and save the humans from some sort of cataclysm/invasion. It'd be essentially part visual novel, part puzzle game and part RPG: stats would affect various non-combat related things, such as which places you can visit or who you can convince to join you. The overall project would be fairly large and complex despite the lack of 3D graphics, so I'd mainly just want to finish a short prototype/demo.
• A 'racing Mon RPG', since I now remembered that I started this: [1] thread and didn't update it, tsk... Anyhow, turning that project into a short prototype would be amazing, if anyone would be interested...
• A 3D character based puzzle platformer in the vein of Skylanders and Lego Star Wars, albeit using all kinds of strange (but still hopefully relatable or interesting) aliens as the protagonist. Characters would have various abilities, sometimes with a degree of cross-over, and the player would use teams of characters to solve problems (I bet you didn't guess that!1!). Again, too big to complete with a small team of volunteers, but a prototype? Doable, I like to think...

So, yes. I'm hopeful that people will be interested, but I'm not going to plan everything from now on around it. If anyone wants to help (and I sincerely hope you do), please comment here. All skills are welcome, but especially things that I'm terrible at myself (modelling, sprite work, music etc.)

edited 27th Apr '12 9:01:25 AM by Eventua

STEP 1: Actually develop an idea and write a full Game Design Document.

STEP 2: Prepare NDAs.

STEP 3: Go on an actual game development forum and ask.

A suggestion from someone currently working on a game: Avoid 3D unless you have deep pockets - newbies to modeling and animation won't cut it for most players (people will complain about stiff animation, you may not have the right polygon count, insert huge list of problems here). Also, if you want to do something big, it's easier to find good help if you have experience with completed projects, especially if you're not paying up-front. So I recommend you focus on whichever game seems to be the easiest to create from that list. To be perfectly honest, nobody's going to pick something from that list, since you yourself don't have any focus when you're asking for help.

edited 27th Apr '12 6:46:47 PM by burnpsy

...

Okay. I will do those things, then.

The best game anyone can develop irrespective of scope will have a gameplay system that is both simple and versatile. If you can combine those elements, some of the game almost makes itself and you can add inherent replayability. Something that can provide this with relatively low labour is probably something like a grid-based tactical RPG. Simple maps, simple units, you don't need a huge, diverse array of animations — most of the work is in the actual design of the system itself.

Remember that all grid-based tactical games are more or less Chess with a new coat of paint and same house rules. This is good because such a simple, versatile setup helps you get maximum mileage out of a minimum of actual content. A big issue with a lot of AAA titles today is that a lot of work will go into game assets when some of it will only be used minimally, reversing the equation and driving costs up. Keep everything on the level, focused and with particular principles in mind.

Yeah, I fancy myself a bit of an 'ideas man' sometimes, but that area is kind of oversubscribed at present, and if you want any help you're going to have to bring more than just a good idea to the table. Having a clear vision that you have bottomless confidence in is essential, not to mention the energy and organizational skills to keep the project on-track, come the hell and high water which WILL assail it.

I don't know if you have, but if you haven't, find some other projects to help with first, just to familiarize yourself with the process, and build up a portfolio.

I'd also strongly advise you to get at least some programming skills - this isn't actually as big a deal as it sounds. If you know exactly what you want to happen, you're halfway to being able to program it already. The rest is mostly just looking up tutorials and reference docs, and getting your head around Object Oriented Programming. Generally the less original idea the easier to program because there's plenty of templates and tutorials to leech off of. For a basic 2d platformer, find the right template, and you'll barely need to program anything.

edited 28th Apr '12 3:43:28 PM by Kesteven

I'm no great shakes at programming, but I've got bits and pieces of experience and my own conclusion is that a lot of game programming is logic tricks. A game itself is kind of tricking a computer into providing a gaming experience, and mechanics have to be constructed with that in mind. And on a level not so deep, a lot of stuff won't be programmed as "literally" as it appears in the game.

For instance, in a JRPG style thing, you might have a party that looks like

Tom = 0
Bob = 0
Alice = 0

So all the characters are set up pre-game. At the beginning of the game, it might become:

Tom = 1
Bob = 0
Alice = 0

Since 1 is a true value. But even though Alice might not appear as a playable character until the final act, the game still keeps track of her from the beginning. By organising data like that, though, where the characters are attached to commands that retrieve their relevant data, you keep things really organised. If you wanted to create a 2D, top-down RPG, most of the legwork is really in this kind of thing. Once all the databases you're drawing from are established, most mechanics-based stuff should be a series of fun, puzzle-like experiments in comparison.

edited 28th Apr '12 5:50:27 PM by MadassAlex

Depending on the language and framework, a lot of programming is practically as simple as 'if (spacebutton.down) player.shooting = true'. Once you know the syntax and objects it's as easy as writing a sentence.

The actual challenging part is keeping everything organised in your code and more importantly in your own mind. Often projects look easy to begin with and things go great but then when you have some code down you forget where you're going with it and what your variable names are and that's when things get messy and difficult and people tend to start giving up.

The trick is in compartmentalization. Keep everything very neat and very segregated; know exactly where and why each bit of a project interacts with every other part, and 'black box' as much as you can. Even if you're not planning on doing any programming at all, if you want to manage a project I think it would help a lot to know the theory behind this stuff and why it's so important.

Code Complete by Steve Mc Connell is a beast of a book with a lot of in-depth stuff you don't need to know, but it's widely respected, newcomer friendly, it's not too difficult to acquire a pdf, and there are some chapters that you might find extremely useful. Otherwise just have a look at the wiki articles on 'encapsulation' and 'information hiding'.

edited 29th Apr '12 4:09:28 AM by Kesteven

One thing that might be worth considering is keeping a Notepad or Word file with all the variables, their names and what they actually are via description. Choosing short, descriptive variable names is a good general idea, too. This should be pretty straightforward for most game variables (the HP variable can be "health" in the code, since two character variable names might get more lost or confused), but as mentioned above, this can get difficult to track if you've got a more complex system, a bunch of gear, ect. One idea is to take the vowels out of certain nouns to shorten the variable title while giving it distinction. "Vorpal Sword" might become "Vrpl Sword", where "Sword" is the full-written visual-text cue in the code for actual code review and "Vrpl" is the modifier.

The thing about coding is that code is perfectly intelligent, it just doesn't understand context. So you have to enforce your own intellectual context on the code by putting it out with pure logic.

There's this programmer joke I really like:

Terrible delivery aside, this is how a computer thinks. Because the wife didn't specify what to get a dozen of, the husband took the initial variable (bread) as context. So the command therefore goes something like:

Buy bread = 1
IF eggs = true,
Buy bread = 12

When what the wife wanted was:

Buy bread = 1
IF eggs = true,
Buy eggs = 12

To a computer, though, her words would result in the first set of commands rather than the intended second.