Sign in Subscribe
meta

Setting Boundaries, Open Source, & Gamedev on Consoles

I am setting some personal and professional boundaries.

Lars Doucet

• 13 min read

This is going to be a long, complicated post that's long overdue. A table of contents:

  1. The PS4, XB1, and PSVita backends for Lime/OpenFL are hereby deprecated.
  2. I am setting some personal and professional boundaries.
  3. Some cautious words about console development.
  4. Some nuanced words about open source development.

1. The PS4, XB1, and PSVita backends for Lime/OpenFL are hereby deprecated.

Context: Over the course of several years, I helped build a set of backends to make Openfl work on home consoles. And the project was a success! I shipped Defender's Quest on three platforms! They even got good reviews and a physical release from Limited Run Games! But it also took a lot out of me and I bit off more than I can chew.

You can still apply for a free license to use the backends we built if you really really want but there's no official support.

Lime/OpenFL's Nintendo Switch backend, on the other hand is still actively maintained and pretty nice to use -- in other words: I do recommend using our Switch backend, and we're still supporting that -- but to be clear, it's the same kind of support you get from any open source community, you're relying on people's free time and volunteer labor, and there's a healthy dose of DIY and figuring stuff out yourself.

All four backends remain available under free (as in beer) license, you just need to prove you are under the platform holder's relevant NDA given that it exposes their SDK's.

I'm eternally grateful to everyone who contributed to the PS4/XB1/PSVita backends (particularly Nilsen Filc, Lucas Pope, Joshua Granick, James Gray, and Wayforward Technologies), but I just have to admit that I can't maintain them anymore. They're frozen on a specific fork of OpenFL 3, whereas modern OpenFL is now up to version 8. This means these aging console backends don't support modern features and cool API's like Starling that entire games are now built around. And maintaining the complicated build environments of three different consoles and old hardware kits is not something I can commit to any longer.

2. I am setting some personal and professional boundaries.

I love helping people with their problems, but from now on I am limiting the amount of personal support projects I take on and setting down clear guidelines so nobody gets burned. Bottom line, I still want to help, but I'm just not going to be able to give some of you the hands-on help that I've done in the past. I need to get back to focusing on my own work and putting my family, customers, and clients first.

Let me be clear:
This is entirely on me.

Nobody should feel bad for reaching out to me for help. You -- yes you! -- the person feeling bad right now, right after I just said you shouldn't -- you've done nothing wrong! I openly invited this behavior, made promises to people, and took on too much.

I don't regret trying to help people, but I do regret not knowing my limits, and leading people on. That stops today.

Some context:
When I first got into open source development I was a starry-eyed youngster with very little experience. I would get stuck frequently, completely unable to google my way out of my problems, and I naturally glommed on to anyone who sounded smart and could help me out -- particularly Joshua Granick, Jens Fischer, Alexander Kholhov, Justo Delgado Baudí, Robert Konrad, Hugh Sanderson, and too many others to name. I am deeply grateful to all of them. I have sent all of these people countless emails and messages pestering them for help, and they've done nothing but give, give, give. In return, I did my best to recommend them for jobs, hire then when I could afford it, bring attention to their repos and projects, etc. On balance, I gave far less in return than what they've given me, so I also tried to take the burden off of them by helping others whenever I could and generally be a helpful and supportive member of the community.

I have to be realistic however, there's only so much I can do. I have an ongoing self-funded independent game project, a wife and three small children, some soon-to-be-shipped extremely important and exciting secret client projects, two chronic neurological diseases, and countless github repos. I'm actually better at managing all this than I thought I'd be, but there comes a point I need to trim down to just the essentials:

  • I want to spend time with my family.
  • I want to stay healthy and sane.
  • I want to ship DQ2.
  • I want to ship my client projects.

Here's my new protocol:

  • I will do my best never to make promises I can't keep.
  • Please do not contact me on weekends. I will not respond. Weekends are for my wife and kids.
    • I am sorry for contacting you on weekends, because that is a thing I totally do and have done. I will try not to do it again.
  • The best way to reach me is via email.
    • my address is (lars dot doucet at gmail dot com)
    • You can email me any time, but I will not respond after 5:00 PM on a Friday until 9:00 AM the following Monday, at the earliest.
    • I don't always respond to every email because I get a lot of them, but I try.
    • EDIT: To be clear, if you're a Defender's Quest customer (DQ1 or DQ2), you should contact leveluplabs@gmail.com, which we check regularly, but not always every day. And if you email us on e.g. a Saturday we probably won't get to you until at least Monday.
  • You can DM me on twitter/discord/etc, but there's a very good chance I will never respond. I have a deep compulsive phobia of notification icons.
    • I am sorry for constantly sliding into your DM's and notifications with my own technical problems.
  • If you're hard stuck I feel for you, but please don't look to me to save the day. I can't, and it's not fair for me to present that illusion.
    • I am sorry for all the times I have been hard stuck and put pressure on you to save the day for me.

