An idea for writing web games in Python

Here’s an idea that popped into my head last night: What if you had a framework that allows you to write a game in Python as if it were a local game, only it runs in your browser?

To make it simpler, let us assume this game is turn-based and features few if any graphics.

That might seem a big restriction, but think about Candybox and A Dark Room and Fallen London and Kingdom of Loathing. Fun games can be built within these constraints.

A framework like this would be ideal for prototyping turn-based online games (and guess what kind of game I am working on right now?). It might also be ideal as a way for people to get into game programming.

The framework

For the simplest version let us further restrict ourselves to single-player games with no time-based aspects at all. So time advances because the player performs an action. This allows us to avoid doing real-time, in the web technology sense of the world, which is a bit tricky. The server can always just wait for the player and never needs to push anything to the browser. This is a big restriction but it makes for a good base that can be built on later.

So then all we would need is to design an API that resembles how you would write a game “as if it were a local game” and translate that into web technology. The two big things that API would need to handle are graphical user interfaces (GUIs) and game data.

GUIs

For GUIs, one part is a simple system to handle screens, UI elements (buttons etc.), and layouting. The system generates HTML behind the screens and sends that to the browser, a bit like a GUI API generates graphics and sends that to the user’s screen. More complex UI elements (e.g. tooltips) will require some Javascript but I’d say that’s more work but not a major impediment.

The other part is mapping URL-based event handling to the button-based event handling you’d expect from an offline game API. You register or otherwise create a button, passing the function that should be called when this button is clicked (much easier than event binding IMO). The system generates a URL for this button, or however it wants to handle it, and takes care of the rest.

The classical game loop then becomes a very simple function the user writes which gets called when the next turn starts. Of course the next turn starts because the user told the system this has to happen. The player sees an ‘End of Turn’ button, clicks on it, the button handler calls a ‘next turn’ function, which then causes the ‘game loop’ to be called. Perhaps that appears cumbersome but it sets things up nicely for the next step which is to allow the server to push to the client.

To do that, you need some additional technology, namely realtime or push. (“Realtime” is confusing in this context because we’re still talking about turn-based games, but it makes sense in a web context.)

Armin Ronacher, the creator of Flask, my Python web framework of choice, writes about that here. I’ve not done a lot of stuff with realtime web technology and I’ve certainly not thought through how to use it in the context of this game system, but right now my gut tells me it’s doable somehow.

Data

Handling data is interesting because of the amusing fact that on the web, the computer forgets everything after you talk to it. There are really good reasons for this, but it can be a bit challenging if you move to web development from other programming areas.

Anyway, I’d try to make it so that data automatically gets saved after each web request. A little layer on top of a typical ORM should do the trick: Basically, commit a transaction at the end of each request. Perhaps I am being naive.

Player and game session management could be built into the system.

Summary

What would be the advantages of such a system? People can use Python to write games. Python is my favorite programming language, so it’s a big plus for me. But Python is also pretty easy to learn, which is a plus.

It’s not so hard to imagine a system allowing people to instantly distribute these games on the internet.

The API would be simple – simpler than Unity3D because the games are more restricted, which is a good thing in my opinion. Also simpler than doing this with, ahahaha, ‘bare metal’ web technology. (I started this blog post with a rant about using Ruby on Rails to learn programming, but it grew too big.)

To sum up: this hypothetical system would make game programming easy to learn and to distribute, for a restricted but interesting set of possible games.

So what do you think? Stupid? Interesting? Boring? Already done? Way harder than I imagine?

Update: I should add that any HTML-based game has to kinda do what I am describing here, and conceivably although not necessarily, they’ve built systems that resemble non-web-game APIs. But I don’t know of any such framework that is available for others to make games with.

Where to eat or drink in Vienna

Putting this here for future reference. Part of a series – see this.

Without further ado:

Zum Weissen Rauchfangkehrer
Pricy, Austrian, very good food
Weihburggasse 4, 1010

Pure Living Bakery
Great US-style coffee place
Burggasse 68, 1070

Die Burgermacher
Best burgers in Vienna
Burggasse 12 1070

Glacis Beisl
Breite Gasse 4, 1070
Good Austrian food, reasonable prices

Benkei
Very good sushi
Ungargasse 6, 1030

Suessi
Cute French tea salon
Operngasse 30, 1040

Cha No Ma
Japanese tea
Faulmangasse 7, 1040

Sebastiano
One of the best Italian restaurants in Vienna, reasonable prices
Mayerhofgasse 22, 1040

