Diary

**With this diary, we want to give you a look behind the scenes and explain our decisionmaking regarding the whole project.**

# Week 11

## First presentation

The first presentation of our project consisted mainly of chinwagging about our goals. We set our Gantt-chart in focus for the planning.

# Week 12

## Communication protocol

For more information about the protocol, check out this page!

Power Racer uses a shared protocol, which is basically an enumeration file which contains all the valid packet names allowed to be sent.

We decided on a packet name length of exactly five letters, which should be more than enough for our use while being short and convenient. After the packet name, there may be extra information which is divided by a colon (":").

Client and server have their own parsers which check the validation of the sent packet.

## Server-Client connection

Before setting up the connection, we tested the common connection types TCP and UDP to see which fits our purpose best. After the test, we decided on using TCP only, because we want to be sure that every sent packet reaches the target every time.

# Week 13

## Server-Client connection

Both server and client use heartbeat packets to validate that the connection still stands and information can be exchanged. There are four corresponding packets, so that it is clear from which side the heartbeat request is sent.

The server has to validate and manage a lot of information. Before class sizes go out of control, we initialized to structure them. For example, there is a PlayerManager which holds and manages all the Player objects.

## Chat system

There are three ways to chat with another user on the server.

Chat to all: When you connect to the server and don't follow up by joining a lobby, your chat messages will be sent to all players on the server.

Lobby chat: When you send a chat message while being in a lobby, only the members in the same lobby will get that message.

Whisper: A private message can be sent to a specific user while being in the "all"-chat or in a lobby.

We decided to not put a chat system in the game itself, because texting and driving is never a good idea.

## Lobby system

Lobbies are created by the users themselves and have a randomly generated ID.

## Small JUnit test

A first unit test is initialized by Florian, just for getting an idea of its use later on.

## Small LobbyGUI

For testing the whole chat system, there was a setup of a small ClientGUI. We believe that it's more convenient than testing the chat over the console.

# Week 14

## Map system

The maps (or tracks) are based on tiles, which are stored in a byte array. Each tile has a different friction, so it is best to always stay on the track.

Each car has a different friction coefficient, which determinates acceleration and speed. This gets balanced out by the handling.

There is a TrackEdit to create new tracks for the game.

## Game logic

The rudimentary game logic is set up. Car position and rotation is updated, but no collisions are calculated. Checkpoints are checked. Game does not finish yet.

# Week 15

## Game logic

Game logic completely connected with server. Games can be finished. Highscore Implemented.

## Basic map design

There is now a "small track" implemented for testing purposes:

## ANT buildfile

Our ANT-buildfile creates a build-directory automatically.

First of all, it cleans all the stuff from previous builds.

Then it compiles all the specified classes.

A jar is generated for an easy start to the program.

After that, all JUnit tests are built, and in a next step run. This takes some time, but is crucial for the safety of a working program.

We later added the inclusion of the readme-file and the handbook.

After everything is done, the program starts.

There were a lot of problems concerning the automation of JUnit-tests. We had to define a classpath for the JUnit jars first, then use them through the buildfile. Now, it works perfectly though.

# Week 16

## Power-ups

There is a lead article about the power-ups.

## Sound

The sound gets handled through javax.sound.

You can toggle the music in the game with "M".

Simeon and Benjamin created the theme song for the Racer, which gets played in the credits for example.

Simeon contributed some piano tunes.

Florian contributed an 8-bit song.

The player hears the countdown now, so he can be mentally prepared to race.

# Week 17

## JUnit test

As the main JUnit test we decided to throw stuff at the LobbyLogic to see if it stands firm.

A lot of these tests assert that the right packet is sent. Some of them assert that pointers are resetted or variables are changed.

The hardest part about the tests was the inclusion into the build-file.

## Advanced map design

The RandomMapGenerator is a pretty cool feature of the game. Every time this track gets picked, there is a completely raceable track generated from scratch.

Its algorithm is constructed so that the track always finds its start again. Checkpoints are set randomly, so are power-up boxes.

These maps were added to the game:

**Sand Track**

**Ice Track**

# Week 18

## Debugging

The RandomMapGenerator was improved so it uses less recursion, which effected the generating time in great measure.

The GUI was improved, some extra features now

## Refactoring

Main theme of the refactoring was picking apart overloaded classes and using getters and setters wherever possible. Furthermore, the package structure was reconsidered and improved.

# Week 19

## ServerParser testing

We found some leaks by testing the ServerParser with an individual JUnit case. Our project tutor suggested to test packets which could be unstable and throw an exception when running through the Parser.

## Debugging

A major part of this weeks debugging consisted of constructing the ServerParser to an unconquerable fortress.

## Documentation

There is a readme in the build file to instruct the user how to run a server through the console/terminal or the GUI.

The slick handbook instructs the user how to play the game and informs of all input keys and features.

# Week 20

## Code conventions

Code conventions were followed quite strictly throughout the whole project.

A major formatting commit was easy through the use of our eclipse formatting profile.

### Style convention

- There's a .xml file in log which can be imported to eclipse

- Braces are always used, even when optional

- Blocks: K&R style

- Block indentation: 4 spaces

- Column limit: 80 characters (everything else is weird)

- There are some limit exceptions like JavaDoc links

- Always use CTRL+SHIFT+F after editing (use PowerRacerFormattingStyle.xml)

- There's no such thing as too many comments

### Naming convention

- Package names: every letter is small (packageexample)

- Class names: UpperCamelCase

- Method names: lowerCamelCase

- Constant names: CONSTANTCASE

## Final presentation

In the final presentation we will set focus on the demo and bring our personal touch into it.