Archives for : October2016

CC: Building Generation

aptsWe have a game map of considerable size which means we are going to need a lot of buildings. . This would be stupid amounts of work to do by hand and just copying the same building over and over wont cut it either so we decided to generate the majority of the buildings.

Buildings are made using a whole bunch of premade panels. This makes it easy to just place a ton of them through code to build a structure. It also allows us to change the width and length of the building quite easily. After generating our structure we simply place a door in the middle and we’ve got a building. So that was easy, huh? Well, that’s what I thought too, but then the game designer suddenly wants to the building to be enterable and feature apartments. This is where trouble started to show its ugly head.

After much back and forth we ended up going with a “hallway in the middle and apartments along the walls”-kinda setup. The one caveat was that the apartments would need some kind of minimum size. This would end up crippling our ability to resize the buildings due to apartments being cut short when the length of the building wasnt divisible with the length of the apartments. Another question was how we were going to create the apartments. Placing a thousand different objects with poorly configured pivot points through code wouldn’t be easy so we ended up compromising. Apartments were to all be the same size and buildings would just have to be generated based on that. The apartments are just big enough to feature a reasonable amount of furniture without compromising the players ability to maneuver it.

We now had both floors and apartments on those floors but no way to get to them. Since we had no plans of implementing noclip as a part of our core gameplay mechanics, it would seem I’d have to go at it again and generate some stairs. So I promptly removed my self from my lazy ass and went to work.

Hardly had I finished those god forsaken stairs before another team member, annoyingly, noted that my beautiful buildings would take up way too much performance containing all those apartments. Bitterly, I had to let the ousted thought enter my brain again as I started plotting the murder, I mean plan, for how I was going to save the GPUs of all our future players. Honestly, the solution ended up being simpler than the mind of a trump supporter and creating it was even easier than lying to one. We were simply going to wait to generate the interior until the player entered the building and then destroy it all again once they left.inside_apt

Fool proof plan but once again it was foiled by our game designer who pointed out that the interior wouldn’t be the same if we just generated it all over again every time a player entered. I was back to the drawing board. Luckily computers are magic and setting up a seed was easier than finding pixelart on a ludum dare submission page.

With trouble slowly receding back to its lair, we went to, as Jonathan Blow would say, “put it in the game.” Turns out it’s kinda hard to visualize just how your city was going to look like based on a bunch of invisible points, that were supposed to resemble buildings. This is where my microscopic experience with Editor scripting came into play. I created a couple buttons on our building generating orb. These allowed the building to be generated in the editor so you could see wether or not your newly placed building was going to block half the highway. This made building our map much easier.

Confident in our generated little wonders, we booted the game and in a display of pure strength our underweight 720Ms mustered an astounding 15 fps. Although highly cinematic, it didn’t quite feel right so back to the drawing board once again. We noticed that Unity’s standard culling technique, fresnel culling, was still rendering all the apartments in the building even when they weren’t visible. This lead us to use occlusion culling instead. Occlusion culling basically only renders what you see. This means that looking at any given building, you’ll only load what you actually see and not, say, the apartments behind it.

And that’s the story of how, I, Hjalte Tagmose, writer of this blog entry, spent way too many hours on something that wasn’t even a major priority! Viva la REVOLUTION!


Did this post not contain enough nitty gritty technical details and complicated code snippets for you? Well then tune in again next friday, when we’ll be talking about networking and how it has reduced our lovely founder, Stefan, into a sleepless mess of a man.

DD: Teamwork and Missions

Hello and welcome to Design Day, this is Asger, game designer of Station 5.

Last week, I talked about the playground in Station 5, and how people have to interact with each other and the world. Today I want to talk more about multiplayer and teamwork in our game.

To be successful in Station 5, all players have to work together. A standard mission is completed in three steps.

First step is to get the mission details and use those to load up the firetruck with the right equipment. In order to do this as fast as possible, and speed is needed as the houses are already burning when the players receive the alarm, the players have to split teamwork, so while one player is at the computer, reviving the mission, another player is emptying out the firetruck, and making it ready for another load, whereas all the player have to find the items as fast as possible, and get in the truck.

Secondly, the players have to drive to the mission site. The player(s) who is driving cannot hold a map at the same time, and another player has to navigate while the driver drives. This enforced teamwork and communication between the four players. Players can take other actions as well, for instance driving in the back of a truck, like the picture underneath, or changing light signals.

Billedresultat for firetruck ladder

