Cat Burton

The Christmas holidays are usually a time of relaxation, time to put your feet up and unwind after a busy year. That was indeed how it started, until Unity announced their Flash in a Flash contest!

As part of the Unity 3.5 public beta, Unity have given us a sneak preview of the upcoming Flash export. While not all features you might currently use for your games are supported yet, there are a lot that do and the export works rather well. And so on 22nd December, Unity set the community a challenge. We were to build “the best Unity-based Flash platform game or interactive content”. The deadline for this contest is 5th Jan at midnight PST.

I was back in rural Lincolnshire for the holidays, meaning I only had my 4 year old MacBook with me. It was so old I couldn’t even install Flash Player 11. I had to wait until after Christmas, but as soon the shops re-opened I hurried out and bought a new MacBook. The game dev could finally begin. It was already almost a week into the contest by this point, so the pressure to get something started was quite intense!

I’ve never participated in a game jam, or made a full Unity game by myself before. Nor have I had to make something in Unity with such a tight deadline. Not only that, but I had no real experience with game design or audio, and no 3D modelling skills! I am used to working on large Unity projects, in a team, with talented artists and designers. This was going to be tough!

My game concept started being the story of a toy (perhaps a small robot or doll) that was left in the house alone. I liked this idea, but realised the modelling for that would be beyond my ability for a quick project. After much thought, I decided on the idea of a mouse/hamster.

The plot of the game is as follows: You play the role of Max, a mouse who has escaped his cage and is searching for Heidi (who I see as his sweetheart, aww). Heidi and max have been separated into two children’s bedrooms, those of Timmy and Lucy – we don’t yet see them in this version of the game. Max must search through the house until he finds Heidi. There is, as always, an arch nemesis for our hero. This enemy is called Bruce; a somewhat evil cat with a penchant for chasing mice.

This was quite a large game to try and make within a week. Coming up with viable levels in different rooms was quite difficult. However my main issue was a complete lack of experience in 3D modelling. I was unable to find characters in the right style on the Asset Store and so I had to try and power-level some skill at using Blender. My first attempts at modelling Max and Bruce weren’t too bad and I kept these in the game for most of the game’s development time. It wasn’t until the last couple of days that the lovely @zafio very kindly offered for me to use the cat/mouse models you now see in the game.

The game as it currently stands has 5 levels, each representing a different room in the house. All artwork/models except for the mouse and cat were made by myself – so while it may look a little rough round the edges, I am really happy that I managed to pull it all together! Coder art FTW!

The game makes use of some of the awesome new features that will be released in 3.5. Bruce navigates the room using the fantastic new NavMesh feature. It doesn’t take much work at all to get him following Max around! I also tried out the new occlusion culling which seems to work really well. The time to bake these scenes was very short – which is handy when you’re rapidly prototyping a game but also needing to keep performance high! I also had a play with the new particle system for the fireplace in the lounge level. That system is much more advanced than the one you’ll find in 3.4.

I’ve now submitted the game to the contest and am looking forward to seeing everyone else’s games. There are a lot of very talented people in the Unity community and the entries I’ve seen so far on twitter have been brilliant!

I will continue to work on this game now that it has been submitted. I have lots of ideas that I didn’t have time to implement in the last week. These include:

• Actual artwork & animated models – there’s only so far you can go with coder art
• Level specific audio
• More levels – kitchen, attic, hallway, bathroom etc
• Full overhaul of the menus/gui
• Different game modes – I’d like to make a mode where you control Max in a hamster exercise ball – would be fun to implement.

That lot will probably keep me busy for a fair while. Still, it’s nice to finally have a side project!

Below are some screenshots from the game. If you’d like to play it, you can do so here (you’ll need Flash Player 11 installed).

I’ve spent this week looking at using Asset Bundles for our Unity project at Mind Candy. And since we’re using them, it makes sense to take advantage of the webplayer cache. For this, we’re making use of the WWW.LoadFromCacheOrDownload function.

Testing whether this cache is used/updated correctly proved difficult at first as I wasn’t sure where the cache files were stored on OS-X. I could see the cache files were being created using Unity’s Web Player Settings page, but I wanted to double check the versioning was working as expected.

Anyway, some failed googling and trawling of my Mac later, I’ve found them:

/Users/[username]/Library/Caches/Unity/

Hoping this will save fellow devs some time hunting them down!

I had plans of finishing more Dead Island tonight before Friday (yay Skyrim)! However, the moon and Jupiter looked so lovely that I ditched gaming in favour of some amateur astrophotography. I think it was an evening well spent…

