1 @gosamihai

2 @gosamihai

-After creating our studio, we got a 3rd party engine,

spent a big amount of money on assets from the store,

quickly put together an unoptimized game

and in the end we gave 50% to a publisher to do nothing for us

-Nah, I’m just kidding, this talk wouldn’t make much sense then would it?

-We actually did quite the opposite

-The talk is about how we made our game faster, cheaper and overall better by building our own technology.

-Nowadays everything is about using this or that technology that’s *supposed* to accelerate development, but there are ways you can do much better

3 @gosamihai

-If you’re using Unity or UDK, don’t leave out just yet.

-Actually everything we did can also be applied to 3rd party game engine

4 @gosamihai

-I’m gonna make an analogy with this piece of art right here.

-Believe it or not, this is a bird. The artist actually wanted to show the “essence” of a bird, whatever that means

-So he started from a bird, you know, with wings… and started removing parts of it: the head, the wings, the feathers, until only the ‘essence’ remained.

-Abstract art is silly, but I liked the APPROACH to building it.

-So I thought..hmmm…maybe we can apply this approach on game technology…

- I wonder how…

5 @gosamihai

-Initially didn’t think about writing a presentation about our tech, because I thought it was too simple. Who would want to know about it?

-Everything these days is about the next DX or the next AA game-changing technology

-But after reading various development blogs I saw that many developers are struggling with their games, even with such easy access to tools and resources.

-I thought: maybe they are overcomplicating the process instead of going the other way, which is to simplify the process

-All we did was simplify, that’s all!

-We simplified and ignored almost everything that you’re “supposed” to do when making a game.

-Just like in the bird example, instead of adding tech, we removed tech.

-We kept removing until there was almost nothing left.

-Sounds counter-intuitive? This about it this way: simpler means faster, cheaper and more reliable.

-And to prove it, our game runs on really old hardware, even with integrated GPUs, and also has an extremely small amount of bugs and crashes. Besides some issues with Windows drivers, we very very rarely received crash reports.

6 @gosamihai

-real time tactics game

-released on 5 platforms, including mobile.

-We went through crowd-funding on our own website, greenlight and published it on Steam and many other store fronts

7 @gosamihai

8 @gosamihai

-It doesn’t look THAT simple, right?

-It’s not triple A, but it’s not the ‘80s either

9 @gosamihai

-It’s a realistic SWAT game, where you take down terrorists, bust into drug dealer hideouts and rescue hostages.

-The best thing about our game is it’s control system

-It’s a freeform control scheme, where you simply “draw” what you want the characters to do.

It was initially envisioned for tablets, but we later decided we had no experience on mobile so we transitioned the same control scheme on PC.

10 @gosamihai

-It was pretty successful for an indie game

-we got awesome reviews, received some awards and made a bunch of money

-I believe that a big part of its success comes from the efficiency of the development itself.

11 @gosamihai

-Let’s talk about development efficiency.

-Think about it, some old school games were made in a fraction of the time compared to today’s games.

-Remember Wolfenstein or Doom, Wolf was made in half a year

-That’s happening even though we have much better tools today and incredibly easy access to information

-And those guys actually had to invent stuff

-There are many reasons for this and depends on game, but the overall feeling is of much higher efficiency back then.

-could it be that we are overcomplicating the process and miss the big picture? That we no longer plan in advance?

-So, can we also do it nowadays?

12 @gosamihai

-For Door Kickers, the core engine was developed in just 3 months. Even after almost two years, with add-ons and a lot of updates, it’s almost the same.

-support for Win32/OSX/Linux/iOS/Android in just a few days for each

-This was all done from scratch in C++

13 @gosamihai

-Let me brag a bit more

-the game has a huge amount of content

-we had tens of maps made after realistic building plans

-random mission generator

-over fifteen hundred mods on Steam Workshop

14 @gosamihai

-First of all: Limited time/money budget: everybody has it.

-Just learning unity/udk can take almost all of your time budget if you have no experience with them

Had XP only with studio-proprietary engines

-This is a really important one: using an engine raises expectations

If you have support for all these high-tech features you WILL feel the urge you to use them, because obviously they look cool.

So if the engine supports something like PBR, you’ll say Oh, but all the new games use it, I must use it myself otherwise the game will look bad. But this actually has an impact on what type of resources you need, which in turn will impact your whole data and art pipeline, and two years later..