Indien Village
One of the best Indian restaurants in Vienna, reasonable prices
Hohenstaufengasse 7, 1010

Taste of India
Good Indian food
Margaretenstrasse 34, 1040

Daniel Moser
A Viennese cafe with decent coffee (rare)
Rotenturmstrasse 14, 1010

Griensteidl
A traditional Viennese cafe with nice food
Michaelerplatz 2, 1010

Kaffeefabrik
Tiny hole in the wall place with maybe the best coffee in Vienna
Favoritenstrasse 4, 1040

Dino’s American Bar
Best cocktail bar in Vienna
Salzgries 19, 1010

Barfly’s
Very good cocktail bar
Esterhazygasse 33 (in the Fuerst Metternich Hotel)

Unity3D for teams of 6 people or more

I’ve done this rant live to various people, but I thought it was time to write it down.

First of all: I like Unity3D. I sincerely think Unity3D existing makes the games industry a better place.

But, basically, I don’t see how it can be used for efficient, professional game development, with teams of 6 people or more all actually using Unity. I’m sure people are doing this, but I’d like to know how.

This rant is based on my experiences on a project that used Unity 3.5. Maybe Unity 4 is better. It was our first Unity3D project, but to be honest we spoke to a lot of other Unity developers and if there were any major rookie mistakes we made I don’t know what they are.

Final caveat: It’s been a while since I’ve gotten my hands dirty on this, plus I wasn’t the one who set up the project, so I might get some details wrong.

We used Unity3D with Perforce, with a team of 6 to 8 people, most of whom had to work within Unity itself, as opposed to just making bitmaps or something. The daily workflow for pretty much everyone on the team was:

  • Check out everything in the Unity folder in Perforce. Not ‘get latest’. Check out.
  • Open Unity3D.
  • Do your work and test it.
  • Save, then quit Unity3D. You must do this.
  • Go into Perforce, reverse unchanged files, then try and guess if any files, particularly all of those tiny .meta files, have been added or removed and tell Perforce about those.
  • Repeat.

Unless you want to change a scene, then you must yell through the office that you’re going to change a scene, lock the scene file, then do all of the above. So this was pretty much like not having a repository. We had things set up so scenes and other data are text files, but to be honest, just because it’s now YAML doesn’t mean you can just merge scenes – all those internal references don’t necessarily match up.

That’s a pretty sucky workflow, and it took us a while to get it through everyone’s heads that they really, really had to do all this. I personally suspect – I never investigated this – that we had to quit Unity because of one plugin that saves important files on exit. But to be honest if that’s the case I still see that as a design flaw in Unity.

So, internet: what did we do wrong? What are your experiences with Unity3D and teams of more than a couple of people? We did not use the Team License – could that have solved our problems, and if so how?

The three most common techniques for telling stories in games

Mainstream games, or at least a significant subset that I’m too lazy to define here, make use of three big techniques to tell stories:

  • Cut-scenes.
  • Invisible boxes.
  • Environmental storytelling.

I think both game developers and players understand these techniques by now, and in fact I think players are getting tired of them. I know I am. And that means it is time to surprise people again, to innovate, by moving beyond these tools or by using them in new ways.

Cut-scenes

Cut-scenes are the most conventional and, perhaps not incidentally, also the most controversial tool. We’re splicing another medium, film, into our games. It is an effective medium to convey information and evoke emotion. Players and developers both understand cut-scenes, important reasons for their popularity. The effectiveness of cut-scenes balances out the fact that they are not interactive, and therefore tend to break immersion and take away agency. But it’s an uneasy balance. Cut-scenes, by definition, do not fit well in an interactive medium.

Over the last 20 years, innovation in cut-scenes has been about technology (how complex a scene can we show), production (how do we economically make more complex cut-scenes) and filmmaking craft (how do we make effective cut-scenes). There has been almost no innovation in the interactive aspects of cut-scenes, and this is to be expected since cut-scenes are pretty much defined by not being interactive.

(I classify dialogues as cut-scenes for the purpose of this article. How to do dialogue better or make it more interactive is beyond the scope of this blog post. People tried cool stuff in the 80s and early 90s, we did some reasonable things in the role-playing games I worked on, by now people have kinda stopped trying to invent new things, at least in AAA. I haven’t played enough Mass Effect or Skyrim to have an opinion on how they did, but I didn’t get the impression it was groundbreaking.)

Invisible boxes

