Day 7

Wow, we've finally reached the 7 days mark! and it only took us 3 months!

Graphics

We spent pretty much the entire day working on the graphics

Movement works fine. I've got to write up a whole lot of server code before we can progress much further.

We spent a good while experimenting with different code for drawing the walls.  We currently have a few minor graphics bugs. The basic maze-war style drawing algorithm has some places where it fails, even on properly generated maps. I might do a post explaining where/why these bugs occur.

Apart from that, we're pretty happy with the aesthetic of it. At some point we'll clean up the graphics a little, make sure lines connect, but probably nothing too major.

The drawing code works at any resolution with any aspect ratio.

We're on break again for a couple weeks so with any luck we might get some more work done on it over the next two weeks...

Day 6

A couple months of intense Uni work later, we finally managed to get some time again, just as the next semester started.

App progress

We got the app talking to the server, and the login and register buttons are working.

Kate set up all the menu transitions and set up the in-game screen.

We also re-designed some of the menus to give a smoother and more intuitive user experience.

We're about ready to start getting some in-game graphics going and some actual server-client communication set up.

Day 5 and interlude

Server progress

I went and finally got us a Linux VPS. After setting up all the SQL stuff on the server (which all had to be done in terminal, which was SUPER fun), I tried running the server code on it, which immediately started having errors. It worked perfectly on my laptop, but threw null pointer exceptions on the server. Took me days to figure out what was wrong - it was the simplest, stupidest error. Anyway, long story short, that's fixed and the server code for logging in and registering is running perfectly.

Client progress

Kate finished up a lot of the menu code. Apparently, it's pretty much completely working. We ran into all sorts of problems with menu transitions, and switching between android activities.

Progress is pretty much temporarily halted since university is back on, but I'm pretty determined to finish this as soon as possible.

The next steps will probably be making the login and register parts of the menu functional, getting some basic game graphics displaying and actually starting to make the game, both client-side and server-side.

Right now, we're all completely swamped with university work. Here's hoping we make some progress before the end of next week...

Day 4

Server progress

I wrote a lot of server code.
I set up account storage, including secure password storage/hashing. I did a lot of the server receiving code, and have a working login system set up now.
I set up some simple code for generating the temporary client ID. 

I also wrote the server code for queueing and sending events to the player, it seems to work as it should. Further testing will be required to see how it performs under load/on a larger scale.
All the threading has been figured out now. The server has a thread where it accepts new connections, a thread where it sends updates to players, and one thread for every socket receiving data.
Kate worked on the GUI and making the app work. She made most of the main menu.

Day 3

*editors note: these posts were not posted on the original development days. They're posted whenever I have the time to write them up. Day 3 was Monday, 28/4/14. I don't plan on adding dates on the older or newer posts, since these posts are still in order and are close enough for the purpose of documenting what's going on, as they are generally written up 1-3 days after the day they cover.

Server design

We finally got around to writing out how the server code would work. By this point, we had talked about how most of the more complicated, problematic systems in the server code would function, for example the position interpolation to make up for connection latency when a player shoots, and how to set the data structures up so that when an event happens near a player, that player will receive an update.

We designed a system to make sending updates to players more efficient. Each player has a queue of "recent events" that need to be sent to them, and there will be a queue of players that need to be updated.
Each map chunk will contain a list of players who are in that chunk.
When an event occurs (remote player movement, remote player shoot,  ect) that event is added to all players contained in the surrounding chunks queue, and for each player, if they aren't in the "to be updated" queue, they will be added to it.
The server will continuously get a player from the "to be updated" queue, and send all updates on that players' updates queue in a single packet.
This gives you a good trade-off between bandwidth efficiency (the TCP/IP header is going to be the largest part of the packet, the more updates you can package into a packet, the more efficient it is) and latency (waiting for events to queue increases latency).
If the server isn't under load, the latency will be low because players will be dequeued and packets sent before multiple updates occur. If the server is under load, multiple packets will be combined together as multiple events happen before each send, and the connection will become more efficient at the cost of increased latency.

There will be a minimum delay between movements (turn, move forward). Probably something around 50ms. This means we can store a queue with finite length of the players last positions, and using a shooter's latency, calculate whether the shot fired by the shooter should have hit the player.
This might get more complicated when we add client side interpolation of movement (for if a player moves more than once before the receiver receiving an update), but the basic idea should work. The other option is to have clients perform interpolation on their side and deside if a shot hits, but that is potentially easy to exploit.
The downside of doing everything on the server like this apart from potentially being more complicated, is that two players can shoot and kill each other because of latency. On the other hand, that's a fair way of processing things, because it means a player with less latency doesn't get an advantage over a player with more.
The other downside is we have to pick a maximum latency to support. I was thinking of using a value between 300-500ms. Realistically, there may very well be players with more latency than that, the question is whether we want to support higher latencies as players with high latency would mess up gameplay. Imagine you kill someone then over half a second later, you're told that they also killed you. It just wouldn't feel right. I guess we'll need to experiment with it and find the point where player latency starts making the game suck.
Another potential strange side effect of this is it might be possible for multiple people to kill the same person under certain conditions depending on how we implement things.

In the end, we removed the Serializer class and decided the events would have a function to write the event to the socket's output, which simplifies the server code (decided after making the diagram below).

We also decided it would be a good idea to have a ban system set up before release that would cover account bans and IP bans.

A lot of the more complex functionality of the server didn't show well on the diagram, so there was a lot more writing out how things would be implemented in the  for the server than there was for the client. At this time, we haven't shared the text document with design notes, but the major things where the interpolation and event queues.

Git setup

We set up Git repositories for the client and server. We got everyone set up so that they could push and pull from the repository and figured all of that out. Kate tried to get a more elegant solution working using an eclipse plugin, but it turned out to be too problematic to set up, so we just used the standard Git GUI.

We got everyone familiar with working with the code, and each pushed an update to the repo.

We're breaking for a few days as Kate is busy. I'm writing up the server template code while that's happening so that we can get programming when we next get together.

Next steps:

(finish templating the server code)

Figuring out multithreaded socket IO, figuring out whether any of our classes will require blocking so things don't break.

Writing enough of the app so that we can start testing code.

Writing enough of the server so that we can start testing code.

Getting some basic IO going between the server and client (guess I'm going to have to hire that VPS pretty soon)

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.