All posts by Tim Henriksson

A visit from the teachers


Last friday our teachers swung by to pay us a visit and check up on our project. Actually, we invited them. We had prepared a demo of the project in it’s current state and thought it was time to show off our work. Of course, the game in it’s current state is a pre-alpha and not very heavy on the graphics side. The main point was to demo the group behaviour of the rioters and how two groups interact when crossing eachother’s path, layed out on a very simple map.

We got the feeling we made a good impression. Our programming teacher, Stefan, was mainly concerned with the delay time of the potential fields of rioters in the game. The potential fields are like invisible magnetic fields that makes rioters cling together in a group or move away from police units and other threats. These are updated in realtime with a delay of 14ms as of now. This is an optimization issue that we will deal with in time.

We also received a bunch of questions and suggestions from our project managing teacher, Torbjörn. As always he was very interested in and inquisitive about our organisation within the group. He raised the important issue that we should focus on locking down ideas and implementations as soon as we’re able to, and linger as little as possible on multiple choices of technical baselines (for example: choosing between two types of animation techniques).

We have quite a lot of zones containing ideas and work tasks for the game – our wiki, scrum board, idea board, user stories, agreements contained within specific group responsibilities and individual visions of the game. Even though we already have a rather tight work flow, Torbjörn wanted us to streamline it further and narrow everything down. It’s quite refreshing to get input like that and I think he pushed us in the right direction.

We received the question of how we’re going to make the rioters look varied and unique, which is always an issue in games containing large groups of individuals. We don’t want rioters looking like clones. Our solution for this is to have a base set of different human models, textures and accessories (for rioters to wear or hold on to), which we will tint with various colors to create variation in their visuals.

In general the teachers seemed to be happy with our progress, and we’re happy too. We’re on track and organized. Basic gameplay interaction is due for implementation in the weeks to come on the programming side, and on the art side we’re going to start creating content such as level design, level concept art, 3D models of entities in the game and mocapping. We’ve come far, but there’s still a long way to go.

– Kim (Technical Artist)

Agile development

There was never a choice whether to exercise agile methods for our project as it is dictated by the course the game is being developed for. Having that said, we probably would have used it given the choice. Agile development is a good fit for many projects and especially for game projects, in my opinion. The core idea is adaptation: the project is developed using iterations where the path towards a finished product can change direction as new requirements and requests are being catered to. This is well suited for game development as it allows us to easily add features, adapt to results from playtesting and quickly change goal if the game idea needs to be altered.

Our method

The process is mainly Scrum. First we create user stories for our project. A user story is typically written from the perspective of a player or developer, or another role significant for the project. It is a feature or technique that a person in that role would want to see in the game. We have divided our project into the smaller parts called sprints and decided on each sprint spanning two weeks. Each sprint has a goal with associated user stories and should work towards the very rough monthly milestones we have set up for the project to make sure we make enough progress to reach our final goal. This goal is decided upon during the sprint planning meeting at the beginning of a sprint. Then, the sprint’s goal is further broken up into smaller tasks (called Product Backlog Items or PBIs) which are estimated and put on our Scrum board for everybody to see. Our team has a velocity, which states how much work we can do each sprint and the total estimations for the tasks should not exceed this velocity.

To find out the velocity, we start by figuring out the unit for the velocity. Scrum suggests this is done by choosing a very basic task, giving that task an estimation (usually one unit) and then compare all future units to this one. That is, a task that takes twice as long as the basic task with an estimation of one unit takes two units – you get the drift. Then, we estimate how many basic tasks we could do as a group in the allotted time and that is the team’s velocity. As this is all very approximative, more so the less experience you have working with this method or working as a group, the velocity needs to be adjusted after a sprint. A good time to do this is during the retrospective, a more realistic value can be chosen as part of the evaluation. More on the retrospective below.

We also have the daily Scrum: a timeboxed, 15-minute meeting at the start of every work day where each team member accounts for what task(s) they worked on the previous day, what they are going to continue work on and what possible problems he or she may encounter during the day. This is a very good way of making sure all team members have an appreciation of what everyone else is doing and what state the project is. It also helps discovering and solving problems quicker. At the end of each sprint we have a retrospective meeting, as the Scrum process suggests, where we evaluate the sprint: what has worked well and should be continued, what did not work and should be changed and what new approaches do we want to try.

Lastly, we have an appointed Scrum master that for learning purposes is cycling through the team members interested in the assignment. Currently, I am the Scrum master and as such, my duties include facilitating meetings and solving problems that may slow team members down.

