Riveting Studios

CONFIDENTIAL

CLOCKWORK CONFLICTS Jan Verbeeck

1 | P a g e

2 | P a g e

Contents 1. Preface ......................................................................................................... 4

2. Introduction ................................................................................................. 5

3. What is Clockwork Conflicts? ....................................................................... 5

4. Rethinking the project ................................................................................... 6

5. Starting the project ........................................................................................ 6

6. Choice of technology .................................................................................... 7

7. Integrated Development Environment .......................................................... 8

8. Version Control ............................................................................................ 8

8.1. Team Foundation Service ....................................................................... 9

8.2. Git .......................................................................................................... 9

8.3. Dropbox ................................................................................................. 9

9. Unity3D ..................................................................................................... 10

9.1. The editor ............................................................................................. 10

9.2. The engine ............................................................................................ 10

10. Communication ....................................................................................... 11

10.1. Social media: Facebook ..................................................................... 11

10.2. Skype ................................................................................................ 11

10.3. TeamViewer ...................................................................................... 12

11. Gained knowledge ................................................................................... 12

12. Teamwork ............................................................................................... 12

13. Deliverables and their Components .......................................................... 13

14. Server deliverable..................................................................................... 13

14.1. Domain ............................................................................................. 13

14.2. Network ............................................................................................ 13

14.3. User Interface .................................................................................... 14

15. Client deliverable ..................................................................................... 15

15.1. Domain ............................................................................................. 15

15.2. Network ............................................................................................ 15

16. Persistence deliverable ............................................................................. 15

17. Messages System deliverable .................................................................... 15

18. Unity3D deliverable ................................................................................. 16

18.1. Code ................................................................................................. 16

3 | P a g e

18.2. GUI system ....................................................................................... 16

19. Database deliverable ................................................................................ 17

20. Working for Riveting Studios ................................................................... 18

20.1. Getting people involved ..................................................................... 18

20.2. Legal matters ..................................................................................... 19

21. Conclusion .............................................................................................. 20

4 | P a g e

1. Preface For our IT-project we decided to do something that we were really interested in

and we could be motivated for. Finding the right project wasn‟t that hard. We

continued a project from last year that we were really passionate about: Creating a

multiplayer game. While we technically continued the project we ended up

redesigning it almost entirely. Ward, Jonathan and I had already worked together

on the previous version and we learned a lot from it. Since Ward and I are going

on Erasmus next year we couldn‟t prepare a project for an external company. So it

was a logical step to continue this project.

First we‟d like a moment to thank our mentor, Geert Vandriessche and the head

of our department Yvan Rooseleer for making this project possible. We would

also like to thank Serge Van Cleynenbreugel for helping us with software related

problems. Finally we would also like to thank all teachers for supporting and

teaching us the skills to bring this project to completion.

5 | P a g e

2. Introduction In this document you will find my views on our project, experiences and some

none-technical information about our project and its deliverables. This document

is one of our deliverables but the project itself, the compiled code as a whole, our

„product‟ is our main deliverable. For a more technical and in-depth view of the

project you can refer to the enclosed technical documentation. This project ended

up to be much more than just our IT-project and this allows me to proudly present

our project: Clockwork Conflicts.

3. What is Clockwork Conflicts? Clockwork Conflicts is not just our IT-project, it is also some kind of dream for us.

The plan is to make a complete game out of it. In the context of our IT-project

Clockwork Conflicts is a technology demonstration to show the basics of our

game. These basics include a completely functional networking library, a

database, server software and client software. In this technology demo 2 teams can

compete against each other in a multiplayer game. To make this technology

possible we needed a lot of functionalities. We made every of these functionalities

ourselves excluding the Graphics rendering and physics engine, for this we used

Unity3D. In the future we would like to make these things too but for this project

it was not realistic in the timeframe.

6 | P a g e

4. Rethinking the project While our project was a continuation of a former project we had to rethink a lot.

First of all we had to make sure what we would deliver, what would our

deliverables be for this project? Time was our worst enemy in this process. None

of us had specific experience with creating a game on this level. Although one

thing we learned from the former project is that programming a fully functional

system takes a lot of time and that lots of time is „wasted‟ searching and fixing

unexpected bugs. So we tried to set our goals not too high in terms of gameplay.

But we wanted to complete the basic functionality.

Because we had a lot of trouble with the former project we chose to start with a

blank slate. We started new projects and tried to start over entirely. We did have a