Invisible boxes (or planes, spheres, volumes, etc.) are the tool that level designers use to trigger events. When you walk around a corner and a ceiling collapses, enemies come running towards you, or some characters act out a little scene (just out of your reach), then you just hit an invisible box. When you’ve seen them once, you see them everywhere.

And that is the problem. As a player, you develop a sense for these things. You know stepping into that big room or walking around the corner will trigger something, just as you know that if you just stay there, nothing is likely to happen, forever, except for the eerie and foreboding music. (The tendency for games to get stuck, when nothing happens because the player isn’t doing something, is a big immersion breaker.)

Invisible boxes are used to orchestrate events just so for the player’s enjoyment, to make sure she meets the right challenge at the right time, sees the right thing at the right moment. They are an easy tool to understand and to use, although hiding them requires finesse.

But they can never be fully hidden. At some point, the player realizes that the world arranges itself around her, and then the reality of being on a well-orchestrated ride dominates the illusion of being inside the fictional world of the game, and her behavior changes. She knows what to expect.

Invisible boxes are stupidly easy to implement, so there has been no innovation here for decades. We’ve become more sophisticated in how we use them, but the scripts in the games I wrote in the early 90s are conceptually the same as the scripts in current games.

Note also that invisible boxes are orthogonal to interactivity. We can use them to orchestrate spectacles, but they are not inherently interactive, they do not in themselves create or enable interesting choices for the player. In fact, they are often used to trigger or to artfully replace cut-scenes. Characters talk or interact in real time, scientists are drawn into ventilation shafts, but in such a way that the player doesn’t notice that she cannot interact with them.

Environmental storytelling

Environmental storytelling is telling a story through a game’s environment, specifically a story about what happened before you arrived in said environment. I believe the term was coined by Henry Jenkins, but I’m not an academic so I’m not going to research it. I first saw it used in System Shock. Remember finding those little cubby holes with a corpse and some empty food containers and recordings telling increasingly bleak tales of the bad stuff that happened before you arrived? Well, that was kind of the best use of that technique, and it’s been used more or less like that ever since. It was used well in Portal and Manhunt. It’s a useful technique, but limited. I recently saw a blog post critiquing the diaries and recordings in Bioshock 1 or 2. I surprisingly felt a bit disappointed at the start of Dishonored when early on, in the sewers, I found a little cubby hole with a corpse and some empty food containers and letters. I remember thinking “Oh no, it’s the 90s again.” For all I know it was a homage. Dishonored is great, you should play it.

So?

These three techniques have a number of things in common. They’ve been used a lot over the last 20 to 30 years, especially in ‘mainstream’ AAA games. Players understand how they work, they’ve learned the conventions. Developers understand how to use them, and have refined them over the years.

And there are signs that people are getting tired of them. I’ve got a whole different blog post on a back burner somewhere about techniques and gimmicks and genres. I don’t have an opinion why this is happening, whether people just get tired of any technique. Maybe they do. Maybe you can see this when you look at the evolution of TV and cinema and comics, how things are rebooted and reinterpreted. But I claim it’s happening.

Finally, none of these techniques are very interactive. Only invisible boxes can claim to be somewhat interactive, in the sense that they react to the player.

(Just a few days ago I read this profile of Mohammad Alavi in Edge:

Once more, Alavi charged into the wilderness alone, eventually writing over 10,000 lines of scripts that anticipated every way the player might disturb or be noticed by the patrolling soldiers, handling each case with different animations and behaviours. “It was crazy and jury-rigged together, but the end result is that you can enter the situation from any angle and it’s legit – if they thought they saw you from a certain distance, they’d behave differently than if you popped up right in front of their face.”

So maybe you can do some cool stuff with invisible boxes if you’re crazy. But they rewrote his scripts and turned it into proper AI.)

And I believe this shows that all of the current techniques we currently have are smoke and mirrors. Well-executed, cunningly used smoke and mirrors, perhaps. But we’ve taken things that we as developers understand and that our players understand, and have tacked them onto games. We’ve taught our players how to overlook the joins and seams, that we all know are there. And we’ve taken this as far as we can. Now the end is in sight. We’re close to not being able to do better, to not being able to afford to do more, and players have caught on to us.

We’re on a local maximum, a beautiful hilltop where things are great, but any movement leads downward. And that’s scary, because that means we have to leave behind what we built, pack a small backpack and trek through the wilderness to find new beauty. And we only have a vague idea of where to go. Some of us won’t make it.