As you can see this cuts both ways. All the boundaries I'm putting down for myself are ones I recognize that I've encroached on in the past.

Now let me be clear again -- nobody should feel bad for asking for my help, and I in no ways want to communicate that asking for help in general is something to even feel bad about. It's a natural human thing and nobody should feel ashamed about it.

It's on me to set and communicate clear boundaries about what I'm able to do and not do, and make realistic promises I can actually keep, or else learn to just say no up front and stop leading people on.

Now let's say a few quick words about console development, and open source.

3. Some cautious words about console development

A big need for setting these boundaries is because I appointed myself the champion of console development for OpenFL. I'm proud of what we accomplished, but I learned a lot of lessons, too, and not just technical ones.

Consoles aren't a magical golden pot at the end of the rainbow

This is the most important thing to learn. You are not guaranteed to make a lot of money just because you release a console game. A lot of people are interested in consoles because:

  • They're struggling on Steam
  • Consoles seem less crowded
  • Consoles are wrapped in an aura of mystery and prestige
  • They want to fulfill the childhood dream of shipping a "real" console game

The truth is that console development is extremely difficult, and the technical challenges -- which are significantly higher than on PC -- are honestly the least of your concerns. I will avoid anything covered by NDA's, but enough of this is widely public information that I can sketch a rough outline.

Console ports don't necessarily make a lot of money

Go check out the online store design on the major consoles, and see what's being featured. Now try to find four or five small indie game released in the last three months by a developer you've never heard of and sit back and honestly assess their relative visibility.

Heck, you can even estimate sales direclty -- albeit very, very, roughly.

If the console platform has user reviews, you can use what the Clark Tank community calls the "Boxleiter method". Take the number of user reviews, and multiply by the appropriate "Boxleiter coefficient" -- this varies with platform, but it's generally a number between 20 and 100, you could use 50 as a rough stab. It will not get you anything like a precise measurement, but if you apply it to a number of games, it will give you a decently accurate insight into the number of zeroes that kind of game's true sales figure might have. It will not tell you precisely how many sales that particular game made, let alone how much gross or net revenue. But all you really need to know is if other indie games in your league are selling tens/hundreds of copies, or tens/hundreds of thousands of copies. Chances are it leans to the former.

Also, if your game already came out on Steam, unless it's already sold a whole lot of copies, you shouldn't expect console platform hholders to be super excited about late ports of an indie game, particularly multi-platform ones. There's always exceptions, but don't let "the grass is greener" lure you into a daunting development slog you're not prepared for.

By all means be bold, be daring -- but first, do the math, and be careful.

Console ports are expensive and take a long time

No matter how smart you are and how technically proficient, and how great your engine is, you will spend more time and more money making a console game than developing the same thing for PC. Yes, even if you use Unity and Unreal.

You will need to pay for kits, and you will need to get through official console QA certification. You will almost certainly fail the first time, and probably a few times after that. QA is expensive and time consuming not just because of the stringent requirements, but also because of all the extra stuff you have to implement to pass, which includes a lot of weird platform-specific features.