lot of code we could reuse though. But every time we reused old code we went

over it again. During the year we learned a lot about programming that we could

use to improve our project. Every programming class we took notes with our IT-

project in mind so we could later implement the newly learned methods and

structures. A lot of knowledge also came from experience, this helped us merge

the former project with the current one.

While we didn‟t want to set our goals to high we did start thinking about the final

product. This helped a lot when implementing features later on and made sure we

didn‟t have to do major adjustments. Everything you could do in the game, every

mechanic was thought about. While we didn‟t get everything right from the first

time we it did really help us. For example we designed the entire database before

we even had implemented the features to even use a database. We tried to think

about every detail for the finished game, not exclusively for the completion of this

product. This made sure we had to do a minimal of changes to the database

structure while working on the project and made sure we could focus on

implementing the database instead of designing its structure.

5. Starting the project The first thing we had to do was merge our old code and rewrite it. Since this was

mainly networking code, our first focus was the ability to send and receive data in

a correct and reliable way. Instead of focussing on two separate projects: Client

and Server. We first focussed on the technology used for communication. Another

thing to do was designing the database structure. And another part of the project

was the visual side since networking is hard to make visible and interesting

without visual elements. So at the start we divided the three tasks. One person

would work on the networking, one on the database and one on the visual side.

7 | P a g e

6. Choice of technology Choosing the right technology is critical in the development of software.

Unproven or unstable technologies can prove to be more annoying than errors or

bugs you can fix yourself. A few choices were already made in our last project.

Since it was a project for software engineering 4 which was about C# and

Microsoft SQL we didn‟t have a lot of choice. Not that these choices bothered us

at all. These technologies were the most familiar for us and work seamlessly

together since they are created to work together.

The toughest choice was the visual side. A game needs a graphical engine to

display things, it needs a physics engine for interaction between objects and it

needs an input controller so that the user can interact with the program. While we

could make these things ourselves this would probably take a few years to

complete. So we had to search a solution. The solution was a premade „game

engine‟. There‟s a lot of choice when searching for a game engine but a few things

were important to have. It needed to be compatible with C#. This drastically

limits the options due to the fact that most game engines are written for C++ code.

It also needed to have an easy asset pipeline and content creating system since we

are programmers and not 3D artists or level designers.

Finally we settled on Unity3D to handle the visual side. The major reason for this

is because it offers compatibility with Mono. Mono is a cross-platform version of

C#, which means our product would run on Windows, Linux and Mac. This was

even better than our envisioned Windows-only release. In Unity it‟s also

incredibly easy to create levels and import assets. Finally Unity comes with a few

basic assets we made use of and it has a large community and lots of

documentation that we could make use of for help.

8 | P a g e

7. Integrated Development Environment Good tools are important especially when you have to use them for hours. Our

primary tool to create Clockwork Conflicts is Visual Studio 2013. Visual Studio is

an IDE (Integrated Development Environment), it is used to write code. However

it is much more than just an editor for code. Like most IDE‟s it uses auto-

completion and code suggesting. It‟s also the tool of choice for .NET development

since it is developed by Microsoft itself. We started out with the 2012 version of

Visual Studio but recently the 2013 version was released which integrates Team

Foundation Service (see Version Control) even better. So we upgraded to Visual

Studio 2013.

8. Version Control One thing that‟s really important when you are working on a big project with

multiple people is version control. It allows people to edit the project and upload

their changes to a server. Other users can get these changes from the server and

upload their own. Some version control systems even allow users to merge

changes they made. For our project we use three kinds of version control systems.

9 | P a g e

8.1. Team Foundation Service

Team Foundation Service is our primary source control version for almost all

code. Everything that isn‟t programmed in Unity3D is hosted at a Team

Foundation Server. This includes our server software, the largest part of our client

code and all tools. This TFS is hosted by Microsoft and is free for up to 5 users.

The main reason why we use TFS is because it is seamlessly integrated with

Visual Studio 2013, our IDE. TFS was created with .NET languages in mind and

works perfect with C#.

The most important feature of TFS is merging and auto-merging. Merging makes

sure you can work on the same project with multiple people at the same time.

When you commit changes you have made TFS will either auto-merge the

changes or if it can‟t resolve the changes will ask the user for input. Team

Foundation Service also provides a website where you can manage your project,

view your code, view the changes and create a backlog. This allows you to work

