April 2, 2014 6:00 PM | Staff
Initially, Goat Simulator was a way for us to play around in Unreal Engine 3, try something new and train our new programmers in Unreal Engine 3. Like I described in my last article, we never expected we would end up making it into a real game, launched on Steam yesterday. Luckily, both getting a working prototype up, and finishing the game went extremely fast due to the tools we used.
Fast development for Goat Simulator has been crucial two times actually. The first time was some time in January when we decided to make the game as a joke, as we never would have decided to play around with the game from the start if it would take two years to get all the basic features working instead of two weeks. The other time we were saved by fast development was when we decided to make Goat Simulator into a real game that we would release on Steam. If the development of the game into a final product would have taken years instead of months, big chances are that we’d end up adding features that are really not necessary, we’d take the whole thing too seriously, and the the game would end up being bloated, or as we’ve been saying at the office; too “try-hard”. In fact, our design philosophy at the office has been “try really hard to make it look like you’re not trying too hard”.
kind of like this
Luckily, the choice of Unreal Engine 3 for Goat Simulator has been ideal. Because of the power of Kismet and the built-in features in the Unreal editor, we’ve been able to put our game designers and even some of our artists on scripting the level design content since day one, and already in the afternoon we had a table with props on it that you could run into with a goat. Unreal Engine’s built in fracture tool worked okay, but NVIDIA’s PhysX and Apex let us really make goat mayhem beautiful. We can’t make every single object destructible because of performance issues, but fracturing windows, fences, barrels and even an entire gas station was very fast to implement and worked like a charm. Creating fracturing objects was as easy as setting the basic variables for the fracturing, importing it to Unreal Engine 3 as any other mesh, and then placing it somewhere in the world.
an early alpha image of a barrel being smashed by the goat's horns and NVIDIA's Apex
Programmers have mainly been adding specific features like the tongue mechanic, the score system, and other non-scriptable content. This resulted in very few pipeline dependencies (waiting for someone else to finish their job so you can do yours is the WORST), which made it the first project we’ve worked on that didn’t need a project plan whatsoever (not even joking), and because of that creativity in the office flourished. We would have never come up with so many dumb ideas for Goat Simulator content if we had a strict project plan. For instance, one of our artists thought it would be funny to have a jetpack as a goat, so he quickly modelled a jetpack in Maya, jumped into Kismet, scripted for the jetpack to spawn particles and apply force in a certain direction when you press a hotkey, and it was done. The fact that we could do these kinds of things directly inside of the engine without having to close it and compile has resulted in countless small and quirky features that took just a couple of hours to implement, but bring a lot of charm to the game.
The iconic tongue mechanic was also implemented rather fast by using existing Unreal 3 features to enable the goat’s tongue to work as a grappling hook extension to the goat. For the interaction between the tongue and other objects, we simply have a bone in the tongue that is hooked to any object you want to grab.
A screenshot of the tongue in action. I don't know what happened to that woman's neck.
To summarize, our choice of game engine and tools has been really ideal to this project, and sometimes its really worth it to bend traditional industry standards such as having an actual project plan in order to give more space for creativity and charm. If this article brings inspiration for other people to make dumb games really fast, then perfect! The game industry needs more dumb games.
Armin Ibrisagic, Game Designer
Line Jakobsen, Programmer
Mikael Mård, Artist
[Armin Ibrisagic wrote this using sister site Gamasutra's free blogs]