When the players arrive at the mission site, they have to rely on teamwork in order to complete missions in a timely and safe manner. Players have to rescue people and safe the building from burning to the ground meanwhile, an example being a blocked door, with 2 people inside, while the stairs are burning. Three of players are moving into the building, one with an axe, one with a ladder, and one with a fire hose. The fourth player is connecting the firehose to a fire hydrant, located outside the building. The guy with the hose is starting to getting control over the fire, while the ladder is being placed. The last player joins the other three inside the building bringing a fire extinguisher, and everyone except one moves up the building, trying to fight their way into the victims. When they get to the right apartment, the axe guy breaks down the door, while the player with an extinguisher is putting out a fire. In order to make a small passage for the 3 guys. They get to the victims, drops the axe, and carries the victims out, while the 4th guy is getting the situation under control.

This is just one way of tackling a problem, and other, more creative, and possibly better, ways to tackle the mission is of course an option (for instance, the players left behind an axe, and didn’t focus much on saving the building).

We look forward to see you come up with creative ways of completing missions, once the game is ready for release.

That was all for this time, thanks for joining us for this Design Day. If you want to see more of the development of Station 5, feel free to follow us on Facebook or Twitter.

See you next week! J

AA: UI and Animations

Hey there, Michael & Jesper here.

In todays blogpost we will talk about Station 5’s user interface also known as UI and our current progress on animations.

UI (Jesper):

Hey, my name is Jesper, i’m one of the artists working on Station 5 and also one of the original founders of InkDropGames.
I’m here to talk about UI today, and the general design idea behind the few UI elements we want to have in the game.

First of all we want our gamescreen to be pretty clean. We do not want big bulky borders or obstrusive elements, therefore we only want the few elements we actually need to clearly tell the player(s) what he can do and what is happening.

Since we made the choice that the game should be voxel based we thought, of course all of the 2D elements should be pixelart, to keep a coherent style.


Here you can see a speedometer, a icon for showing if your blue lights are on or off (even though that is quite obvious if it is, but it is  more to show that the player have the ability to turn on/off the siren) and lastly a icon to show if the next light regulation is showing red or green, and that you can change it.

We ended up with quite a “high-res” pixelart style. We decided to not use noise, so our elements look smooth and clean. Noise in pixelart has its home and charm, but we decided that it did not belong in our game. All UI elements is handdrawn in Photoshop and implemented using Unity’s own UI system.

Going forward we still need a lot of  UI elements for things like, the title menu, missions screens and so on.
Keep an eye on our Twitter, to keep up with our progress.


Animations (Michael):


Hey, Michael here! I’m the Technical Artist and Animator working on Station 5.

So it’s time to talk about the fabulous animations in the game.

There have been a ton of animations to do, and still is, we needed to have animations for everything rather fast since it would help shape the feel of the game, so a big part of my work have been focusing on making the animations satisfying and funny to look at.

So far all the basic animations are in place, such as running, walking, jumping and strafing. Though there are still a lot more animations to come, I can give you a little sneak peek of an animation of our player animation when he is carrying 2 handed stuff, such as buckets and ladders, etc.


All Animations are made in 3DS max and imported directly into Unity using FBX.

There is alot to look foward to when it’s time for polishment of the animations, we have a lot of funny and goofy ideas. Everything from special taunts towards other players and special interaction animations, to more detailed basic animations, and a few funny easter eggs.

That’s it for this time folks, stay tuned on our website for near daily blogs or follow us on Twitter and Facebook for more frequent updates


MM: Organizing a group

Hello and welcome to Miscellaneous Monday, this is Marc.

Today I want to talk about working in a group with focus on what we’ve learned ourselves.

First, I want to talk a little about our group. Our group consists of 8 students from Denmark, who have very different levels of knowledge and experience in game development. We were not all used to work together, but we all knew who everyone else were. Luckily our fields of knowledge are somewhat spread between programming, 3D-modelling/animation and 2D-art. The only important field of knowledge we really lacked in was sound and music. I encourage you to watch this week’s Summary Sunday video to see what I’m talking about. Anyway, it has been relatively easy to spread work roles and tasks between us because of our diversity. With that in mind, I want to give a list of tips we’ve learned so far in our development of Station 5:

  • Have diversity in group member’s fields of knowledge.
  • Group work doesn’t succeed if nobody is ready to compromise.
  • Maintain a high level of intern communication, either by being together physically or using com-programs like Skype.
  • Share files and everything else on a common cloud-service, like Google Drive. Unity also has a new feature called Collaborate which allows us to share assets and scenes, similar to using an external git-program.
  • Have one or multiple clear and visual board(s) with work tasks that everybody can see. We use a service called Trello to communicate work tasks and show progress. With Trello, we can assign group members to tasks and use labels to indicate what a specific object needs. Here is an example of a board we use to track progress on 3D-models:
  • Work morale and efficiency is highest when all group members are equally productive and willing to work. Bad morale is a bitch.
  • One of the most important things in any project is to be clear about expectations to each other and the project as a whole.