If we find bugs, these are put on the Scrum board immediately and discussed during the next daily Scrum to determine whether they are pressing and need to be resolved promptly, or if they can wait to the next sprint, as well as who takes care of it. This is in line with the Scrum policy that tasks are not finished until they are complete and bug free (as far as is possible to determine).

Apart from what we take with us from these agile processes, we also have an idea board for adding any ideas whenever you think of them. These ideas are then considered at the sprint planning meeting and either discarded, left for the future by going back on the board or incorporated into the process in the form of a user story, PBI or addition to the Game Design Document (GDD).


We have had occasions where some team members have been stuck waiting for other team members to finish their tasks. This has left us less productive than we could have been although not inherently the fault of Scrum – some dependencies are inevitable, especially at the beginning of a project and some are due to our inexperience in planning and such problems will be avoided as we get better at planning.


Several advantages have been mentioned above and include the easy addition and removal of features, incorporate changes based on playtesting, all team members being up to speed with what everybody else is doing and the use of an iterative process. If we come up with new ideas we would really love to see in the game, they are easy to add and conversely – if we find that time is running out on us we get the chance to cut features. Same goes for the result of playtesting.

That all team members know what everybody else is doing is very important and minimises misunderstandings, double work and error resolving. The Daily Scrum also propel communication within the group as an extra bonus for a newly founded group.

The iterative process allows us to change the direction of our project if necessary, scrap features and techniques that do not work in the desired way and even rollback entire sprints. Thanks to the retrospective meetings at the end of a sprint, we continuously improve the work process to make it more effective and less error prone.

Further Reading

If you are interested in the Scrum process and want to know more, I recommend the book Agile Game Development with Scrum by Clinton Keith (ISBN: 978-0-321-61852-8)

Edit: Removed an erroneous description of our method where Kanban was mentioned.

Written by Kim Restad



Creating some concept art

After the thumbnails for a specific scene or object has been created, we verify it with our graphics lead, Lukas. If necessary, we discuss the various pictures in the thumbnail with Tim, our game designer, to decide which concept would work in the game, which parts we should continue working on etc. When we’ve decided which concepts seems the most interesting and suitable, we finish the verification step and continue by making the actual concept art.

The biggest issue for me was to minimize the time spent on actually drawing the concept art, as I am not an artist in my own right. Finding a work process that would work for me was quite a challenge and each of the concept images made so far has ranged between 2-4 hours in the making.

Factory designed for a certain level in the game

I’ve been working mainly with the environments and architecture of the city that is the game world. The city, which is typically cyberpunkish, is divided into three vertically built layers: the top plane for the upper class citizens, the middle plane for trade, markets and middle class citizens, and the bottom plane for the working class and poor people, filled with slums, industries, smoke and dirt. The bottom layer is the part of the city we’re focusing on at this moment of the development.

The slum environments will look kind of like the industrialism of the early 1800’s: brick buildings, high chimneys spewing thick smoke, tall windows and dirty streets. I photomanipulated the picture below by adding in some buildings and factories to visualize how the people would have had to build their homes in chunks right next to the industries polluting their environment, because of lack of space and to portray the desperation of the people living there.

Concept art for residential area.

For my other artwork, I created 3D scenes in Maya and used them as references for keeping the perspective correct, as can be seen in the concept picture below displaying a market street in the slums. I have used various other references from image-googling keywords like “slums”, “markets” and “stand” just to get a sense of the details needed to portray the scene and the looks of a cyberpunk market.

One obstacle in working with cyberpunk is the amount of detail that needs to be put into the environment. The image I have of a cyberpunk slum is that everything has been built on top of eachother – vertically – due to the lack of space to build new structures. It’s a challenge to portray this in any authentic way.

Concept art of market street.

The next step in the graphics department will be to create more general concept art for the specific objects in the game levels. We will probably write another post about that in the future.

– Kim Jonsson (technical artist)


Like Kim said, when the lead technical artist and the game designer have agreed upon a thumbnail, the process of making the concept art begins. I bet you have a certain opinion of what concept art means but for us it could mean a bigger, more worked on image. It could involve colorisation or adding more details. Also, it could just be to clean up the previous sketch. A concept art image is not as restricted in time as the thumbnail sketches, however, the time given is not infinite.

When drawing the concept art for the police and the weapons, I had been given feedback from the leads on what they liked. The final results were a combination between three or two different thumbnails made into one. It felt a bit strange trying to meld several very different sketches into one. As if I each time ended up with a strange mixed breed, escpecially with the guns.

Compared to the buildings and surroundings, I had things that did not really need to express much mood, and thus they became simpler images with only basic colors.

Can you see the mixes made by looking at these and the thumbnails in the thumbnail post?



