Archives For unity

Game Engine Wars

March 22, 2014 — Leave a comment

GDC has bought with it the exciting news that many companies that make game engines are following in Unity and Game Makers footsteps in an effort to “democratize development” as Unity’s CEO David Helgason puts it. Most are following a subscription model with a variety of price points having been announced. This is great news for developers as access to professional quality features, cross-platform development and increased productivity just got a hell of a lot cheaper. I can get a fully featured game engine with full source for less than I spend on my internet connection per month. That’s pretty crazy.

The main downer I can see at the moment is most companies seem to be competing on cost rather than productivity. Wild eyed developers who see the shiny features and triple-A titles that the engines have powered are already announcing the death of Unity. In truth though the reason you buy an engine off the shelf is to save yourself time and money building, maintaining and improving one of your own. Most games companies are interested in making games not technology. As such cost is only really an issue if you end up spending more money than you save in increased productivity. Even at the indie scale we’re talking about such small number differences (tens of dollars a month) that even a mediocre productivity enhancement in a more expensive product will more than pay for itself many times over. Given the price point differences the cheaper end are really saying to me “look we know our product isn’t great but at least it’s cheap” only the cost saving isn’t radical enough to offset the potential loss in productivity between platforms. For example at this stage Crytek would have to pay me to use their engine over the competition. Their tool is just not as usable, which is not to say it’s a bad engine, because it isn’t, but the UX is just terrible.

Bad UX is a typical problem of internal tools. They are built in an ad-hoc manner to a “just good enough” standard and are often just plain terrible from the perspective of the user. Typically horrors involve choice paralysis, bugs and lack of a well designed workflow that matches users needs. Most companies survive this because they have a huge amount on institutional expertise to guide new users and new projects through the complex maze they inhabit. This knowledge also tends to be tribal, passed on by word of mouth and custom rather than by good documentation. As soon as you can’t rely on this institutional knowledge you are basically screwed and your productivity is going to be very bad until you learn it. This has historically tended to be a big problem facing teams adopting internal technology and is an even bigger issue if you are licensing someone elses technology.┬áThe reason Unity currently has far more users than other engine companies who have also had free offerings for some time is simply that their mission has been to empower developers so their product is just easier and better to work with.

I’d also be very skeptical about getting seduced by revenue sharing schemes. 5% gross revenue is an awful lot of money to ask and could well push a developer into making a loss rather than a profit on their game. For example you make a game in one year and sell $100,000 worth of copies. $30,000 of that will go to distribution (e.g. Steam), $5,000 goes straight to Epic (plus the $240 you spent per month) leaving only $65,000 to account for marketing, the creation of the game (you’re going to pay yourself right?) and any profit you want to actually make. For Unity the upfront costs are higher but that 5% cut is gone so rather than costing you $5,240 you are only spending $900. When your margins are slim that’s important.

A Wishlist

So what would I like to see from an ideal commercial game engine?

  • A company that puts empowering developers as their first priority. Without this the project is doomed. The entire mission for any new feature should be to make the UX as good as possible within the other constraints. The tools and code should be extensively documented and that documentation should be easy to search and use. Video tutorials and regular education opportunities would be excellent. Further support for the community is a must as very often people will solve each others problems.
  • A clean architecture for making games. This essentially means that the process of creating a new game entity should not be unnecessarily convoluted nor should the resulting entity be polluted with lots of unnecessary stuff. I’m very much biased towards engines that make use of an entity-component system these days. The architecture should make inter-entity communication simple and event driven. There should be templates for scenes and entities which provide good support for procedural generation. All the engine code should be well tested, by which I mean it’s covered by unit and integration tests further it should be easy to write and run these tests on game code.
  • The engine should be fast. Game developers still want to push hardware particularly on fixed platforms like consoles. This means at the very least the engine needs to be multi-threaded probably with a generic jobs system to make use of the cores that are available on various platforms.
  • The engine should be portable. If it can’t build to consoles, web, mobile platforms, Linux and desktop OS’s then that’s a bit of a deal breaker. Not because you necessarily want to deploy to all those platforms but because having the option means you can should your companies plans change. This is important from the perspective of productivity as porting a project can be an awful lot of work especially if you need to learn a new engine to do so!
  • Iteration times should be blazing fast. Data should be editable on the fly and it should be ludicrously easy to experiment with ideas. It’s even better if code can be live reloaded, usually from script to avoid the pitfalls of compilation where certain cases will force you to tear down everything.
  • It should be easily extensible. An editor you cannot customise is pretty useless. Doubly so if you want to fit it into any sort of Continuous Integration/Deployment or want to implement a more complex build process.
  • Integrated. At a minimum the editor should support various forms of source control. Support for other popular developer tools out of the box would be gravy.
  • Source access. Big, ambitious projects will almost always need to modify the engine internals.
  • Feature rich. This comes last. Shiny features are no good without the above. Unity has amply demonstrated you can have a feature rich editor simply by empowering developers.