using the Agile software development methodology. You can add backlog items,

features and tasks. You can then assign them to a specific sprint, a period in the

development. There are also a few options that let you display statistics to monitor

the project status.

8.2. Git

The second system we use for version control is Git and more specifically GitHub.

Git is a version control system that is not specific for Visual Studio projects. It is a

system that supports all kinds of projects and files. We use git for our Unity

project. This includes the code from the client which is also written in Visual

Studio. Although Visual Studio supports Git we use GitHub for windows for our

version control. We use this because our code is hosted by GitHub. GitHub is

usually used for open-source projects, project with a free and open source code.

We don‟t want anyone to view our code however so luckily they also provide

private hosting for students. We choose to use a separate system for our Unity3D

project because it doesn‟t consist of exclusively code and TFS is designed to

specifically host code. Since we started prototyping in Unity from the beginning

before the network code was implemented we didn‟t want to merge the network

code with the Unity project just yet.

8.3. Dropbox

While Dropbox isn‟t really comparable to the other two systems it is also some

sort of version control. Dropbox is used to store all our information and

documents. This includes design documents, database scripts, some art, archived

files and compiled test versions of our project. It‟s incredibly easy to use and it

synchronizes data in real time. This is something the other systems can‟t do.

Dropbox has a whole different use and wouldn‟t be particularly be useful for

writing code. But it‟s invaluable for other files that need to be shared fast and

easily.

10 | P a g e

9. Unity3D Unity3D is both a tool and a game engine. It consists of an editor to design levels

and manipulate objects in the game world. It also includes an IDE called

MonoDevelop but since Unity also supports Visual Studio we chose that option.

While the editor is a powerful tool that makes creating a game easier and visual it

is also some sort of restriction.

9.1. The editor

The editor was perfect to start making the game. Defining the controls, camera

and doing singleplayer prototyping. So we could get a feel of how the game would

be when it would be finished. The thing the Unity editor lacks is a system to create

graphical user interfaces. Not only doesn‟t it have a system to make them using

the editor but the user interfaces by using codes is abysmal. So we spend a huge

amount of time creating a somewhat better system to create user interfaces by

using code.

9.2. The engine

The Unity3D engine was both our largest blessing and curse. It allowed us to

create the visuals of the game without too much effort. But it was also the thing

we had the least influence on. The engine consists of a large codebase and has lots

of things predefined. Right from the beginning we decided to do almost everything

ourselves. This takes a lot of time but makes sure you understand everything and

you learn a lot from it. But when using Unity we often ran into different problems

we had to work around. This is one of the reasons why we would like to continue

this project and create a complete game with our own engine.

11 | P a g e

10. Communication Communication is very important when working in team. Because we already

worked together in the past, working together wasn‟t really a problem. We really

synchronised our method of programming. Our code looks very similar because

we use the same formatting rules. There are three major tools we used for

communication.

10.1. Social media: Facebook

The first is an obvious one: Facebook. Although I thought we would use it a lot

more we didn‟t really use Facebook as much to communicate between team

members. We have a group where we sometimes post things we need to do and

sometimes I posted something when I had successfully implemented something or

fixed a bug. We also used chat to contact one member directly when something

was urgent. But for the project itself or in team we didn‟t use it much at all.

Communication towards our supporters however was done with Facebook. We

made a page and posting some teasers on it. We also used Google+ and twitter to

communicate with interested people.

10.2. Skype

Skype is our main source of communication. It allows us to host a group call with

all three of us so we can talk together. While the quality isn‟t always optimal it‟s

free and doesn‟t require anything other than the program itself. We spent

uncountable hours on Skype together. Often entire days and/or nights. This

meant we could constantly communicate by talking to each other which is still

much easier than typing. Even when we weren‟t calling we could still

communicate by chatting.

12 | P a g e

10.3. TeamViewer

Another invaluable tool. TeamViewer makes it possible to view what is going on

other people‟s computers. This made it perfect for pair programming while not

being physically present. It is most useful when fixing bugs or testing the results of

something. It‟s also great for network or multiplayer testing since you can see

what happens on the other side. Often we had a few TeamViewer sessions open so

we could see each other‟s screens without constantly swapping the presentor.

11. Gained knowledge This project was a source of knowledge for everyone in the team. This knowledge

comes from form searching for topics you don‟t know or when searching solutions

for a problem. Since we were working closely together and were usually on Skype