-Matilda Karlsson (technical artist)

Making thumbnails

When the overall visual design has been set we start doing thumbnail sketches. These are sketches done within ten minutes a picture. The trick about thumbnail sketches is speed and the moment you slow down, you shold consider yourself about finished with your picture. The police sketches, for instance, were made by drawing on top of a basic pose of a man to avoid unneccessary drawing. There should be no time for thinking when doing thumbnail pictures, only drawing. We both used Adobe Photoshop and a wacom4 drawing tablet for all the drawing of the thumbnails.

It was important not to zoom in on the picture when drawing because the harder we made it for ourselves to draw detail, the less detail was going to be drawn. And it worked for the most part.

I felt a bit intimidated because of the stress level coming with the time limit. When you draw it can be a peaceful experience, but that usually also equates to slow work for a lot of people. I think that description fits me very well but the more I drew, the more fun it became to push myself to finish a little bit faster.

The thumbnails for the weapons were more complicated and were not hurried as much as the police characters. This might have been unwise due to the pictures becoming a bit to complex and time consuming, but it helped with having more straight and clear lines. With the time aspect in the back of the head, the weapons took shape in a reasonable pace.

Each piece took around 10 minutes to make, give or take.

Each piece here took around 5 minutes to make, sometimes a few minutes were added due to me getting caught up in details.

– Matilda Karlsson (technical artist)


I agree with what Matilda wrote above, that It was fun working with thumbnail sketches because you have to constantly push yourself to finish a sketch a little bit faster every time. For me this was a new way of dealing with creation of concept art and even though it was difficult to keep within the time frame of each thumbnail, it’s a great way to improve your drawing skills.

The concept art I’ve made pictures the environments of the slum parts in the city, and some scenario-related structures, architecture and machinery. I tried to finish each thumbnail off with some general shading to add, to a small extent, some detph to the images. Each frame took between 5-15 minutes to create which is a stretch owed to my modest drawing skills.

Thumbnail sketch for residential area

This is the residential areas of the slum and I was going for three things here: tall buildings emphasizing how the people are really living on the rock bottom of the city as seen in frame 1, 2 and 6, vertical construction as seen in frame 7, and early 1800’s industrialism as seen in frame 8, 4 and partially 5. I accidentally drew a concept for transportation in frame 3 but I left it in the thumbnail anyways.

Thumbnail sketch for market area

As with the finalized concept art images following these thumbnails, I wanted to focus on some general details typical for the cyberpunk theme. In the image above I wanted to highlight the neon signs and advertisements visible on every wall and stand in the slum markets. And as with the concept of the residential area I tried to get a sense of vertical construction, that buildings, homes and other premises have been built on top of another due to lack of space (and freedom).

-Kim Jonsson (technical artist)

Creating a Visual Theme and Style

Art is often a big part of a game, so establishing a visual theme and style is very important during the development for the art to be homogenous, and for it to match the narrative and the gameplay as closely as possible.

When we started defining the visual theme we knew what the basic gameplay would be, namely that the player would control riot police squads to keep riots under control in an urban environment. We also knew that the actions the player take in the game should feel meaningful and have an impact on the player.

With this in mind, the first thing we did was decide on a visual theme that would fit this experience. We ended up with a grounded cyberpunk theme set around 50 years into the future. In this theme we imagine a world in grave imbalance in all areas from social classes to the environment, so finding meaningful conflicts in this realm would be pretty easy. Some examples of conflicts are lack of food and clean water, human labor being worth very little, huge disparities between rich and poor people, transhumanism, etc.


With a theme broadly defined, the visual style was next. After discussing different styles and what we wanted to convey to the player, we decided on going for realism. The riots should feel real and the players’ actions should feel as meaningful as possible, so this style made the most sense. We also wanted to challenge ourselves to create a realistic looking game environment.

After the visual style and theme had been defined, we created moodboards for a variety of different areas. This started by going onto image sharing and searching websites and downloading any image we thought aligned with the view of what our game would look like in terms of design, colors and atmosphere. These images were then put together into a single image that represent a specific area of the game. We made five moodboards in total, for the high, middle and low class housing areas as well as for the rioters and the riot police forces. These will help inspire and guide us to create art that is homogenous throughout the development process.

Written by Lukas Orsvärn


The core mechanic in Riot is crowd control. The crowd is made up of a large number of rioters and it is important they move in a way that feels realistic. To make this happen we are using something called potential fields. Simplified, it is like simulating magnets: the different influencing units, called agents, each have a charge that is either repulsive or attractive to other charges. With magnets the same type of charge is repulsive and an opposite charge is attractive, but in our software implementation, we have no such limits. For instance, the rioters each have the same type of charge, but we want them to try to stick together which means we want them to attract each other. Thus the rioters are attracted by the same charge. Potential fields also give us the freedom to implement any type of curve for the charges so that we can make the rioters repulsive very close to the center and attractive further away. This way we make the rioter agents avoid getting too close to each other while still trying to stay in a group.

