How do you guys get started on the game code

[vikun]

Been coding some games in javascript for about 3 months. So far: an angry birds ugly clone (really crappy, using box2dWeb), a shooter like sonic wings (way smaller, though), and some simple games like pong, breakout and a simple endless runner with no sprites, just using rect and arc to draw. 

 

I've been experimenting with ways to plan the code, and realized that I output more and finish things quicker if I don't actually plan anything at all: just sit there and code, and deal with problems as they occur.

 

Do you guys do that way too? I guess maybe because all games I did were small ones this works. Maybe for bigger ones it will be  a mess, even though the code I write is usually clean.

 

How do you guys go on about planning all the functions, objects and interactions amongst your games? 

[rich]

I mostly tend to just iterate. So I too will sit down and just start coding. When it gets to a certain point I'll refactor, maybe split the code up into different classes (depending on the game). Maybe consolidating functions, optimising here and there. But essentially I'll get it up and working first as a priority and then tidy it up after the fact - never the other way around. I much prefer to work iteratively, I find it more natural and to be honest always have done, even when leading large teams of developers. I find it's the best way for emergent game play features to happen. Very often we would have a clear plan of what the game will be up front, but the path taken to get there is more flexible.

[vikun]

Yeah, I guess that's the best way and probably the one that works out for most people.
I was just wondering because maybe there was another way that was generally more agile than that, but I guess not!

[rich]

I think that way is the very definition of agile.

[JUL]

How do you guys go on about planning all the functions, objects and interactions amongst your games? 

 

If I had to do it all over again (the only game I've finished, from presentation page to end credit), I would start by the money making system, then build the rest of the game around it, not the contrary.

 

 

Also, I've lost a lot of time by deving a game concept (adventure type) and then half way into it, changing my mind and turning it into a simple "rush and kill arena" type of game.

I hadn't a clear idea of the end result when I started.

Funny thing is that I'm now deving the story mode/adventure part...

 

I also divided the game into seperate files in the begining, a la flash AS3, class system.

Weapons.js, World.js, Characters.js, and so on.

 

After a while I found it more convenient to simply code everything into one single file with all assets stored into one folder, called "assets", instead of assets/sounds assets/images assets/youNameIt.

It's probably not considered as the best practice, but for "everyday use", I just find it more convenient.

[mattstyles]

In terms of methodology, I'm with Rich on the iterative agile thing (clients at work are even coming to us asking for it, which is pleasing!)

 

I rarely go fully blank page to start with, not for anything non-trivial, I'll at least have a basic idea of how the major components will fit together (if I'm using some kind of framework, those major components and their bindings are often already solved, saving me some brain cells).

 

But any plans are high level at best, if I go into too much detail too early I'll often feel stuck by those decisions, but, often, I'll have far more information to make decisions later in the process so shouldnt be stuck by decisions made earlier with less info/direction.

 

It's not until later that I find some strucure or a scribbled roadmap helps, even with multiple developers.

 

In terms of how I actually structure a project: I'm heavily into modular components, I use browserify to get access to commonjs modules (kind of lets you just include, or import, other files into your project, kind of, its a fairly basic and straightforward module system), preferably extracting modules to their own projects (where they can be coded in isolation, and tested that way) and then the main game/app project becomes composing those modules and adding any specific logic. In terms of how this plans out, it sometimes starts all in the same file, then gets extracted into different files, and gets further and further broken down as components become complex enough to warrant their own file/directory. I actually have a number of scaffold/seeds that already set up much of this, but the constant breaking down and grouping of functionality is the same.

[bruno_]

I start always with a sample of what I need to do.

 

I make every piece I know I will need for the game, when I have every pieces I think in the best way to organize them and do that - Basically if it's something all games could use it goes into a separate part (or module), if it's specific to that game it goes in the main game part.

 

Then I join everything for the final version.

 

The first game is always harder to structure, in the second you already have a base strucuture that worked for you.

[sandudhate]

I am with you, guys. Its best to get on with the idea and solve the problems as you encounter them. I think you don't need any planning until you're working on something as complex as FIFA or you know.

[Firenibbler]

You normally just plan as you go, altho some exceptions i like to use for this rule when I program, is if it is a massive or complex game, or if you have multiple people working on it.

[b10b]

I'll always start with a Game Design Document.

 

It doesn't have to be grand, but should include a quick section for each game scene / state, the purpose of each, the main features of each.  At the start of the document will be the primary mission, which usually involves referencing other games, moods & style, assets, and some playtime!  At the end of the document is a schedule, costs and risks (e.g. anything that needs a proof of concept side project).

 

Armed with that, I have all the nouns and verbs needed to describe the game, and so the initial architecture is complete.  Within minutes the classes and primary methods are established (helped because I use the same design patterns project after project), and from there on it's iterate and refactor (a lot) until complete.  For the sake of an hour or two I believe it's well worth it - else, without a GDD, I'd be chipping away at the same piece of rock without any idea of the cathedral I'm supposed to be building.

[rothers]

I have always just started coding when I feel 'it'. Some of you will know what I mean, you just know you are ready to be very productive and ideas will fly and thing will go well.

 

If i'm 'forced' to code then it can be a messy disaster.

 

When I'm in the mood I can make the code compact, flow well and work quickly. Some times if I design and plan ahead too much it is not so good.

 

It can be a bit of an art coding for me, I have on and off days.

[Rudrabhoj Bhati]

I see my game as a well organized system of  objects, fully isolated from each other and use the main Control object to communicate. Everything including the screen and colission subsystems, game objects, ui and the states are equal part of the organization headed by the control object. (note: well isolated don't mean state object wouldn't create instance of ui, player, etc. )

 

I use Haxe Phaser.

 

EDIT:
If you find problem in concentrating on the work, give a try to Noisli. You can make your exprience even more wonderful by playing Noisli along with this.

[GBeebe]

I agree with b10b about documenting. I always right something down. The main point of the game, so it doesn't change half way through. Desired mood of the game, funny, scary, serious, etc.  Must haves that I need to stick with so I don't forget them. May haves for things I can add but aren't necessary. Then I draw up some dummy placeholder sprites and design a level that incorporates all the must haves.  I have a "skeleton" directory with an index.html that includes some .js files that contain my commonly used code for canvas, keyboard/mouse, sound, state machine, etc...  I copy that to a new project with my sprites and finally start coding. Just to keep things clean I usually start new files for player and other classes and not code them directly into the main file.