GIC 2016, Poznań - day one
Wow, it's been a while since I attended a gamedev event! This time my resolution is to prevent my notes from vanishing somewhere in Dropbox and actually publish a few impressions.
Here's a bunch of talks I'd like to highlight:
The power of attitude. A story of Techland's success
The opening presentation was given by Paweł Marchewka, CEO and founder of the renowned Polish game publisher and developer. If Techland doesn't ring a bell, they're the guys behind Dying Light, Dead Island, Call of Juarez and Chrome (this one).
Paweł opened with a feels trip in time, back to when the nerds (who since then had time to become parents of nerds) would regularly meet up in shady marketplaces, trading hardware and pirating software. I've been there once as a kid and I still remember how it went down:
- "I'd like Doom, please"
- "Certainly, that would be 3 floppy disks"
- (commence copying)
One might ask: okay, what the hell's going on, great games get pirated in Poland because the western prices seemed ridiculous around here (hint: Soviet Union times), shouldn't it be the other way round? Shouldn't it be us who make great games and ship them overseas, where people can happily pay in dollars for each copy? So Paweł started a recruitment campaign that included a megaphone on the said marketplace, got some programmers onboard and started making games with the intention to conquer the western market.
Paweł went into great detail to describe their mindset - "success is the only option" - and told how it helped Techland get through some hardships. What hardships? For example, there's Eksterminacja, their first game - it took five years instead of two ("almost finished" syndrome), and when it finally got shipped, the market was already hot about Starcraft and Total Annihilation and Command & Conquer... Not the best weather for another RTS to stand out.
Then there was the Crime Cities story. Wow, I loved Crime Cities, I played the hell out of it and if anybody made a remake, I'd probably just take 3 weeks off and stock up on energy drinks. The game didn't have it easy either: the genre itself (zero-g shooter) wasn't very popular; people might have had enough of Descent and Forsaken. (Personally I'd argue here, Crime Cities had an open world plus some RPG elements, it seems wrong to bundle it with these titles.) Then there was a graphical revolution happening during Crime Cities development and Techland had to rewrite the game engine like 2 or 3 times just to keep up...
Some other takeaways:
Steam releases a few thousand games a year - why would people buy YOUR game?
That's a great legit question to think about. You should always be able to rationalise the game's value to yourself - it's essential to stay motivated.
Also, is your game fun? Why? Have you checked? If not, why not? There's a common pitfall that Paweł advised against:
"But we're not ready to show this game to people and get feedback!"
Oh it doesn't matter if you're ready or not. Feedback is what prevents you from wasting time on wrong things.
5 Ways to Kill an Indie
Kadri Ugand from GameFounders came to GIC to acquaint the audience with the idea of getting an investor to fund your studio. After opening the talk with a small dance, she put a lot of effort into explaining the differences between a publisher and an investor. Essentially, publishers are interested in the success of your game, while investors benefit from your studio itself being successful. Publishers want revenue from games, while investors want the studio's equity to grow. This also affects the kind of help you can get from either.
All the innovations are coming from indies...
Wow, someone said it! Turns out it's because large studios are slow and beaurocratic, while indie studios iterate quickly and can ship whatever they think of. Indies are the first to jump on any new bandwagon like VR or Twitch integration or you name it.
A well prepared talk about the magical place where your games meet real life.
Jakub Węglarz on level design tools
So Bladebound is apparently a hot thing and Artifex Mundi came around to tell a story how they managed to solve the problem of messy and tangled game logic. The levels in Bladebound are put to life using a system of triggers that cascade and trigger each other in response to various things happening in-game. An author of each level had to manage this complex network of interactions using a workflow that I could sum up as "Unity Inspector hell". Wow, this took some courage.
Jakub considered coming up with a better way of designing game logic, but he stumbled upon the standard problem of operating on a live system: there was a ton of content already produced using the current tools. Even if Jakub managed to finish a new, feature-complete solution, he'd then need to migrate all the existing levels. Either that, or he'd leave them be, at the price of the game code having to support two competing systems for doing the same thing. That's a huge price to pay for a partial rewrite. To add insult to injury, all the level designers were still producing content using the current approach and the production work couldn't just be stopped for the transition period between old and new system.
Of course there was a way out of this tricky situation! Jakub decided to keep the current trigger-based data model, but to add a second, competing interface for editing it. He hooked into Unity's rendering callback to actually display each trigger as a game object, together with displayed interconnections to related triggers. This improved the experience of writing triggers from a nested tree editor to a visual language, not so different from, say, LabView or maybe even Blueprint. Plus, the designer could actually put the trigger icons in meaningful places using the Unity scene graph so that the relationships are easier to understand.
One thing I especially liked in Paweł's solution was populating the context menu for the triggers using C# reflection. In order to make it possible to easily connect two object, you could select both, right click one and the system would show you some suggestions about different ways that you could connect these. The different options were not hardcoded - in fact the system crawled both objects' annotated interfaces and looked for properties that had matching types. Every sufficiently metaprogramming technique is indistinguishable from magic!
Finally let me re-share the lifehack that Jakub used for managing his time (as I remember it):
Work in a weekly cycle. Spend 1 day improving your tool, then use it for the next 4 days. Rinse and repeat
I like how this simple technique prevents you from going all-out and developing useless features, and insteads places you in the shoes of the user of your tool so that you have no other option than to collect feedback which parts of the tool really need an improvement and which are okay as they are.
Two more days to go! Continue to day 2