I’ve been thinking about storytelling in games for a long time, since before I became a professional developer even. For years I chased immersion and used the techniques I described above. But I knew there had to be more. Now I am seeing hope, in games like FTL, in Spelunky, in Rebuild, in Dwarf Fortress, perhaps in Minecraft. It’s not the discovery of something blindingly new, but more suddenly looking at things in a different way. (And then seeing a trail leading from these games back in time to older games. It was there all along.) I don’t know where this trail will lead. I’m sure it will be different from where we were before. I can’t wait to find out.

Why we called our game Albion

Some time in 1994 we (the Albion team) were thinking of a name for our new role-playing game. We knew it would involve Celtic culture somehow. As well as spaceships and aliens, of course.

Some of my personal criteria for game titles were:

  • It’s nice when a game’s title starts with an “a”, because then the game shows up at the top of alphabetized lists.
  • It’s nice when the game’s title is not truncated by the operating system. Albion was a DOS game, so it’s nice to have a name of eight characters or less.

However. Albion started off as an Amiga game, and Amiga’s operating system allowed longer filenames than DOS. So either we came up with the name after we made the decision to switch to DOS (because Commodore had gone bankrupt), or we were just lucky in this regard.

So someone, maybe me, came up with “Albion”. We didn’t know what it meant, but we knew it sounded vaguely Celtic. As this was before we could have looked this up on Wikipedia or Google, we had no idea Albion meant England… In retrospect it’s a weird name that creates associations that have nothing to do with the game. This is probably how Japanese developers pick names all the time.

Anyway, that’s how we came up with the name.

A rant about games and how they’re perceived

Last night I had a discussion on Twitter with Luke Dicken about game definitions, and why they matter. It reminded me of some strongly-held views I’ve had for some time about attempts to place games in a larger context: art, society, culture, et cetera.

I don’t care if games are a legitimate art form, medium or whatever. I don’t care if they have a pedigree going back to 1971, the 50s or the 18th century. I don’t care if they’re older than the novel, older than writing. I am not convinced, nor do I particularly care, that computer games are direct descendants from board games, children’s games or play in general. I don’t care if animals used play to learn before humans learned storytelling to transmit knowledge. I don’t care if play is an essential part of human culture.

If someone were to convincingly prove that computer games are not a legitimate art form, I’d still be making games. If someone could convince me computer games were a trivial hobby, I’d still be making games. If computer games were not derived from something else, if they had been invented ex nihilio, out of whole cloth, sprung fully formed from the brow of Nolan Bushnell or whoever, I don’t care, they’d be even more miraculous.

What unites most people making computer games is their passion. We want to make games. We know how to make games. We strive to make better games. But it makes absolutely no difference to me where we fit into other people’s questionable value systems. Fuck ’em if they don’t get it; they will die out anyway.

If we have to play power games to protect our medium, if we have to argue that games have cultural value in order to gain legal protection or subsidies: why not, it needs to be done. But let’s not mix that discussion with actually making games, with making people happy, with evoking emotions and giving people means to express themselves which are fundamentally new.

We’re working in the newest and most exciting medium in the world. That doesn’t make it a ‘better’ medium – I don’t even know what that means. It doesn’t make our lives easy. It doesn’t mean we bear less responsibility, that we don’t need to work hard to do better every day.

But it is a good thing, no matter what anyone else thinks.

Pushing ideas to different parts of your brain

A couple of months ago The New Yorker published a profile of Hilary Mantel by Larissa MacFarquhar. I found this paragraph particularly interesting:

When she’s starting a new book, she needs to feel her way inside the characters, to know what it’s like to be them. There is a trick she uses sometimes, which another writer taught her. Sit quietly and withdraw your attention from the room you’re in until you’re focussed inside your mind. Imagine a chair and invite your character to come and sit in it; once he is comfortable, you may ask him questions. She tried this for the first time when she was writing “The Giant, O’Brien”: the giant came in, but, before sitting down in the chair, he bent down and tested it, to see if it would take his weight. On that occasion, she never got any further, because she was so excited that she punched the air and shouted “Yes!” But from then on she could imagine herself in the giant’s body.

This reminds me of the Rubber Duck debugging technique:

The name is a reference to a likely apocryphal story in which an unnamed expert programmer would keep a rubber duck by his desk at all times, and debug his code by forcing himself to explain it, line-by-line, to the duck.

Peter Reiterer, a programmer I work with, occasionally uses this technique. (I myself have used a similar technique but using a graphic artist instead of a rubber duck. I have not compared the two approaches but my method is also quite effective, if perhaps more boring and confusing for the participant.)