Now that these opening salvos in a battle over license cost have been fired we’ll hopefully see a wider war waged on empowering developers with tools that really enhance their productivity.

About a year ago I floated the idea of running an internal game jam and got a lot of interest from not just the developers but from our business and support staff. Actually implementing that idea got waylaid by being too busy with development (we were on a very tight deadline revamping the hacking in EVE) and by my not really being senior enough to co-opt things like people and budget to help out. The idea was revived by my immediate manager Bjossi and along with a crack team of others interested in helping out we assembled what I think was the first Game Jam organized within CCP.

Eating pizza at the end of day one.

Eating pizza at the end of day one.

My part in things was to work with a few other people to come up with a format and generally sort out how we would run things. In the end I actually facilitated the whole thing as Bjossi was unexpectedly unavailable. I think our format was pretty good and the results really speak for themselves. I’ve reproduced the important details below so that others can use it as a template:

Organizing a Jam

Game Jam Rules

  • All game code and content must be made on the 14th and 15th of February.
  • All games must be based on the theme of the jam. The theme will be announced at the beginning of the jam.
  • There is no restriction on third party libraries or tools although you must only use software with a valid license (e.g. trial license).
  • There is no restriction on preparation for the event so long as no content or game code is written prior to the theme being announced.
  • Games may be digital or paper based.
  • All digital games must run on Windows.
  • We’re going to share source code internally as it can be a great learning tool.
  • All IP created is the property of CCP Games.

Forming Teams

Teams will be formed immediately after the jam theme has been announced. We’ll have a mic ready so people can make small pitches if they have an idea and want to get people on board. We’re going to try as far as possible to leave this as a self-organizing effort but please bear these things in mind:

  • Teams shouldn’t really be larger that 6 members.
  • Try to recruit of join up with people you don’t normally work with.
  • Attempt to spread people that work on games directly during the day out between teams.
  • If you have special requirements about when you can or can’t work just let your teams know. I hope most people will be glad of the extra pair of hands even for a short while.

CCP very kindly gave us permission to run the Game Jam using one day from the working week and the use of the office facilities over the weekend. We also got budget to feed the troops pizza and beer after day one, for some beers to available during a showcase afterwards and for some free drinks at a local bar as an after-party for the participants. We also block booked out some of the meetings rooms in the office for the exclusive use of the teams and allowed people to work offsite, although only one team actually did. For communication before and during the Jam we had a couple of mailing lists setup and a chat-room open for all the participants.

At the beginning of the work day on the Friday we announced the theme ‘One Heart to Break’ and after a bit of a false start everyone quickly formed up into teams and disappeared. I spent most of the day trying to make sure everyone had what they needed. There was a hard submission deadline of five PM on the Saturday evening which all the teams made, although some only just! After they submitted everyone rushed to get setup to demo their creation in a showcase open to the rest of the people from the office. Beer was consumed, fun was had and then each team gave a little presentation about their game before I announced the prize winners. After we’d packed up we all adjourned to the pub where the event was dissected in detail.

One of the teams looking a bit stressed out.

One of the teams looking a bit stressed out.

Lessons Learned

Game Jam’s are awesome, most people that have taken part in one will have enjoyed it. Ours was no exception and the event generated a tremendous amount of good will from the participants. At the beginning I was a little worried that teams wouldn’t end up making very much but every single team made at least one game. People did mix up who they worked with a little but most of the big organization boundaries weren’t crossed. I think that’s about all you can expect running this sort of event for the first time.

I would like to make more of a thing out of the showcase when we do this again. The organization was a bit last minute and we could have done more to make the event something people wanted to attend as well as easier for the teams to setup and be distinct from one another.

For those interested in technology choices by far the most prevalent choice was a variety of web platforms with most code written in JavaScript. The only big game engine used was Unity by one team. We had one team make a card game and another using a physical game board to control a videogame. By far the most unusual choice was the piece of interactive fiction a team created in Confluence our project wiki software!

Over the next few days I’ll post about each of the prize winners before summing up the remaining entries.

A talk I gave at Unite Nordic in 2013.

Basically an exposition of my thoughts on prototyping, how to do it right and what value it provides to game developers.