What is your game development process? - A beginner's question

News & General Discussion
1

Hello Unity Community!

This is my first post after doting around on the site for a while, reading threads, doing tutorials, floating around and eventually wanting to create a game using the engine. I’ve seen that the forum is a great place to poke at the community’s brain so I decided to finally post.

But, I’ll get right to the point: How would you go about and create your game? What is the workflow/pipeline/process you follow to get from idea to finished product? I figure it might be something like this, but I wanted input to see how everyone else goes about it:

  • form idea and gather references/inspiration to help it grow
  • create game design document (GDD) to nail down gameplay, concepts etc
  • start designing characters/create concept art (environments, characters, assets etc) and in tandem, create storyline
  • once refinements are done to GDD continue working on it as well as concepts while building a level prototype with workable player character

I’m somewhere close to the end of my aforementioned list. I’d appreciate feedback on what you’ve done for your project or if you haven’t done/created one, what you think it would be. Thanks!

2

I’m treating my game as a hobby - if I’m not having fun with making it I’m doing something very wrong. I tend to concentrate on 1 major task, with several minor tasks (camera, UI) as rainy-day tasks when I’m bored with the main task. This has worked really well for me so far.

My game is a zombie survival based in the 1800s with procedural terrain buildings. I have not planned what I want my art direction to be. I have no concrete idea on how gameplay will play out. Most of the time I am making it up as I go along, which has also worked well.
If I planned everything out I would grow very bored of it - turning into a tasklist.

3

Development being one long linear process is not very adaptable to changing situations. Consider using a development process in cycling, short bursts.

In its simplest sense, it would be like this:

  1. Planning, re-assessment of priorities (what needs to be done first?), coordination among teammates (what will you do for the week? what will I do for the week?).
  2. Implementation
  3. Testing and user feedback
  4. Go back to step 1

Tips:

Art creation and programming can be developed in parallel, but consider using placeholder art first while making the game. Create finalized art assets only when you deem the game to be working out fine, since revisions to the art take up valuable time. At most, perhaps rough concept sketches can be done early on without much risk of revisions from gameplay concerns.

Make a detailed design document for yourself, but summarize it for your teammates (no one wants to read long blocks of text).

Use sketches to visually explain your plans to teammates, to lessen misinterpretations.

Not sure if a feature will be good? Make a small prototype of it using mock-up art, then test it out yourself.

Get user feedback and suggestions as early as possible while its still easy to change things, let them test the game even if it looks rough, and do it for every work-in-progress build you create.

Let people play your game without teaching them how to play first, to see how easy it is for your game to be picked up by new players.

I work in a startup company wherein I am the only programmer for my team as of yet, and this was my development schedule:
Monday through Wednesday: work at home concentrating on light, minor tasks to “warm up”
Thursday through Friday: stay at office working on major tasks, constantly re-assessing priority list on what needs to be done first
Saturday through Sunday: don’t work, breaks are vital or it will stress you out in the long run

You’ll see that I’m missing the testing and user feedback and this was one mistake we did as a team. We only got useful ideas from players later on in the development schedule which would have made sense to implement but we didn’t account for in our schedule so we were not able to implement it in our first release.

4
  1. have idea
  2. create prototype and decide whether or not the idea actually works
  3. if everyone loves prototype and sees potential, go ahead and develop it.