And this happens more than you would think so. It’s very easy to tick a checkbox without thinking of the consequences.

-Think about it: does you game only have static environments? Then you don’t need real time PBR or normal maps & specular maps.

-You also need to learn something while making the game. What’s actually beneath the hood.

What do you want to write into your CV if you need it? 3rd party engine programmer?

15 @gosamihai

-Back to the original bird… uh I mean concept

-Can we make something so bad-ass, that it outweights…

16 @gosamihai

-I’m not saying that 3rd party engines are bad, it’s just that maybe people no longer think about the overall process, they just start implementing the game using this or that tutorial and having unrealistic dreams

-It’s probably because of lack of experience and not knowing what is required to actually make a game, but that just adds to the point. You need to know what’s under the hood.

17 @gosamihai

-To do this, you need to know exactly where you’re going to end up, technically speaking

-instead of choosing an engine right from the start, think about what technology you need and don’t need

-because efficient development is about limiting technical features

-don’t think about sequels, you need to get this game done yesterday, so don’t think or plan ahead of the current product, keep your focus on making this game the best possible game you can make

-be realistic: Don’t set about making a space sim, and afterwards think about also making it an MMO and later an FPS where you can walk around the ships

-Do you really need an animated UI? Even if that’s so common nowadays, I’ve seen many triple-A games that don’t have one, just balance out the benefits with the time needed to implement a feature.

18 @gosamihai

-Now… let’s start removing stuff

-Stand alone editor: you would need at least a couple of months to do something good. We want to make things faster, not make your own UDK

-Implementing it in game uses the same game code, so WYSIWYG and less code to write: you don’t need to export/import from the editor, just work on the final file format.

-The downside is that UIs are harder to implement, so we will need to reduce complicated widgets to a minimum.

19 @gosamihai

20 @gosamihai

-Scripting AI? If you worked on something like this…I feel you

-What we went with…is sandbox behavior. Just place Ais in a map and they should handle themselves

-That’s part of the reason we don’t have a single player story mode

21 @gosamihai

22 @gosamihai

-UI editor? What do you want to do, make another Adobe Flash?

-what we have is a simple system where you manually edit an .xml file and hardcode coordinates

23 @gosamihai

24 @gosamihai

@gosamihai 25

@gosamihai 26

-It’s hard even to use a particle editor, not to mention actually implement it.

-Make animation sprite sheets for everything: fire, rain, snow, explosions. Pre-render them in Adobe After Effects or something and keep all their frames in a single sprite sheet. They will occupy quite a bit of space but that’s not really a problem nowadays. I’ll show you more about this later.

27 @gosamihai

28 @gosamihai

-You guessed it, we don’t need ANY tools whatsoever!

-If you implemented an in-game editor, the UI will be your limitation, so try not to add any configurable properties in the editor.

-It’s much faster to edit properties in a text file, than to add them to your editor, be it in-game or not.

29 @gosamihai

-By now you’re probably thinking: WHERE is this guy going to? There’s nothing left…

30 @gosamihai

-When we started out and I knew we were making a 2D game, I envisioned this workflow

…

-To make a game in 3 months, this is what we needed

31 @gosamihai

-This is how our editor looks like.

-The left hand tab there is where the objects are. That’s it: you just click on an object and place it on the map

-We later made it prettier for modding purposes, but this is what the game shipped with

@gosamihai 32

-If you’re thinking this I won’t blame you.

-But what if I told you that this is the best game engine in the world…

33 @gosamihai

-I’m sure you heard about unified lighting systems before, but I bet you never heard about unified everything

34 @gosamihai

@gosamihai 35

-I’ll get back to that, but some other reasons for it being the best engine in the world

-Cheap

-Very fast, we get more than 60 fps on any kind of machine. On mobile we capped it to 30 because it would drain out the battery.

-Invested 1500k and got 2M out of it

36 @gosamihai

-For unifiying everything, I started thinking about what’s a common denominator for all systems in a 2D game

-Since the game should only work with images, it means we must use some kind of image-processing algorithm

-Bresenham is used to trace a line through a 2D grid. You give it a start and end point, and you get which cells it goes through.

You’ll see how that comes into play.

37 @gosamihai

-This is what happens behind the hood of the game

-At runtime, we rendering all entities in an image

And from that …

@gosamihai 38

-For generating the collision map, we render everything to screen using IDs instead of color, so that we know which one is which and we downscale it