Potential fields for each unit shown by green and red circles.
Potential fields for each unit shown by green and red circles.

Potential fields is a new technique for us, making it hard to asses whether we can make it behave exactly the way we want: Enter prototyping! With prototyping we get to implement a technique to ensure it is what we want. As our development team consists of six programmers and only so many can be working on the core or graphics engine at any one time, whoever not working on those areas can work on the prototype thus maximizing the work done.


For prototyping, Unity was chosen. It was the first time I ever used it, which initially meant a lot of learning what I could do. It was fairly straightforward though so I quickly got a good idea of how to do what I needed. Unity is by this experience a great tool for doing simple and even fairly complicated things quickly.

The prototype

We rapidly got a working prototype showing much promise for potential fields. The first prototype was made for a pitch and had to be finished in a short amount of time, leaving it somewhat of a mess. After the pitch it was scrapped in favour of a new prototype with a structure that had a closer resemblance to what it would look like in our game engine. This, however, suffered from severe performance issues due to the way Unity is made and had to be abandoned by a third version more similar to the first version. However, as much code could be recycled, not much time was lost doing this.

Police (blue units) affecting a crowd of rioters (black units)Police (blue units) affecting a crowd of rioters (black units)

Potential fields is a very performance heavy technique, with a complexity of O(n2), of which we are very aware. The prototype gives us an excellent opportunity to try different optimisations and observe their effect on the behaviour of the algorithm. One optimisation we evaluated was to spread the potential field calculations over a number of frames. This gave the agents a weird behaviour that was hard to control. Thus, it is an optimisation deemed best to avoid, if we can help it.

Pros and cons

There are several obvious advantages to prototyping. We get the chance to evaluate one or several possible options for creating the desired game mechanic, determining which suits us the best based on performance and behaviour. It offers an isolated environment for developing and measuring the algorithm and of course: that it can be started day 1, letting us get a lot of research and, if needed, tuning done while the game engine is still not developed enough to allow for implementation of the AI system.


As for drawbacks, an obvious one is the time it takes developing the prototype. In our case, this is not a very severe drawback as there is little else to be done at this point and as the research needs to be done anyway. Most of the knowledge obtained during the prototyping phase will be useful when implementing it in the game engine later.

Moving forward

None of the code can be used directly, as Unity uses C# and our game engine uses C++. However, the concept and much of the algorithms can be translated directly. No matter how much tuning can be done in the prototype, it will still be needed for the game. This means it is of no use spending too much time on tuning during the prototype.


The chosen technique is very expensive so optimisations are needed. Performing the calculations over several frames was a suboptimal solution so other options need to be explored. Potential field calculations are in their nature very well suited for parallelisation, so both CPU- and GPU parallelisation will be evaluated.


The first video shows off potential fields, the main focus of our prototype. The second video shows off something we’ve started to explore using the prototype in the last few days, flow fields, which we will hopefully be able to talk about more in the future.


Written by Kim Restad

Welcome to XYZ and RIOT

Riot is the working title of our game, to which this blog is dedicated. Very simplified, Riot can be described as a mix between a Real-Time Strategy (RTS) game and tower defense. The game takes place in a near-future cyberpunk setting, where human augmentations and robotics are about to become more and more common.

As a player, you get to pick from several different riot scenarios where you control the police and your objective is to make sure the riot does not get out of hand. This is achieved differently in different scenarios: be it subduing the rioters, making sure they get to their destination without making too much of a mess or simply preventing them from reaching their goal. You have the choice of doing this as peacefully as possible, or using whatever force necessary to accomplish your mission.

Before a mission is started, you are faced with a planning stage where you get to purchase units as well as equip and upgrade them. This is where you decide on your setup for the scenario – as soon as it has started, you cannot add or change units, so choose wisely.

Each scenario will offer different challenges such protecting an important economical meeting, escorting protesters or breaking up a full-scale riot. These scenarios will promote different solutions, some a more peaceful route while others will ignore any violent acts you commit.

At the end of each scenario your result is presented with statistics of how well you managed: how many rioters were arrested, what objectives you managed to complete, how many units you lost and much more.

This developer blog will let you have insight in the process of creating Riot. It will be continuously  updated with new posts discussing different areas of the game development so check back often for new articles. Next up is an article detailing prototyping: why, how and results.