Day 2

Design tweaking and creating the initial code structure

Jack was sick and missed everything.
Kate and I worked together on creating the initial structure of the app. We created the classes, added variables and created empty functions defining the structure of the classes and how they would access each other.

We decided for the sake of simplicity, we would have a static class with references to the current Client, Engine and possibly the Graphics instance if needed. This makes communication between the client, engine and graphics code easier.

The main reason for that is that both the Engine and the Client need references to each other, and since you can't give an object a reference to an object that hasn't been created yet, you end up with a chicken-and-egg problem. For example, if you create the Client before the Engine, you cannot pass the Engine into it's constructor, and vice versa if you create the Engine first. The other solutions would be to pass a parent object to the Engine and Client, or add a setClient function called on the Engine after creation, but that seemed like an unneeded extra step. The other nice thing about storing it statically is that the Graphics object can access the Engine the same way the Client would without having to add extra code for setting up the Graphics object.

We also put some more thought into how the IO between the client and the server will work.
We had a conversation about how potentially adding single player and local multiplayer would effect the design and classes. We decided that we should be able to make a class that effectively works as a local server. It had previously been decided that any AI code should be a part of the Engine code. This could make having a local server be complicated. We will undoubtedly have to add one or more new classes in order to make it work. It would be a good idea to talk about this at the next meeting, as changing the design early on will be less costly.

Now that all the classes, functions and general program structure has been written out, we should be able to start programming the app and designing the server application.

Day 1

Part 1: Setting up

We started later than planned.
I was late. Jack was very, very late.
We spent a good few hours setting up Eclipse and getting the android debugging connection working on our phones.
I had previously installed the Android Development Tools a year or two earlier, and only briefly used it then forgotten about it.
Since then I had rooted/updated my phone, so the debug connection wasn't working anymore.
After changing the SDK ADT was using, updating the Android Debug Bridge and messing around with it for a while, I finally got it to work with my phone.
I loaded up some example code (the snake sample code for API8) and played around with it a bit to get a feel for android.
It's important to remember at this point that before day 1 my full experience of android programming consisted of taking the snake demo and adding touchscreen controls to it.
After some googling, I started reading up on views and activities.
By the time Jack arrived (5 hours late), me and Kate had mostly figured out views, activities and the other basics of android programming, and we were ready to start designing the actual program.

Part 2: Design

We spent a fair amount of time talking about how the game would play from a gameplay perspective. We talked about things like movement interpolation, control schemes, and how we would implement such things if needed. Jack also liked the idea of bullets travelling over time, I disagreed an thought they should be instant, however I think that it's something that should be explored if we have the time.
We decided we'd start actually designing the android app and got out the whiteboard. It became obvious pretty quickly that we had no idea how to start.
I decided to draw up 3 columns: client, engine and graphics, and started getting people to list functionality each part of the app would need.
The graphics column covered the renderers, menus, etc.
The engine covered anything relating to actual gameplay, such as keeping track of the map, enemys, player input, etc.
The client column covered things like server IO, serialization and deserialization of objects.After a couple of minutes, we were making progress in leaps and bounds.
When we thought we had covered the functionality of each part of the app, we started breaking each column down into classes.

The whiteboard at the end of the discussion, complete with authentic engineer handwriting:

FYI the map is a separate class because we are using a special datastructure that makes serialization and deserialization better.
Input was later (day 2) moved to the graphics column because input is done on views, so we made a new class called InputView that MapDrawer extends.

Introduction

Hello, reader!
This blog documents the development of the tentatively titled android game Maze Runner, a massively multiplayer online first person shooter inspired by the 1974 game Maze War.
We are a small 3-person team of students from Victoria University of Wellington studying Engineering,  Jack Bannister-Sutton, Kate Henderson and me, Bryden Frizzell.
We have next to no experience with Android development, and realistically about a week to make this thing.
This should be fun.