Jupiter’s Moons and a Cloud Hiding Ours

The Moon and Jupiter

A Close-Up of the Moon

Session overview: “Creating a browser-ready first-person shooter MMO in Unity presents massive gaming opportunity but also a set of unique client-server challenges. Join the developers from Aquiris Game Experience and Electrotank as they discuss the hands-on lessons they learned in creating an upcoming free-to-play FPS MMO for PC/Mac and the browser.”

A very informative session by guys from both Aquiris and Electrotank. The session started with a realtime demo of Aquiris’s FPS. The game looked fantastic, particularly their UI which they wrote themselves in OpenGL. That effort clearly paid off as the game is gorgeous! The multiplayer element seemed to work really well, with them demoing against a team of guys in another studio.

Artwork challenges/considerations encountered when making the game:

•  They made a basemesh covering entire level: max 50k tris, max 30 objs, max 3k tri per obj
•  Smart texturing – They limited textures to a maximum of 30 textures. 50% tileable; 25% trim; 25% unique.

When developing the game, they made automatic import tools to handle the setup of the many weapons and maps. Extensively used asset bundles and then because it was taking too long to build the project they developed their own tool to enable you to toggle which bundles should be built. Rather than storing weapon data in xml/json etc they used scriptable objects to store this info. For map details, this was stored in xml on the server, sending the client the correct map config at runtime.

During development, they had a number of networking options available:

• Unity’s built-in networking – Their opinion of this is that it’s good for small games. Nice features mentioned include the fact it’s integrated and easy to use (easy rpc calls, easy to share objects). However they believe it’s not made for thousands of players per instance. It’s good for local hosted games, but not for 2000+ players on single server.
• SmartFox – They skipped any comment on this
• Photon – As with SF, they didn’t comment on this
• ElectroServer5 – This is the solution they chose because they knew it already works well with flash. ES5 also has good admin tools. It runs on linux and is java based.

Originally the Aquiris team considered using a P2P solution for their MMO but decided on client-server for a number of reasons. They wanted a semi-authoritative server with 100+ matches per server instance and 8 to 18 players per match. During development, the networking layer was separated from gameplay by making the solution event driven.

ElectroServer5:

•   ES5 nodes handle realtime simulation, persistence.
•   Distributed simulation / load distribution.
•   Runs on EC2 – scales to meet requirements
•   EUP handles matchmaking, loadout etc
•   MatchNodes – register themselves with EUP. Can add/remove themselves at any point.
•   Protogen (protocol engine) is described on their site as “a framework to support creating protocol specific objects dynamically via a simple declaration file. Protocol message objects (client and server) and their codecs are generated by EUP, saving developers significant time and effort.”

I just attended the Flash afternoon at Unite where Lucas Meijer and Ralph Hauwert detailed the latest progress on Unity’s export to Flash. On first impressions, the games they’ve been working on look fantastic! One of the reasons I’ve been keen on working with Unity over Flash for 3D games dev is the awesome toolset, and these guys have really nailed the Flash export.

As long as your code isn’t doing anything too “exotic”, Unity will convert your code (c#, js (strict) and boo) to ActionScript. It will then compile this, along with your assets, into a swf using the mxmlc compiler. One thing to note here is that literally everything is compiled into that one swf. There was mention of them using asset bundles at a later date to generate individual swfs for content such as scenes. Since everything is in one swf, that means file sizes could get pretty large really quickly. One of the demo apps generating simple spheres compiled to a ~1.4mb (iirc) swf which is pretty chunky for something so simple.

The generated AS3 code is pretty readable although since there’s no method overloading in Flash, they’ve had to compromise on function names somewhat! That said, it should be pretty easy to debug your exported app.

The features currently supported in Flash are:

• PhysX
• Particle system
• Custom and standard shaders

Things that won’t work in the first version include:

• Anything needing depth textures
• Advanced audio such as doppler and reverb
• Dynamic shadows
• Mouse lock
• Unity networking (you’ll have to use a Flash networking solution for now)

Looking at the performance of the games, they seemed to run pretty well. They mentioned trying to push anything you can to the GPU rather than CPU. An example given would be to animate textures in a shader rather than scrolling it in a script, as well as the usual light baking and occlusion culling. Basically, as Lucas put it: “The best way to make your game go faster, is to have it not do stuff”.

So to summarise – from a first glance, the Flash export looks pretty awesome, and the Unity guys have done a great job getting it working. There are still a fair few features missing, but there should be enough there for most simple Unity games to be exported. Unfortunately, both the release date and the price were listed as “TBA”, so I guess we’ll have to wait a little longer before we can try it out.