The way he explained it to me, or rather the way I remember his explanation, is that this technique forces you to express thoughts and then absorb them again through a different part of your brain, and this allows you to see them in a new way.

I always thought the mere act of expressing your thoughts to someone (or something, I guess) forces you to reorganize them and in the process discover new insights. A bit like learning by teaching, and incidentally the reason why I do public speaking or write blog posts. The difference is subtle and I can’t think of a way to test which explanation is better.

But the interesting thing, to me, is seeing two techniques to unblock yourself, to get a new perspective on things, that involve forcing a different part of your brain to interpret something. Of course it’s just me saying that is what’s happening in Hillary Mantel’s head, and I am not a neuroscientist. I don’t know for sure if she is using two different parts of her brain: this is just my intuition.

After discussing this with my wife it struck me that prototyping is similar to these techniques. It is easy to imagine a logical, abstract structure for a user interface, but once you visualize using it in your head, or, even better, prototype it on paper, you see it in a different way and can perceive things you couldn’t in your abstract model.

Of course, this raises the question: does prototyping work because you’re perceiving something using a different part of your brain? Or ‘merely’ because you’re seeing an approximation of the real thing? It is unlikely that I can better understand a game design idea by using, say, interpretative dance.

Food for thought, perhaps. Can this approach be generalized? Can we express, transform, and re-experience our ideas in other ways?

Game definitions and the designer’s toolbox

When you hear someone say “that’s not a game,” they usually mean “this is not what I was expecting from a game”.

Game definitions are like tools. You need to get something done, so you open your toolbox, pick the right tool, and then use it. As a craftsman, you care about your tools, you polish and clean them, you try to make better use of the ones you have, and judiciously add new ones to your toolbox, all in service of the craft.

A game definition based on Huizinga’s magic circle allows me to do different things than a game definition based on Crawford’s toy/puzzle/game taxonomy or Costikyan’s resource-based definition. All of them are useful, they all make sense and are ‘true’. But each operates in completely different perspectives.

And this is the value of a varied and well-selected set of tools. They allow you to look at things from different angles. When you have a screwdriver, you look for screws, for things to open.

Similarly, when you’re using the magic circle perspective, you might be thinking of how playing relates to non-playing, how people can be drawn into a magic circle, how their behavior can be changed, or how you can draw attention to their behavior by manipulating the magic circle.

When you’re using the toy/puzzle/game perspective, you might be thinking of player goals and replayability. Do you give explicit goals to the player, or do you let them select their own goals? Is the game about figuring out a problem and then moving to the next one, or is it about dealing with an opponent or a complex system?

Costikyan’s definition of game draws your attention to resources and allows you to design independent of whether you’re working with cardboard and tokens or on a computer. It makes economics applicable to games.

A final perspective – I hesitate to call it a definition – is that of ‘it’s a computer game because it looks like a computer game’. Here we get games like Proteus or Dear Esther. They are sold and discussed alongside other games. They contain 3D worlds we can navigate through. They don’t have a ‘serious’ purpose – they’re not email clients. Note how none of the previous definitions of games said anything about navigation in 3D worlds, or any kind of navigation or worlds at all. Yet the representation of and navigation in worlds is an unspoken assumption underneath a lot of people’s idea of what a game is.

The toy/puzzle/game taxonomy is the clearest about games like Proteus and Dear Esther. In this system, seen from this perspective, these games are toys. This helps me understand them. It makes them tractable, understandable, ‘known’, even before I play them. This doesn’t mean they’re boring or predictable: just that I can recognize them from a certain perspective.

Game definitions are tools, and knowing your tools well, understanding their differences and their strengths and weaknesses makes you a better designer. In the case of mental tools, knowing exactly which tool you’re using is perhaps one of the most useful things to learn.

Game definitions can also be used in a rhetorical way, as a form of argument. This is always about power, and thus political. I define games this way, therefore your game is not a game and thus you lose power. I define games this other way, therefore games become more worthy than your medium and thus you lose power. I define games like so, therefore it should not be a part of your department and I get to raise my own funds.

There is nothing inherently wrong with rhetorics, politics and the use of power. But it’s important to distinguish between politics and the truth inside your toolbox.

Andy and Jurie are looking for jobs

TL;DR: Game designer Andy Schmoll (profile) and grizzled veteran developer Jurie Horneman (profile) are looking to move to an English-speaking country in the near future. Hire us while we’re hot!