together this knowledge got shared with the group almost instantly. This means

the amount of knowledge we gained from this project is almost tripled when

compared to doing a project solo. Lots of this knowledge gave us a better

understanding about how systems work. For example we had to analyse the entire

system of how computers communicate to make the networking system. We also

learned to work with tools like Unity3D and GitHub. We also mastered topics

that were taught during classes by applying them.

Working with Unity3D also taught us some basics of how a game engine works.

While we couldn‟t access the source code we got a general idea by working with it

and reading the documentation. This information will come in handy later when

we will try to make our own game engine.

12. Teamwork One of the main goals of this project was learning to do something as part of a

team. Because we already worked together this wasn‟t a problem for us. Perhaps

it‟s a little disadvantage because in a work environment you don‟t always get to

pick your team members. However I don‟t think this project would have been

possible with different people.

While we worked closely together we each programmed systems independently

after consulting with the rest of the team. Usually we had TeamViewer open so

the others could see what you were doing at the moment. Some of things we did

together is pair programming. This is a technique were one person writes code

while another one watches. This was also possible using TeamViewer. It has a few

advantages: The other person knows your code and can correct or suggest things.

When there was a game-breaking bug that slowed or halted development we

would all watch one person‟s screen while he was debugging the code. This

approach made sure the thinking capacity was tripled and usually sped up the bug

fixing process.

13 | P a g e

13. Deliverables and their Components It‟s hard to work on the same things with a group of three people so we decided to

divide the work into pieces. When we started the project we had portability in

mind. Portability means the project can easily be ported to other software or

systems. We didn‟t want to write everything to specific and divided each element

based on its functionality. When programming with C#/Mono this isn‟t hard to

do. Instead of building an application as a whole you make a part of it and

compile it into a Dynamic-Link Library or DLL.

These libraries can be imported into a code project which then can make use of the

DLL‟s functions without seeing or having to go through its entire code base. This

makes it easy to swap out different functions and allowed some code to be reused

or be used on both client and server. Every DLL in our project is a deliverable and

a small project on its own. Our project is divided into four main deliverables but

these consist of components which are also deliverables. These deliverables are the

server software, the client software, the Unity3D project and the database.

For details on the deliverables please refer to the enclosed documents.

14. Server deliverable The server is one of the main deliverables. Network communication and thus

multiplayer is impossible without a server. The server consist of a few

components. These are the domain which handles all the logic of the server. Next

is the network library which handles connectivity and is also shared with the

client. Then there‟s the persistence which handles database connectivity. There are

also some smaller libraries that handle the graphical side of the server and contain

some data structures to make programming easier.

14.1. Domain

The domain is the heart of the server it handles all logic. When the server receives

information it processes this information and makes it ready to be sent again. It

includes everything from logging in an account to calculating the account.

For more information on this please refer to the enclosed document “Server Logic

Layer”.

14.2. Network

The network is the centre of communication for the server. We started working on

the server first and this was later reworked for the client. While they got a lot of

things in common. This side is specifically tailored for a role as server. This means

this network component can handle a lot of connections to facilitate all clients and

thus players that are playing the game.

For more information on this please refer to the enclosed document “Server

Network Layer”.

14 | P a g e

14.3. User Interface

Last but certainly not least is the servers‟ User Interface. The User Interface or UI

is what the user sees. We opted for a Command Line Interface or CLI which is a

basic interface that shows information line by line. A CLI is not very pleasing to

look at but it‟s the least graphical intense way to write a program. We don‟t want

to spend any of the server‟s resources displaying information when only

administrators can see it.

Figure 1 the server User Interface

The main goal is to offer our end-users a smooth multiplayer experience. Making

it a CLI also enables the possibility to run the server headless which allows the

server to be run on a physical serve machine that has no graphical operation

system. Which is usually the case in datacentres. It also makes porting to other

platforms like Linux and Mac easier since the User Interface doesn‟t have to be

redesigned for every platform

For more information on this please refer to the enclosed document “Server User

Interface”.

15 | P a g e

15. Client deliverable The client also consists of a few components. These components are like the server

the logic and network parts. While they serve roughly the same purpose as the

ones on the server they are completely different. Other components are shared

with the server like the persistence and data structures.

15.1. Domain

The domain of the server handles client side calculations. It processes the

information it gets from the server and stores information that is needed while the

program is running.

For more information on this please refer to the enclosed document “Client Logic

Layer”.