Alright, this is it for this week’s Miscellaneous Monday, I hope you enjoyed it.

For more InkDrop Games content, be sure to follow us on Twitter, subscribe on YouTube, like on Facebook and keep an eye on our blog!

Summary Sunday – Episode 2

CC: Traffic Simulation

Hello world!
Today its time to dig down into the backend of how we simulate traffic in Station 5.

Our traffic simulation is still in its early stages and needs a lot of work, but the basics are down and vehicles can navigate the network of roads without mayor problems. But why even make a traffic AI from scratch? Unity’s asset store already got multiple ready made traffic AI systems. iTS Traffic System, TI Traffic AI, A.I Car Traffic PACK, just to name a few.

The problem with all of these solutions, is that none of them is very versatile or adaptable. Dealing with traffic AI in an chaotic open world game, control over the code is key. Adapting any of the above solutions, to work with physics and collisions, proves to be a much more complex undertaking, than just rewriting it all from scratch. Not saying that all of the above solutions are bad, but they are just not what we needed.

So how does it actually work?
First of all we need to look at the criteria’s for how we want the AI vehicles to behave

  • Be able to accelerate and decelerate and semi realistic rates
  • Wheels suspension to make it look like a real vehicle, and not a block translating.
  • Navigate the road network
  • Stop for red lights, players, road blocks and other AI vehicles
  • Spawn and despawn when inside or outside the players viewport.

The first 2 criteria’s hints that we need a way to simulate wheels on the vehicle. Fortunately Unity already got exactly what we need, “WheelColliders”! WheelColliders gives us the ability to add individual suspension to all 4 wheels, accelerate and decelerate using torque directly on the wheels and gives the vehicle a way to steer.

Setting the vehicle velocity. After November 2016, all roads in Seattle downtown will have a speed limit of 25mph, so our roads use the same limit to cap the speed of AI vehicles. To make the vehicles seems less “robot like”, they all have a random value that determines whether the AI will drive slightly above or below 25 mph.

Vehicles accelerate to a desired speed using a simple formular

(desiredSpeed - currentSpeed) * Acceleration Sensitivity

Where the desiredSpeed is most often the speed limit of 25mph, currentSpeed is the vehicles current speed in mph and the Acceleration Sensitivity is a value between 0-1 that decides how quickly the car accelerates, to allow for different kind of vehicles.

When a vehicle has to deceleration due to a redlight or a car braking in front, the vehicle calculates a deceleration value based on attaining the desiredSpeed in 1 second.

(V2 - V02) / 2(X - X0)
desiredSpeed = (targetVelocity - currentVelocity) / 2 * (Vector3.Distance(target.position, transform.position));


Detecting Collision. Every vehicle casts a SphereCollider in front of it, to check if there is a chance of a collision with the vehicle in front or if the player suddenly walked in front of the vehicle. If the vehicle in front gets within a specified range, the vehicle adjust its speed to match or be slightly below. If another car or vehicle gets to close, the vehicle “blocks” the brake and engages the handbrake, effectively applying the maximal amount of deccaleretion within the laws of physics


End of the road. When a vehicle hits the end of a straight road or an intersection it has to decide on where to go next. Currently to simplify things we only have 3 possible situations, based on the vehicles current lane.

Far-left lane Left or straight
Far-right lane Right or straight
Any center lane Straight


If the intersection has a traffic light the vehicle will wait for green, before choosing a new direction. U-turns are not a thing as it doesn’t look good and have a bad habit of creating collisions.

That’s all for today, if you have any questions you are welcome to post them in the comments below or on our Facebook or Twitter

DD: Developing a playground

Hi there, welcome to Design Day.

My name is Asger, and I’m the game designer of Station 5, and I want to write about the core design of Station 5 today.

The most important part of Station 5 is the way you, as the player, is able to interact with the other players and the world. We want the players to be able to think of something, try to do it, and see what happens. We want it to be fun to interact, and react, to the things happening in the game.

So how do we do that?

