Hi, I'm Henry. In 2012 I quit my job as a programmer at BioWare to spend a year making my own indie games. This blog is about what happened next...

Like Spaceteam? Want to support my work?
Join the Spaceteam Admiral's Club!

Unity Progress

I’m now fully committed to the Spaceteam rebuild.

It’s a big investment in the future of all my games and the sooner it happens the better. I’ve been wasting too much time tracking down obscure bugs which will soon become irrelevant, so I’ve stopped development on the 1.8 branch until the new version (2.0) is ready.

Sorry to everyone currently experiencing crashes, you’ll have to wait a bit longer for a fix. Thanks for your patience!

In the end I decided to go with Unity 5 and I’m really enjoying it so far.

The UI system makes it easy to scale and anchor elements so they work at different screen sizes. This was a pain to get right before and annoying to test, so the new system is a pleasure to use.

The Particle system is powerful enough that I can directly recreate most of the effects I was using. I can now use Animations for some sequences I was previously doing in code.

There are handy built-in features like Serialization and JSON parsing that I get for free.

And I love being able to easily make custom visualizers and editors that work right in the Editor.

Here are some more notes on how I’m using Unity:

Project Setup

  • I’m using C# for the CaptainsMess networking portion and Javascript for the game code. But I’m considering moving everything to C# so I can get full debugger support (I’m assuming you can’t do source-level debugging in Javascript?).
  • I use Sublime Text 3 on the Mac as my script editor, but I’m also looking at Visual Studio Code which has some nice integration features and debugger support. VSCode also works much better with C# than with Javascript.
  • I’m trying to use plugins from the Asset Store as much as I can. These are the ones that have sparked my interest so far:
    • I2 Localization. I have 12 languages to support!
    • xARM. Useful for testing multiple screen resolutions on different devices (iPhone 4, iPhone 6, iPad, Android tablet, etc)
    • Google Sheets for Unity (GSFU). Handy for getting simple data tables into the game, like level progression.
    • TexturePacker Importer. I already use TexturePacker to make sprite atlases for the Cocos2d version so I assume it will help here as well, although Unity has some built-in sprite packing so maybe I won’t need it.
    • Editor Console Pro. Search, filters, and colours for the debug console.
    • VSCode. Integration for the VSCode editor.
    • PlayMaker. I had heard good things about this tool so I wanted to check it out. I like being able to create state diagrams that not only provide a high-level view of the game logic but are also functional. I still haven’t decided whether I’ll use it in production.

#

Networking

  • At first I looked at the Photon framework but it turned out not to be a good fit for Spaceteam. Most of their services are online rather than local and if I want to use their Redistributable Server license it seems I’d have to pay for every 500 users, which is totally untenable for my needs.
  • My current plan is to just use the built-in Unity Networking. I don’t have to pay for it and it covers most of what I need already, so the CaptainsMess library may end up being a relatively thin wrapper around it.
  • The main classes I’m using are part of the High-Level API: NetworkManager and NetworkDiscovery
    • The NetworkManager class can start a server or client but has no discovery
    • The NetworkDiscovery class can broadcast and listen for other devices but has no server/client code
  • For the initial connection I’m also using NetworkLobbyManager and NetworkLobbyPlayer
    • These classes already track “slot” (ie. player index) and “ready” state so I don’t have to
  • The main thing I’ll have to add is the ability to search for games as a server and client at the same time. The current system only supports one NetworkManager object so I’ll have to work around this with some lower-level code.
  • This networking system seems to be quite new and I’ve encountered a few weird bugs and idiosyncrasies but they’re pretty minor so far.
  • Luckily, Unity has made the source code available which makes it much easier to debug and modify: https://bitbucket.org/Unity-Technologies/networking

