How We Won Gamedev By Rolling Our Own Tech (no notes)
•Download as PPTX, PDF•
2 likes•1,537 views
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.
Recommended
More Related Content
What's hot
Similar to How We Won Gamedev By Rolling Our Own Tech (no notes)
Similar to How We Won Gamedev By Rolling Our Own Tech (no notes) (20)
Recently uploaded
Recently uploaded (20)
How We Won Gamedev By Rolling Our Own Tech (no notes)
- 1. HOW WE WON GAMEDEV BY ROLLING OUR OWN TECH Mihai Gosa Co-Founder/CTO at KillHouse Games
- 2. LET ME INTRODUCE MYSELF… ● Ex Ubisoft & EA, don’t hate me ● Now doing a bit of everything @ indie studio KillHouse Games ● Released ‘Door Kickers’ in 2014, now working on sequel.
- 3. WHAT'S THIS ABOUT? What if I told you…there is value in NOT using a 3rd party engine? You can make games faster You can make games cheaper You can make games better …by building your own tech?
- 5. HOW? … now let’s apply this to game tech Bird in space (by C.Brancusi) – $28M
- 6. SIMPLIFY! “Simpler” is: ● faster ● cheaper ● more efficient ● less buggy So, how “basic” can you get? Let’s see…
- 11. DOOR KICKERS ● 2014's best tactics game (acc. to "Rock, Paper Shotgun") ● 97% ‘overwhelmingly positive’ rating on Steam ● Over 300k copies sold on 5 platforms ● Grossed $2M+
- 12. DEVELOPMENT EFFICIENCY - CONCEPT Remember the 90s: ● Games much more complex than some of today’s would only take a fraction of the time to develop ● Where did we go wrong? So, can we: ● Create successful games without taking years on development? ● Without spending big money on tools?
- 13. PROOF OF CONCEPT – DOOR KICKERS Very low cost + fast delivery ● Custom-made engine developed in 3 months ● Only 1 programmer initially ● Available on 5 platforms (~2 days coding for each implementation) ● Budget of $1500 up to Early Access version
- 14. PROOF OF CONCEPT – DOOR KICKERS Huge amount of content: ● Over 120 maps modeled after realistic building plans ● Random mission generator ● Five campaigns ● Modding support
- 15. STARTING GROUND: WHY ROLL YOUR OWN TECH? Limited budget (we had 6 months to make it or break it) ● Unity/UDK can take from 1 to 4 months to use proficiently (without previous experience) Using an engine raises the expectations = more dev effort ● If you have support for real-time GI, Flash UI, you may feel the urge to use them Learn something in the process ● Programmers also need to have fun / be creative) You’re cheap and don’t want to give % of your game away
- 16. PROOF OF CONCEPT - HOW? Can we make something so simple, so efficient, so streamlined, so low-cost and fast that it outweighs the benefits of using a 3rd party engine?
- 18. PROOF OF CONCEPT - HOW? Get close to 100% efficiency in development ● Set fixed, final goals early on: only develop what you need, not what you "might" need ● Embrace limitations and restrictions (design & tech): do you really need that cool animated GUI? ● Ask not what you can add, but what you can remove
- 19. AN EXERCISE IN REMOVING… Stand alone editor? Too much work!
- 20. AN EXERCISE IN REMOVING… Stand alone editor? In-game editor: faster to develop, direct pipeline, WYSIWYG Too much work!
- 21. AN EXERCISE IN REMOVING… AI scripting per map? Too much work!
- 22. AN EXERCISE IN REMOVING… AI scripting per map? Should place AIs in a map and they should handle themselves. Too much work!
- 23. AN EXERCISE IN REMOVING… UI Editor? Too much work!
- 24. AN EXERCISE IN REMOVING… UI Editor? Who doesn’t prefer fast/simple UIs? Don’t you hate those games with low FPS in the main menu? Too much work!
- 27. AN EXERCISE IN REMOVING… Particle system? Too much work!
- 28. AN EXERCISE IN REMOVING… Particle system? Why not make sprite animations for everything? Too much work!
- 29. AN EXERCISE IN REMOVING… 2D animation system? ● Too much work! Specifying collisions, lights and entity properties? ● Too … much … work!
- 30. WHAT WE NEED… PUT IMAGES ON SCREEN AND IT SHOULD JUST WORK!
- 31. WORKFLOW 1. Artist makes PNG images 2. Designer adds PNGs to the map 3. Run game: everything works
- 33. THIS IS WHAT YOU’RE PROBABLY THINKING BY NOW… “Engine”
- 34. WELL, WE ACTUALLY DEVELOPED THE BEST GAME ENGINE IN THE WORLD Unified everything
- 36. WELL, WE ACTUALLY DEVELOPED THE BEST GAME ENGINE IN THE WORLD Why? ● Unified everything ● Cheap: no paid third-party software ● Very few bugs, very fast ● Huge return on investment
- 37. UNIFYING EVERYTHING Can we find the lowest common denominator for all system in a 2D game? ● Could all game data be contained in a 2D image? ● Could an image-based approach be used for all systems? Bresenham algorithm ftw!
- 38. UNIFYING EVERYTHING - Workflow Everything at runtime, no pre-processing needed. Render all entities in an RGBA image Generate pathfinding map Generate lighting/ambient occlusion Generate collision map
- 39. COLLISION MODEL GENERATION Render images to screen Entity ID instead of color Downscale 8x Apply threshold to remove shadow
- 41. PATHFINDING A* on the same collision map
- 42. FIELD OF VIEW Shoot 360 rays for each character, in the same collision map
- 50. DIRECT LIGHTING & AO AO and directional
- 51. DIRECT LIGHTING & AO ● Ray-trace using Bresenham in the same collision map ● Only done once, fast enough for load-time
- 52. ONE IMAGE TO RULE THEM ALL Bresenham for: ● collision detection ● field of view ● lighting & AO ● sound reverb A* for pathfinding Same dataset (image) for everything!
- 53. NOT SIMPLE ENOUGH? How many file formats do we need? The game is basically an XML, TGA and WAV loader ● These cover all basic needs: user-editable data, textures and sounds ● Simple format = easy to parse ● Uncompressed = very fast loading
- 54. NOT SIMPLE ENOUGH? Least common denominator for graphics API? ● OpenGL ES 2.0 ● Use OpenGL subset functions on PC, works automatically on iOS/Android
- 55. STILL TOO COMPLICATED? “Premature optimization is the root of all evil” applies to data as well ● Why bother with texture atlases? ● Zipping game resources would just make developing/modding harder ● Less than 1GB of data? Don’t bother optimizing for disk space or RAM ● 2D/sprite animation system? Just make all frames equal-sized quads.
- 57. SAME SPRITE SHEET IN A “NORMAL” GAME
- 58. BUT IMPLEMENTING MULTIPLE PLATFORMS IS HARD... This is our operating system layer for Win/OSX/Linux/iOS/Android:
- 59. BUT IMPLEMENTING MULTIPLE PLATFORMS IS HARD... OSX/Linux implementations took less than installing the actual operating systems iOS/Android trickier due to the myriad of aspect ratios and resolutions Currently considering PSVita and WiiU ports
- 60. DISCLAIMER No two games are alike, but challenging the status quo can be done everywhere ● We’re currently applying the same approach on the fully 3D sequel ● Probably won’t work for a finely-tuned AAA game This approach only works when developing from scratch ● Don’t bother if you have a well-established framework in place
- 61. END / QUESTIONS Email pintea@inthekillhouse.com Twitter @gosamihai
Editor's Notes
- -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
- -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
- -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…
- -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.
- -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
- It doesn’t look THAT simple, right? It’s not triple A, but it’s not the ‘80s either
- 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.
- -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.
- -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?
- 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++
- -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
- -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?
- Back to the original bird… uh I mean concept Can we make something so bad-ass, that it outweights…
- -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.
- -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.
- 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.
- 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
- -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
- 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.
- 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.
- -By now you’re probably thinking: WHERE is this guy going to? There’s nothing left…
- -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
- -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
- -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…
- I’m sure you heard about unified lighting systems before, but I bet you never heard about unified everything
- 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
- -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.
- -This is what happens behind the hood of the game -At runtime, we rendering all entities in an image And from that …
- -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
- -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
- -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
- -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.
- 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
- -Same process is applied for enemies, just that we don’t render their FOVs
- 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.
- 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.
- -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.
- -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
- -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.
- -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
- -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
- -this is how it should look like in a “smart” game, less than quarter the size
- -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.
- - OSX/Linux took two days each, with very small modifications afterwards.
- -Not saying that we found a silver bullet, but the approach works on any game.