Game Dev Diary – Part 1 – Living with Milestones

Game Dev Diary – Part 1 – Living with Milestones The Plan

Hey guys Nemo here, this week has been the official start of the holiday. With all my uni projects and contract work finished, I am free. I’ve been pretty pumped up for this holiday. This is the first holiday where I have had zero projects on my hand. It was such a relief but after the first day it was strange not having anything to work on. So, I decided it was time for a new project. After a bit of brainstorming on how I wanted to spend this 5 weeks, I boiled down to two main tasks. These are:

  • Game Development – Develop a prototype of a game that I’ve had in mind for  the past few months. A game that I can post to TigSource
  • Blogging – Post a blog at the end of each weeks about the progress of the game development.

And so it begins – The five week challenge.

The Game Design Document

We begin with the Game Design Document, this document describes the entire project, with all the details, and the methods by which each element will be implemented. It should encapsulate both the body and the soul of your game. By writing a design document it helps ensure you from wasting time, indecisive choices and from adding new features (otherwise known as feature creeping). It is like the blueprints of a building. When it comes to writing a design document there isn’t a golden template or rules to follow. However from my experience of writing and reading game design documents I’ve come to realise a few common traits that a good design documents have. These are:

  • Readable – People shouldn’t have to squint their eyes. If you have messy handwriting, stick to writing your documents on word. Learn to use good page layouts – eg. plenty of white space, easy on the eye fonts, bold headers.
  • Understandable – People shouldn’t get bewildered by your document. Dumb down the words. This isn’t 4unit Advanced English essay. Sometimes words aren’t the best choice either, you can sketch out your idea.
  • Detailed – Don’t tell them the “what”, tell them the “how”. eg. A bad example: A player can move in the game. A good example: A player can move by the keyboard or a xbox controller. On the keyboard he would use wasd and on the controller he would use the left joystick.

I realised that a good Design Documents are an essential to any projects and not just game related. The difference between a successful project and failed project can be reflected by the design document.

So Far

The concise version of my design document. Delirium, a top down sci-fi action game set on a cargo spaceship. Players will be put in a fast paced battle against a variety of bosses, in which they have to learn each of their weakness to defeat them. Upon defeating them they acquire new traits which can help them during other boss encounters. Features:

  • Intense and interesting boss battles
  • Players can shoot or use melee attacks
  • Players acquire traits such as dodge roll, different weapons
  • Players have 2 hit life system
  • Intuitive tutorial and gameplay
  • Swift and precise movement
  • Controller movement allowed
  • Pixel art – inspired by Crawl
  • The game draws its inspiration from Titan Souls and Mega Man

Untitled-Untitled-2 Placeholder art and basic functionalities of the game.

Well that’s about it for now but more to come over the 5 weeks! First week down, another 4 to go. Till next sunday! Stay well and keep productive. 🙂 Nemo Out

Advertisements