General Tips

  • Remember to set “Playmode Tint” in Editor prefs so you don’t lose changes you make in Play Mode!
  • Don’t name Prefabs the same as Instances!
  • If you’re doing things with a networked Player object remember to check isLocalPlayer to avoid redundancy and confusion.
  • Changing a child object name after animating its properties breaks the connection and marks it “Missing”.
  • Reference for mixing C# and Javascript:

    http://docs.unity3d.com/412/Documentation/ScriptReference/index.Script_compilation_28Advanced29.html

  • Extend data classes from System.Object if you want them to be inspectable in the Editor (add [Serializable] in C#)
  • You can’t define generics in JS, but you can use them (with dot before brackets: List. instead of List)
  • Use builtin array[] in Javascript instead of Array if you want to see the items in an inspector.

I know that a bunch of you already know Unity so maybe you can help me answer some questions that I have.

My Questions

  1. Can I rearrange folders in Assets or should all extensions/plugins live at the root level? I’d like to put packages I download from the Asset Store into a subfolder but whenever I update something it wants to import it at the root level.
  2. Any tips for using the Animation Controller system as a regular state machine with transitions triggered in code? (eg. for abstract game states like Lobby, Setup, Intermission, Playing, etc). And if I do this should I be using “Trigger” parameters or just go directly to the state with Play(“StateName”)?
  3. If I have a bunch of unique objects (eg. UI screens like Title Screen, Credits Screen, etc.) should they all exist in the scene and get Activated/Deactivated as needed? Or should they only exist as prefabs and get Spawned when needed?
  4. How do you ‘diff’ scene files in source control (I use Git) to find out what changed? I’ve found some methods for saving them as text and plugins that claim to solve the problem but it seems like it could be error-prone. What do you recommend?
  5. Is there an advantage to separating things into Scene files if your game has very little content like mine? Will it be ok to have everything in one scene?

I’m officially on holiday now but I’m looking forward to continuing the project when I get back.

Thanks for listening and Happy Holidays!


Quandary

I’m reaching the point where my “technical debt” is finally catching up with me. The Spaceteam codebase is now 3 years old, using an out-of-date customized version of cocos2d for iOS (notably not cocos2d-x). I’m stuck with this code primarily so I can get the Android version for “free”. My Android build is reliant on the Apportable SDK, which I can still use and still works ok, but I can no longer update it or request new features. And it is difficult to debug.

But I’m trying to move on from Spaceteam, so why does this matter?

Well I still want to support the current players, and I’m starting to get Android bugs that are much harder (and in some cases, potentially impossible) for me to fix on my own. Some of them are just annoying but some are hard crashes, preventing the game from starting. Even if I can fix these bugs they end up taking a lot of time to diagnose and test. I can’t really get help from experienced Android programmers because there is no Android code to work with.

If my Android “solution” no longer works then this not only impacts Spaceteam and its various incarnations (Spaceteam ESL, Spaceteam Kids, etc.), but also my new projects like Blabyrinth that are based on the Spaceteam code. If I can’t easily get Blabyrinth to run on Android then I have no reason to stick with my ancient, cobbled-together, spaghetti Frankenstein code.

So I’m seriously considering rebuilding Spaceteam with new technology. It will take some intense work (at least a month) and if I do it right then nobody will notice that the game has changed. There won’t be any new features. Except that everything will work better. It’s a big investment in the future. Here are the advantages:

  • Lots of major bugs will no longer exist (…with a few minor ones to replace them)
  • The game will be much easier to maintain and extend
  • I’ll have control over the Android version
  • Lots of community support, both locally (friends in my co-working space and Montreal in general) and online
  • Much easier to find and hire development help if I need it
  • Opportunity to use better networking libraries
  • Possibility of a Windows Phone version!
  • I’ll feel a lot more comfortable and proud sharing the project source code with people 😃

If I can make it work then it will be a much happier note on which to end the main Spaceteam saga and finally move on to other things. So I’ve been investigating this over the past week.

The obvious engine choices are:

**

**

cocos2d-x: The cross-platform variant of the engine I’m currently using. This would be the most straightforward port because it’s very similar and supports almost all the same features. It’s tailored for 2D games, which is good for Spaceteam and Blabyrinth.

Unity: Unity has even more community support than cocos. I love Unity and I want to use it for future games, so getting more experience now is another bonus. They have recently improved their 2D, UI, and networking components, all of which are critical for my games. And they have high-quality reusable components available in their Asset Store.

I’ve experimented with both and so far I’m leaning towards Unity.

A Finer Mess

The other project that would be affected (positively) by this change is CaptainsMess, the much-delayed local multiplayer networking library that I want to make freely available.

The delays were due to higher priorities but also to the fact that in its current state it is iOS-only and still has connection issues so I wasn’t confident releasing it at this level of incompleteness.

But if I rebuild Spaceteam then I also have to rebuild the networking and make it work cross-platform, possibly as a Unity plugin, which I think will be much more useful to people.

Whatever form it takes, it will be the version that Spaceteam actually uses and so I would continue to support it. If I go ahead with the rebuild then the old version (if I released it) would be dead on arrival.

Anyway, I’m as frustrated by the delays to Blabyrinth as you are and very eager to work on it again, but I just wanted to explain and justify what I’ve been struggling with lately.

Space out!


Surprise Television

Just when I thought I was out, they pull me back in…

So in a somewhat surprising announcement, I just released Spaceteam for the new Apple TV!

I say surprising because a month ago I didn’t think this is what I’d be doing. I was interested in making a game with a large shared screen, but I wanted it to be something new, designed from the beginning with the TV in mind.

But then, a few weeks ago, I got contacted by Apple. They convinced me that Spaceteam would make a great couch co-op game for the new Apple TV launch. When Apple shows interest, it’s hard to say “no”. Potential benefits included:

  • A significant chunk of new players, with not many games to choose from (yet)
  • Some practice developing for the big screen
  • Improving my relationship with Apple :)