15.2. Network

Like the server‟s network layer this handles everything that relates to connectivity.

It is different from the servers‟ because it is built to handle only a few connections

to one or a couple of servers.

For more information on this please refer to the enclosed document “Client

Network Layer”.

16. Persistence deliverable This part is the same on both client and server. Persistence handles getting data

from a database. This library just gets the info without actually knowing what the

data is for. The raw data that is collected from the database is made available for

the domain. So nothing is done with this information until the domain asks for it.

For more information on this please refer to the enclosed document “Database

Layer”.

17. Messages System deliverable The server and client are two entirely different programs but they need to be able

to communicate with each other. This means they need to talk in the same

language using the same system. This entire system is specified in the message

system that is included in both programs. Both sides need the same version in

order for communication to happen flawlessly.

For more information on this please refer to the enclosed document “Messages ”.

16 | P a g e

18. Unity3D deliverable This includes a code project which makes use of the code of the client. All libraries

from the client are included and used here. The unity project contains additional

code to communicate with the client code so the client can remain independent. It

also includes all art assets and the game world as a whole.

18.1. Code

The code of the Unity project is the glue that binds all client functionalities

together. It is an interface between the client and the user. It handles everything

visual about the client, the input of the user and the physics that make playing the

game possible.

For more information on this please refer to the enclosed document “Unity”.

18.2. GUI system

When we started working on Unity our main complained was that its GUI or

Graphical User Interface was almost unusable. So we decided to write some sort

of wrapper around the existing system that made it easier to use. We ended up

spending a lot of time on this and took a larger amount of time than envisioned at

first.

For more information on this please refer to the enclosed document “Restructuring

the Unity3D GUI”.

Figure 2 our game with the new GUI structure

17 | P a g e

19. Database deliverable The database deliverable includes out entire database system and all scripts that

were used to create the database. The database holds data for every aspect of the

game. It holds everything form user accounts to the resource cost of an ability that

is used in the game. Creating the database was a lot of work because it included

designing the database, writing the scripts and filling it with test data. This also

wasn‟t a linear process because some things had to be changed during the course

of the system.

In reality we don‟t use one database but several. One holds important info that

should never be viewed or adjusted by users. Another one includes all active data.

This means all data that is often changed, like user accounts and characters. The

last database is the static database which hold all values that should be used in the

game but shouldn‟t be adjustable by the user. The static database gives us a huge

advantage in the further development of the game because we can adjust its

values. When the values in the static database are adjusted the game will

automatically be updated. This means we can change the game and balance it

without having to release a lot of updates.

For more information on this please refer to the enclosed document “Database

structure”.

Figure 3 raw designs of the database layout

18 | P a g e

20. Working for Riveting Studios When we started this project we chose to work for ourselves instead of picking a

company. This makes some things easier but also makes a lot of things more

complicated. We started working under the alias „Riveting Studios‟. While we

aren‟t a real company the idea is to become one someday. With this in mind we

tried to do everything right from the start. We thought everything through while

trying to remain realistic.

20.1. Getting people involved

When developing a product it is important that you build interest in it for potential

users. While this wasn‟t a necessary step for the completing of our project at this

moment. Testers are an advantage when building a multiplayer environment. We

did spent some time working on our project setting up a site, creating a Facebook

page, setting up a twitter account and making a YouTube channel. On our

Facebook page we regularly release teasers.

Figure 4 teaser images released on Facebook

19 | P a g e

20.2. Legal matters

While we haven‟t looked at all our options yet we are quite confident that we will

be able to continue this project either as a commercial project or otherwise. We

currently have a contract with our testers and an agreement between our team

members that states that all assets of this project are undivided between the team

and we all have co-ownership of everything. During the preparation we were also

cautious when picking a name to see if it was not used yet.

Figure 5 the Clockwork Conflicts logo

20 | P a g e

21. Conclusion This project has truly been a life-changing experience and I have a feeling this

project won‟t end here just yet. We learned a lot from it and improved our skills

immensely. We discovered not only what we were capable of on our own but also

what we could accomplish as a team. Countless hours went into this project and

we gained a lot more from it than just knowledge relevant to the project. The late

night Skype conversations were often as much fun as they were productive.

We hope to be able to continue this project in the future. And while it‟s truly an

enormous and ambitious project, with the knowledge we gained from our IT-

project I think we are now more than ever capable of making our envisioned final

product succeed.