@gosamihai 39

-This is how the result looks like

-To check for collisions we just trace lines into this map using Bresenham, for bullets for example

-Dynamic objects are written on/off each frame using Bresenham

40 @gosamihai

-For pathfinding we use the same image that we’re using for collision. When an object moves, we modify it into the original image and the modifications are reflected in pathfinding, so dynamic objects are also taken into consideration when doing pathfinding.

-We can use a few bits from the initial image to keep costs

-Jump point search removes this need

41 @gosamihai

42 @gosamihai

@gosamihai 43

-We shoot 360 rays from each character, with 1 degree accuracy.

-During this phase, we also gather collisions and all objects of interest in the character’s FOV, to be used for AI.

-Downside: you lose precision very far away, because we only do 360 rays and 1 degree accuracy near the character is not enough very far away.

44 @gosamihai

-We use this geometry to render the highlighted portion of the FOV

-We also use an accumulation buffer to store a separate FOV for areas where we have looked in the past

45 @gosamihai

@gosamihai 46

-Same process is applied for enemies, just that we don’t render their FOVs

47 @gosamihai

@gosamihai 48

-For a big map, it can get quite heavy, especially if there are very long lines of sight.

-The Bresenham algorithm is fast enough though, that we don’t need to do additional optimizations, we had to implement multi-threading on mobiles though.

49 @gosamihai

-Using the same collision map

-For AO we just trace 360 rays around each grid cell and see how much it gets occluded by surrounding areas

-For directional we just smudge shapes in a direction. It’s a gross fake, but it looks decent. For other places we have custom Photoshop shadows.

50 @gosamihai

51 @gosamihai

-So we’ve unified everything using a single image, onto which we apply Bresenham or the A* algorithm

-Bresenham is also used for sound reverb calculations: we calculate how big an area or room is and depending on what objects are in that area we apply reverb to sounds. For example if it’s a small room with toilets in it, the sounds there will have a big echo.

-The key to our pipeline is that when adding content, a developer doesn’t need to do much to create a new object.

-There is no need to define object collisions, lights or AI properties. Everything is generated at runtime.

52 @gosamihai

-Implementing various loaders for file formats is definitely time consuming, so let’s simplify that as well.

-That’s everything we need for editing maps, images/textures and sounds

-We only added compression when porting the game to mobile, because the TGA/WAV files were too big.

-Almost no third party libraries

53 @gosamihai

-One of the biggest issues in porting the game on multiple platforms is the graphics API.

Use DirectX and you’re fucked on everything else excepting Windows and XBOX

-So we must use OpenGL, but there are a bunch a variations on that also

-If you know about OpenGL, you know that the mobile version, OpenGL ES, is just a subset of the desktop OpenGL. So if you use only the OpenGL ES functions on desktop, it will work by default on mobile also.

-So right from the start, we only used functions & capabilities existent in OpenGL ES, even on PC. That means that when we ported the game on iOS and Android, the game just ran, no modifications whatsoever.

54 @gosamihai

-premature optimization is the root of all evil, you only need to optimize the biggest consumer

-using texture atlases just complicates the pipeline: every time you modify something you need to recreate the atlas etc.

There’s little gain in terms of speed except for very/very complicated games. For ours it wasn’t an issue, especially if you sort your draw calls by texture.

-we never free memory in our game, at least in the PC version. Everything stays in memory at all times, that’s why we have very fast loading times.

All data in the game is a bit above 1 GB (uncompressed data), so even if you keep playing the game and load all maps in a single session, the game won’t occupy much more than 1 GB, that’s nothing for today’s hardware.

-For HDD space is even less, and being uncompressed data it zips quite well, so the installer is only 3 or 4 hundred MB.

-for sprite animations, we just made all frames equal to the largest frame

55 @gosamihai

-this is how a sprite animation sheet looks like in our game

-very wasteful, but easy to code: you don’t need a separate file for where each frame is located

56 @gosamihai

-this is how it should look like in a “smart” game, less than quarter the size

57 @gosamihai

-nine C functions

-some of them you may not need depending on the game, the main ones are the Window creation and input handling

-most people use SDL, but frameworks like these have become very bloated, offering all kinds of services.

58 @gosamihai

- OSX/Linux took two days each, with very small modifications afterwards.

59 @gosamihai

-Not saying that we found a silver bullet, but the approach works on any game.

60 @gosamihai

61 @gosamihai