So I dropped everything and spent the last four weeks crunching to redesign the game to work with a remote control.

Since it was for the new product launch I wasn’t supposed to talk about it which is why I’ve been quiet lately, but I’m finally finished and glad to be recovering and then back to my regularly scheduled programming. I missed the actual launch date by a few days, but it’s still early so hopefully I’ll make it into the next round of App Store features!

Here are the design ideas I went through trying to make it work:

Spaceteam doesn’t make sense as a single-player game so you still need one or more other devices to play, but an Apple TV with Wifi gives you pretty ideal conditions for getting a game connected and set up.

The Siri Remote lets you swipe up/down/left/right and “click”, so that’s what I had to work with. Dials don’t really make sense, and even simpler actions like pressing buttons feel different since they’re one step removed from directly touching a thing you can see.

I wanted to experiment with a few different “game modes” for the TV player since I didn’t know what would be fun.

NOTE: I only had time to finish two of the new game modes in time for launch (Controller and Observer), but I did a bunch of work on some of the others so they’ll probably make it into an update soon.

Observer mode: This was the most obvious use case to me. The TV shows an overview of the game (ie. a large viewscreen and everyone’s panels) but doesn’t actually control anything. Good for spectators at festivals, tournaments, etc.

Navigator mode: TV gets a single navigation stick that can be swiped up, down, left, and right. It comes with special instructions “Hard to port!”, “Hard to starboard!”, “Pull up! Pull up!”, “Dive! Dive! Dive!” and new obstacles to avoid. Turns out the navigation control was just too boring to use so I cut it. But my artist G.P. made some cool new obstacles for this mode so I’ll find some other way of including them.

Controller mode: TV is just a regular player. They have a wide horizontal panel with simple push/toggle controls, operated by swiping a cursor left and right and clicking. This feels the most like classic Spaceteam and required the least amount of custom design, so I focused on this and included it as the default.

Thwarter mode: TV player is an antagonist who controls asteroids, wormholes, disasters, and anomalies. I first considered it as a non-cooperative mode but then realized it might be more interesting as a cooperative mode where the TV player had to carefully manage these disasters by preventing them, choosing the timing, or being forced to decide between them under pressure. I didn’t have time to finish it.

Cat Wrangler mode: TV controls the paw of the ship’s cat by swiping on the remote. The cat just gets in the way and makes it harder for the other players, but also has a goal of its own. I really want this to work and I still think it can somehow, but I didn’t have time to make it feel good for the first release.

Commander mode: TV gets ALL the instructions and others players only get controls. TV player does all the shouting :) This eliminates the two-way communication dynamic, but might still be fun. Didn’t have a chance to try it yet, but I’d like to.

Do you have any suggestions for how to incorporate the TV in an interesting way? Let me know!

While I was writing this post I had another idea for a mode with a massive control board on the TV, much too big for a phone screen. The players with phones would each have a “window” onto this board that could be moved around to get to the individual controls. Instructions would all be delivered on the TV. Players would have to coordinate which sections of the board to cover, either by themselves or with a dedicated “dispatcher”.

But I think some of these mechanics would be better served by a game designed up front for a TV player, instead of shoehorned into Spaceteam. So I’m going to save them for the co-op TV heist game I want to build!