Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
November 13, 2019
arrowPress Releases







If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 

From Air to Unity: The monstrous cloud editor under our bed

by Ondrej Trhon on 09/10/19 10:39:00 am   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

This is a guest devblog co-written with our programmer Ondrej Paška. We will be doing these from time to time.

Game development is a race against time. Not only because of looming deadlines, but also because technology rapidly evolves. Established tech from ten years ago, might be hopelessly obsolete today.

We learned it the hard way. When I started working on Attentat 1942 as a programmer at the end of 2011, we put some of our bets on technologies, that we should’ve seen were slowly fading away. With our next game Svoboda 1945 those decisions came back to haunt us, just like historical traumas from post-war period are still felt by our characters.

Let me show you the journey of our small Czech team into the depths of Flash development, showing our attempts to build our own git, creating our own cloud editor, but eventually ending up loving Unity.

When Apple ditches your technology, it’s not good

As historical accuracy was the key goal, we wanted to let actually professional historians create all the content.

The problem was that we weren’t experienced designers. The initial idea was to create an editor in which our historians could put the game together themselves. They would assemble dialogues, storylines and interactive scenes.

We wanted our own tool to be accessible so we - yes, yes, we know - decided that it should run in the browser. And the best way how to make interactive stuff on the web at that time was, you guessed it, Flash.

What seems like a horrible decision made sense back then. For GUI elements there was Adobe Flex, which enabled XML layouts with code hooks - similar to what Android does now.

So we started making our own online editor, with user management and basic tools for creating interactive fiction. Behold:

We named it MIVE. And to be honest, I also feel proud. We made this beast from scratch and we came up with some ideas that we would be happy to have today. For example you could send a link to a scene to someone and they could immediately play it inside their browser, without installing anything. Upon release, we exported a package directly from the server, coupled it with a standalone Adobe AIR engine and sent out PC and Mac versions.

Our initial plan that the script writers and historians would work on the game soon started to fall apart. We weren’t able to make the editor accessible enough. We had to hire people we called scripters to work as intermediaries between writers and programmers.

But this moved programmers further away from game designers, creating new kinds of funny incidents. Attentat 1942 started as a text only game. So when the request to add a video playback function came, we thought that it would only be intro or some minor part of the game. We coded it and forgot about it. Later, scripters came and told us about a weird bug - the game was freezing and crashing. We took a look at the data and found 30 videos playing simultaneously in one scene. That turned out to be deliberate.

In the end, Attentat 1942 became a full FMV game. But we had to grapple with it along the way.

Too many things, too much bugs

In the end, the main problem was that we tried to do a bit of everything. MIVE had user permission system, online directories like Google Drive, version control as Git, access management, automatic video conversions, interactive scene editing and much more. You could pick it up and create a lot of different games. But for our particular game, it made things much harder.

And honestly, it was also a buggy mess. Complicated scenes took minutes to load. Our scripting system was getting really convoluted and inexperienced junior scripters got lost among entangled variables and dependencies.

Things got much worse when Flash fell out of grace. Browsers rolled out security improvements which broke our editor regularly. Standalone version of Adobe AIR had 1 GB memory limit which we often exceeded and the garbage collector often dropped our frames.

Every little bugfix took its toll. We finished Attentat 1942 through gritted teeth and released it. We got nominated for the IGF, won several awards and the reception was generally really good. It’s good no one was able to see all the hacks and mess, which kept our serious story of nazi occupation together.

In the end, no one is judging the quality of your code.

New times require new tools

Fast-forward to 2019. We are currently developing our new game Svoboda 1945. Although we did some early prototypes in MIVE, we very soon decided to move away from Flash altogether. It wasn't an easy decision, but we really hated the long waits and also wanted to target more platforms.

In recent years, Unity implemented better 2D game features. We decided to switch and port our entire game onto a new platform. How did that work?

Even with fewer resources than we had for Attentat 1942, as a single programmer, I was able to create Unity tools with game designers in mind. Simple draggable scripts, polished dialogue system, scriptable objects for variables - Unity enabled me to easily create a kind of scripting LEGO. Our scripters can now quickly create not only prototypes, but whole game scenes. Versioning is left to git and we started doing video conversions by hand in ffmpeg.

Using standard Unity stuff and putting a layer of useful gadgets on top greatly sped up our development. Ease of use and error-proofness were the main goals. Bugs are now easier to find and we can spend more time thinking about game design and less time waiting for scenes to load.

So: What we learned?

  • Before the “final” game design, create cheap prototypes. Don’t make your code too general. When you are satisfied with your prototype, start from scratch.
  • Listen to feedback and make tools easy to use
  • Don’t make general tools, make tools specifically for your game!
  • Be aware that your favorite technology might be forgotten in 5 years
  • Don’t expect non-programmers to start coding without proper guidance

Had we knew all that in 2011, we would have saved a lot of time, energy, avoided much of development stress. And we wouldn’t have to debug a single character’s scene for roughly a year. Ludmila is a central figure of Attentat 1942 story. But for us programmers, she is also a long and confusing list of variables running in Flash.

Unity allowed us to create characters of Svoboda 1945 much easily. Instead of hunting for the one wrong variable, we could focus on making our characters as truthfully as possible, capturing every bit of historical nuance. Because that’s the real upside of having better development - you don’t have to fight your tools and instead create a better game.

Wishlist Svoboda 1945 on Steam or subscribe to our newsletter

 


Related Jobs

Supergiant Games
Supergiant Games — San Francisco, California, United States
[11.12.19]

Engine Programmer at Supergiant Games
Sucker Punch Productions
Sucker Punch Productions — Bellevue, Washington, United States
[11.12.19]

Camera Designer
Sucker Punch Productions
Sucker Punch Productions — Bellevue, Washington, United States
[11.12.19]

Encounter Designer
Big Red Button Entertainment
Big Red Button Entertainment — El Segundo, California, United States
[11.12.19]

Unity UI/UX Programmer





Loading Comments

loader image