You can pay for professional QA to speed things up (I highly recommend Syrenne McNulty for that by the way, she's great!), or you can try to do it yourself, which will take you much longer.

If you have any dreams of sailing through QA on the first pass, especially if you're not paying for professional QA, and super especially if you've never shipped a console game before, you're in for a hard ride. If you're lucky, you'll be done in two to three months. Six months is more realistic, and a year is not unheard of. Keep in mind all this extra time and money spent on passing QA certification comes after the point you may have already mentally flagged your console port as "basically finished."

And none of this factors in all the delays in trying to get approved for console development and access to kits in the first place.

Console build environments are tricky & fragile

Console build environments are more complicated than the equivalent for PC development because it's connected to a proprietary hardware/software platform. You have to install special software on your PC, and connect to the hardware that is itself running special firmware, and all of that is tied to a specific proprietary SDK that has strong opinions about what dependent software, environment variables, and a bunch of other stuff ought to be on your computer. Oh, and the platform holder can and will push mandatory updates with breaking changes at any time. And if you need to test networking features, you may have to jump through some arcane hoops to connect to the console's proprietary servers.

Sometimes you can set up a cleanly segregated build environment without tarnishing the rest of whatever you're doing on your PC, but that's mostly down to your technical skills. It's not a coincidence that big studios will set up entirely dedicated build machines connected to exactly one dev kit each, carefully set up with a frozen and imaged build environment that they never touch thereafter. If you're an indie developer, you probably only have a single PC.

The worst part is you can't google this stuff, you have to either seek support from the console holder or hope someone on their private forum that's also under NDA can help you out.

Developing for multiple consoles at once is a recipe for misery

Don't do it. Just don't. Take one thing at a time. Doing multiple consoles simultaneously multiplies all of the above challenges by ten. I developed for three consoles simultaneously (four technically, but we gave up on the WiiU). Big studios will have a separate build machine for each console, not to mention entire separate porting teams, whereas I was plugging them all into my one PC, and trying to sort it out in parallel with James Gray, my long-suffering console porting engineer who had his own kits. And each platform all wanted different versions of compiler software and all had their own cables and controllers, and they didn't all play nicely together, and everything was a tangled mess both virtually and literally, and if I sneezed everything would break and it would take me all day to get everything straight again just to be able to compile something. And it was hot, so very hot, in my cramped home office. I eventually clawed some sanity back by pulling out an old spare mini PC and offloading one or two build environments to just that box. In the end we pulled it off! But I set it all up in the most painful possible way.

Right now I have exactly one console project in development, for exactly one console -- Nintendo Switch. This isn't to put down the other three by any means; I'm done with them for now that my game has shipped, and one console platform at a time is more than enough scope. And I'm not in a hurry. DQ1 will ship on Nintendo Switch when DQ2 is done, because DQ1 is an extremely late port that has three other console releases already. When DQ2 releases, DQ1 will be a lot more relevant and I'll release them on the system together, and probably create a nice bundle SKU.

This isn't to say I'm not interested in, say, the upcoming PS5, or Xbox Tooie (or whatever they're gonna call it). It's just that I probably will not try to tackle those, along with previous gen consoles, by myself, personally, all at once, at the same time.

Know your limits

It's not a coincidence that many of my friends, who not only have more technical experience, but are also even using "console-friendly" engines like Unity and Unreal, don't even try to port consoles games themselves. To be clear, there definitely are a few of them who do everything themselves, but a huge number just outsource the ports to trusted console porting studios.

There's risks and costs involved with this, but there's also risks and costs involved with trying to do it all yourself. The technical risk is that you will get hard stuck and not know how to proceed. The time risk is that it will take you four times as long as a dedicated expert would. The money risk is that you will wind up spending more (either out of pocket, or in terms of the opportunity cost of your time) by trying to do it yourself than a port studio would have.

Console dev is hard, and it may not be worth it. Know yourself, and know your project.

4. Some nuanced words about open source development

Again, despite the fact that I'm deprecating the PS4/XB1/PSVita backends for OpenFL, the majority of my struggles with console development were with things ancillary to the basic technical task of building a console compatibility layer. I'm trying to say something very particular, and don't want this post to be misconstrued.

Here it is:

Whether you want to use commercial software or open source software is a very personal decision and you should weigh all your needs carefully. If you're wondering how to balance it all, I'm more than happy to talk you through it -- during business hours, and preferably over email, and I probably won't get back to you right away.

The bottom line is you should use the technology that's right for your specific use case. I am a big fan of what I happen to use (Haxe/Lime/OpenFL/HaxeFlixel), but as an open source maintainer I have very different needs, and more importantly, incentives, than a big commercial game engine company.

A commercial game engine stands to gain customers and revenue from recruiting, whereas an open source project stands to gain support burden. Granted, new users is how we grow our community and the crucial network effects that makes it possible for everybody to help eachother and "a rising tide lifts all boats" and all that. But what I don't want to do is to paper over any foreseable real issues someone might have just because I'm trying to "win" recruits for "my side."

What I want is for your project to succeed, and for you not to be disappointed or led astray. If you're going to try to use what I use, I will unflinchingly tell you every difficulty I've ever had with it (as well as what I love about it), and also give you a comprehensive list of all the other competing products and projects that have a different set of strengths and weaknesses, and you can choose what works best for you. If it happens to be the stuff I use, or even libraries I maintain in my free time, I'll welcome you with open arms. But I'm not here to sell you anything, and I have no incentive to do so. Let's be clear on that.

Best of luck out there! Gamedev is hard.

PS: here's a list of projects I find interesting that have the power to put your game on consoles, among many other systems:

Commercial

Open Source

  • Godot
    • Generally amazing and best contender for an open-source successor to Unity
  • Lime/OpenFL
  • Heaps
  • Kha
    • Extremely technically impressive and from what I've heard runs on just about everything
    • Be sure to check out the amazing Kha-powered Armory3D!
  • Monogame
    • C# engine derived from XNA, focused on new projects. Used in basically every C# indie game that isn't using Unity. Used on lots of consoles.
  • FNA
  • SDL
    • The foundation of tons of PC games (and now some console games), if it wasn't for these folks we'd have never gotten the OpenFL Switch port off the ground.

And here's some stuff that isn't console related but still very neat:

Other things I find cool

  • NME -- the project OpenFL forked from, if you like stability and an API that doesn't move around, this is for you. I heard it might have some console backends but haven't confirmed.
  • Phaser -- just for HTML5, but it's awesome.
  • Ruffle -- A Flash Player emulator written in Rust. In very early stages and focused more on preservation than for commercial projects, but if you're remotely interested in the legacy of Flash than you have to check this out.
  • Pico8 -- I love Fantasy Consoles!
  • Pixel Vision 8 -- A configurable Fantasy Console. If you like Pico8 but really wanted to tweak it to the specific visual/audio limitations of, say, the original Gameboy or an NES, this is for you.

Sign up for more like this.

Enter your email
Subscribe