Continue Reading »

The Stagconf budget

I thought it might be educational, both for you, dear reader, and for myself, to write a blog post about the budget for Stagconf, the conference on storytelling and games I co-organized last year.

Here is our final budget:

Income Expenses
Ticket sales € 6380.25 Location € 3726.00
Sponsoring € 4450.00 Speaker hotel € 1545.00
Other € 300.00 Speaker flights € 3666.60
Catering € 1739.85
Speaker dinner € 750.00
Recording € 1150.00
Taxis € 275.00
Other € 564.21
Total € 11,130.25 Total € 13,416.66
Budget for the 2011 Stagconf conference

So what can we tell from this?

Final score

We made a loss of € 2286.41. This wasn’t a catastrophe. We didn’t expect to make a profit. On the other hand, the conference was not part of some larger enterprise where the loss becomes an investment. It wasn’t a marketing activity, for instance. And while we didn’t end up living under bridges, we can’t afford to lose this amount of money on a regular basis. This is one of the reasons why we haven’t made any concrete decisions for a Stagconf in 2012.

Speakers

Over 40% of our budget went to the speakers. We treated them very well. Not every conference pays for travel, hotel, taxis, dinner, etc. Our U.S. speakers brought their partners: we didn’t pay for their flights, but we did pay for the double room for 3 nights.

Was this necessary? Yes, I think so.

At academic conferences, speakers are typically expected to not only pay for their own travel, but even for their own entry tickets. This makes sense because speaking at a conference is important for academic careers.

I’ve never attended any open source or web conferences, but if EuroPython is typical, then there it is also expected that speakers pay for their own travel and entry. This fits the open source spirit, plus there is a sharing with peers aspect that not every conference has.

At industry conferences, such as GDC, speakers typically get in for free. The value of attending and of being a speaker are high enough that it makes sense to expect speakers to pay for their own travel costs. Plus, speaker supply is very high.

I think there was no strong case for speakers at this conference to invest more than their time, which is already valuable. This should not be underestimated. In my work on the advisory board of Game Forum Germany I have seen speakers turn down an all expenses paid trip to Germany simply because they couldn’t justify the time cost, and I myself have also turned down speaking invitations for this reason.

In the end it’s simple: we wanted to have the best speakers we could imagine, and the way to achieve that is to pay their travel costs. And it worked: everyone we contacted said yes right away.

Food

Our food wasn’t cheap, but it was worth it! Feedback on the food was unanimously positive. Paolo’s did a great job.

The location

The cost of the location made up almost 28% of the budget. I’ve been told this price was low for a conference location, and the Museum of Natural History definitely has a charm that added to the experience. Still, we’ve since come across options that might be even cheaper while still being very nice.

Ticket sales

This is a big topic that involves marketing, PR and pricing. I will save it for a future blog post.

Sponsors

We are immensely grateful to our sponsors. Without them, Stagconf would have been financially ruinous and/or less cool. (For instance, everyone loved the notebooks from Scout Books and the after party at Grande cocktail bar.)

Having said that: finding sponsors, especially financial sponsors, wasn’t easy. Not just because it’s never easy to get people to open their wallets, or because we had never handled sponsoring before, or because we were an unproven event. I think the business case for sponsoring Stagconf is a bit different from other games conferences. If you focus on graphics, you can talk to Nvidia or Autodesk. If you focus on AI (for instance), there are AI middleware providers that have marketing budgets. But who do you talk to for storytelling in games? We pretty much stumbled across Nevigo by accident in early August 2011, and were very glad we could convince them to sponsor us. But apart from that it’s difficult.

One target I had in mind was the HR departments of big developers. I tried quite hard to get in touch with Ubisoft HR, because I think it would have been a great fit: they’re looking for people all over the world, and most of their games involve storytelling. But despite all of the people I know there, I wasn’t able to reach the right people in time. And it might have been tough simply because HR departments might not have sponsoring budgets. Still, I’d want to try this again in the future.

The future

Speaking of which: what about the future? As I mentioned before, organizing Stagconf was fun but also incredibly exhausting. So if we do another one, we won’t do it the same we did it last year. What does that mean exactly? We don’t know. We have been talking to people and discussing various options (different formats, different locations, partnering with other events), but we haven’t made any concrete decisions so far.

But you can help! If you have feedback on our budget, let us know. If you have tips on organizing conferences, talk to us. If you know sponsors, definitely get in touch.

Meanwhile, I hope you found this informative.