First of all, we have to make sure that the players have fun interactions with each other. What happens when a player loads the firehose on another player? What happens if they drive the firetrucks into each other? How well can they complete a mission with structured teamwork? Questions such as these are needs to be answered, so we can develop the consequences of such actions. If a player shoots a teammate with water, the teammate will stumble backwards and trip. If the two firetrucks crash into each other at full speed, they might catch fire and be ruined.

We want the players to play with each other, experience meaningful consequences, and be encourages to dive deeper into the playground.


(We apologize for the low quality GIF)

This kind of goofy elements is what we hope will carry the game, and make it great, and it is therefore something we consider in all aspects of the design, from animations to car AI.

The animations have to be exaggerated and happy, the fire should burn fierce, but not to serious, and the players should be able to be knocked down by cars, but not die.

These things are the most important parts of Station 5, and this is what we are going to try to create on our trip.

That’s all for today’s Design Day, thanks for tuning in, and see you guys tomorrow for Coder’s Corner.

AA: The world of voxels

Hello and welcome to Artists’ Articles, we are Marc and Hjalte!

As you may know, our game’s models are made out of cubes named voxels. Voxels can be viewed as the 3D-version of pixels. Some games like Crossy Road and Cube World also use voxels to make their 3D-models. While it is possible to make voxels in other programs like 3DS-Max, it is far more efficient to make the models in a voxel-program, such as Qubicle (see Here are some examples of our work in Qubicle:

treeseses stopsign

There are many reasons why we chose to go the voxel way. First, Making voxels heavily  reduces the time it takes to make our models. Going for a 3D game with this short development span means we need to cut time wherever we can. Second, going for voxels make the game feel more cartoony and fun, which is exactly what we are trying to go for with our game. Making the game too realistic or too serious would do more harm than good. Third, we are used to working in voxels in previous projects. Check out Above the Skies on our website to see what we’re talking about.


This week we’ve been working on the fire station itself. The station is of course modelled based on the Station 5, which the game is also named after.

Due to high amounts of individual voxels in big complicated structures like Station 5, we’re creating the individual parts of the station seperately before mashing them together. This means our sensitive and fragile graphics cards wont break their nails trying to render it all, which in turn gives us a smoother modelling experience.

Replicating the station in voxels is a process of looking at the station and trying to recreate it. This can be difficult with just a picture or two, but thankfully we chose a real world location, which means we can look at our structure in Google Maps and get all the angles. Still, it seems the google car that took those photos didn’t possess the ability to fly, so we still need to use a few drone/helicopter shots.


It’s also extremely important to keep scale in mind when creating a structure like this. The fire station is your home in the game so of course players and fire trucks need to fit inside the station, but it also needs to be comfortable size so it doesn’t feel like a big empty hall or a cramped attic.

To solve this we use fire trucks and player models when creating our buildings, so we can constantly see the relative size.


That’s it for this edition of Artists’ Articles, feel free to ask any questions in the comment section below. We’ll see you next tuesday for more artsy endeavors!


MM: Development Blog Explained

Hey everyone!

Today it is time for Miscellaneous Monday. But what is Miscellaneous Monday?
Everyday of the week we upload a short post here on the website. Each day has its own theme with Monday being “Miscellaneous”, which kinda means it doesn’t have a theme, but whatever 😛

Only want to hear the geeky stuff? Or wanna hear how our artists are shaping the look of Station 5? Then take a look at our blog schedule below! It never changes, so you wont miss anything.

  • Monday: Miscellaneous Monday – Surprise corner.

  • Tuesday: Artists’ Articles – Artist screenshots, videos, reasoning.

  • Wednesday: Bugsmasher Blog – Bug fixes, how we did it, known bugs, how we will approach the problem.

  • Thursday: Design Day – Features in the game, why they are added, what we do to tackle problems.

  • Friday: Codey Corner – Code from the game, how we approach coding problems and optimization.

  • Saturday: Screenshot Saturday – Screenshot from the game, with explanations.

  • Sunday: Summary Sunday – Video, containing most or all of the developers.

Miscellaneous Monday is the only day where anything can happen, as nothing is planned.

If you haven’t already we encourage you to go watch our Summary Sunday video, to get up to speed on what Station 5 is.
To get even more frequent updates you can follow us on Twitter or like our Facebook page.

That’s all for today, but remember to come back tomorrow, where Hjalte and Marc will talk about the art style of Station 5 and how we make 3D models and art for the game.


Summary Sunday – Episode 1