Did you know you can make successful games faster, cheaper and more reliable by building your own tech instead of using a third party engine? With a small team and no budget, we managed to make 2014's best tactics game (Door Kickers) in a very short time, with a huge amount of content, on 5 platforms. Without using any third-party engines or tools. Instead of adding tech, we removed tech. We kept removing until there was almost nothing left. Sounds counter-intuitive? Think of it this way: simpler means faster, cheaper and more reliable. Learn about the extreme simplicity of the production pipeline and the "unified everything" game engine used for Door Kickers. Learn that developing a game can also be done in a very smart and simple way, instead of spending years or $$$$$ on game engines. Learn how to focus on what is important and that finding the simplest solutions is usually the hardest.

1. 1@gosamihai

2. 2@gosamihai

3. -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

4. -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

5. -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

6. -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

7. -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. 8@gosamihai

9. -It doesn’t look THAT simple, right?
-It’s not triple A, but it’s not the ‘80s either
9@gosamihai

10. -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

11. -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

12. -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

13. -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

14. -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

15. -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

16. -Back to the original bird… uh I mean concept
-Can we make something so bad-ass, that it outweights…
16@gosamihai

17. -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

18. -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

19. -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. 20@gosamihai

21. -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. 22@gosamihai

23. -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. 24@gosamihai

25. @gosamihai 25

26. @gosamihai 26

27. -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. 28@gosamihai

29. -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

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

31. -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

32. -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

33. -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

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

35. @gosamihai 35

36. -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

37. -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

38. -This is what happens behind the hood of the game
-At runtime, we rendering all entities in an image
And from that …
@gosamihai 38

39. -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

40. -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

41. -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. 42@gosamihai

43. @gosamihai 43

44. -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

45. -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

46. @gosamihai 46

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

48. @gosamihai 48

49. -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

50. -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. 51@gosamihai

52. -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

53. -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

54. -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

55. -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

56. -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

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

58. -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

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

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

61. 61@gosamihai