On Saturday, I attended the fantastic Gamecamp unconference at the London South Bank University. The annual event encourages attendees to add their talks to the schedule on the day. As a result, there is a fantastic variety in the topics and sessions.
One of my favourite sessions from this year was a roundtable discussion about how to stay sane while being indie. This session was an informal discussion with about 20 of us in the room. There were some fantastic points raised from many people who have tried the indie life and struggled with it.
A lot of the points raised really hit home for me. I plan to take on board a lot of the advice while working on my indie projects and I hope this summary will help others too.
Here are the main areas we discussed:
Exercise. An obvious one but one that is incredibly easy to ignore or forget about. For a lot indies like me who work at home, their routine is to wake up, walk to another room, and sit there all day working hard on their project. Exercising is often forgotten about (or, lets face it, not entirely enjoyable), but it is vital to keep yourself fit and healthy. The healthier/fitter you are, the better you will work. This doesn’t mean you necessarily have to go to the gym every day. If you’re like me and dislike the gym environment, there are plenty of alternatives: take a dance class, go for a run (free!), or even simply go for a walk. Even a small amount of exercise per day will work wonders.
Eat healthily. This is closely related to the previous point. If you eat healthier, you will feel better in yourself and be more productive.
Get out and see people. Whether it’s a quick walk round your neighbourhood, a wander round the shops, or a nice stroll through the park, getting out of the house and seeing people will help you keep a grip on reality and will help stop that cabin fever feeling. It often helps to have other people around you to motivate you, so rather than working alone, try finding a group of likeminded people to co-work with or meet for coffee.
Schedules and breaks. Just because you’re indie does not mean you can/must/should work ridiculous hours on your project. It’s fantastic if you’re motivated and want to work hard but if you put in too many hours at once you will eventually burn out. Instead, pace yourself and work at a sensible rate. Try to set yourself a clock-off time as if you have a day job so that you can spend some time relaxing and get a break from the project. It is also very important to take regular breaks during the day, especially when staring at a screen all day. Try to break your work into small manageable chunks so that you can naturally take a 5/10 min break after each task without getting too distracted or having to stop mid-task. Taking a short break or an evening off from your work will give you chance to reflect on your project. So many of us have been stuck on a feature only to get a good night’s sleep and wake up with the answer. Allow yourself a break from time to time – it will help. One solution for helping us to take breaks which was mentioned in the session is an app called Workrave. This app will regularly prompt you to let you know you need to take a break.
Keep a TODO list. On my projects, I always have a TODO list. I’ve tried many options from a scrum board of post-it notes on my wall, to simple google docs, to now using Trello. There are many advantages to having a well structured TODO list:
They provide you with a clear list of what needs to be done. This will help you to prioritise and work out how best to tackle the job. It also means you can unload all those tasks from your mind and concentrate on the single task at hand without constantly worrying about forgetting to do something.
Tasks should ideally be broken down into small manageable chunks. If you have one large task which will take a day or more, break it down into a checklist of smaller sub tasks. By having a solid list of tasks (broken into smaller sub-tasks) you will naturally fall into a pattern of having short breaks at the end of each sub task.
A great benefit of TODO lists is the action of marking a task as done. Whether this is dragging a task in Trello to the “done” column, checking off a sub-task checkbox, or taking a post-it note off your wall and placing it in a done pile, it is all positive reinforcement that you are making progress and doing well. Try to keep all of your completed tasks so that you have an ever-growing pile of completed tasks. See, you really have been working hard!
Guilt. It is vitally important to keep a your work/life balance when working on your own projects, even though it can sometimes be hard to switch off from your work. Many people in the group mentioned they feel incredibly guilty if they’re not working on their project, even if they are doing something they enjoy or need to do. There is no reason for you to feel guilty. Taking a break, as mentioned earlier will really help you to re-focus on your project and also stay happier. Try to make your breaks something that is done away from your work environment. Make a cup of tea, play with Lego, go out with friends, visit a museum, take up knitting. Whatever it is, find a hobby or social activity away from the computer screen that you can do to relax for a while. And whatever you do, don’t feel guilty about taking a break – you’ve earned it!
Depression/Stress/Sleep problems. A few of the people in the Gamecamp session mentioned that they have suffered with depression, stress or had trouble sleeping. This is something that can easily affect everyone but is unfortunately sometimes difficult to talk about. If at any point you start to feel overworked, stressed or depressed, take a break and try to speak to your doctor about it. There are people there who can help you so don’t suffer alone. The sooner you find someone to help, the sooner you’ll get better and can finish that project you’ve been working so hard on.
If anyone else has any other great advice for staying sane while being indie, I’d love to hear them! Please feel free to comment or email me and I shall add them to the list.
A couple of months ago I took over the responsibility of organising the London Unity User Group (#LUUG). Organising my first full LUUG was quite hard work, but it was definitely worth the effort!
After the last LUUG people seemed to really like the open mic sessions, so we decided to dedicate more time to them this month. This seemed to work well and we had a fantastic selection of presentations during the evening.
Here’s a quick round up of the talks…
1) Tomas Rawlings – @TomasRawlings
Tomas talked about the Royal Society game jam that’s happening next month. Here’s a summary of the event:
Get £2K+ to Game Jam Cutting Edge Science into Fun: Deadline 1st May
The Royal Society is looking for experienced games development studios to take part in a new initiative that will turn some of the research on show at its annual Summer Science Exhibition into video games. The Royal Society will host a 12 hour game jam on 24th May that will see developers work with the scientists behind exhibits to produce five exciting new games. Five development teams of up to 4 developers will be partnered with the selected exhibitors for an all-day game jam from 10am – 10pm. Each development team will receive £2,000 to further develop their games after the game jam so that they are ready to be played at the Summer Science Exhibition which runs from 1st – 7th July. The games will be available free online and at the exhibition itself so that the public can cast votes for their favourite game. The team that receives most votes will receive an additional £2,000 to further develop their game once the Exhibition closes. This is a great opportunity to get your name known, make some amazing games and get paid too! Reasonable travel costs, food and refreshments will also be provided. Interested developers can find out more about the competition and how to apply from the Royal Society’s website at http://bit.ly/RSgamejam
The hashtag for the game jam is #RSgamejam
2) Russ Morris – @TheRussMorris
Russ showed us RescueNauts, the game he’s been working on with Iain Gillespie. You can play RescueNauts here: http://gamejolt.com/games/arcade/rescuenauts/14019/
3) Nate Gallardo – @poxican
Nate showed us his university project, icefishing v. Icefishing v is an interactive sound-art album, inspired by noise, glitch and ambient music. You can check it out at: http://v.icefishingmusic.com/
4) Danny Goodayle and Roberta Saliani – @DGoodayle, @robertasaliani
Danny and Roberta told us about the London Game Jam which will take place on June 1st at Modern Jago. Tickets for the event are available now via http://thelondongamejam.eventbrite.co.uk/. For more info on the game jam, see http://thelondongamejam.com/.
5) Mark Baker
Mark showed us a sneak preview of a previously unseen Moshi Monsters game for iOS. I have no links for this game, but it looked really nice.
6) Tom Szirtes
Tom is from Lantern Interactive (http://lanterninteractive.com/). He showed the beautiful trailer for their game The Realm (@TheRealmGame, www.therealmgame.com). The game looks stunning! They have a kickstarter for the project which is definitely worth taking a look at and backing: http://www.kickstarter.com/projects/995134339/the-realm-game.
7) Rui Antunes
Rui is the tutor of a short introductory course on Unity3D (20 hours, 2 hours each Wednesday evening) at City University. If you’d like more information on the course, check out the City University page: http://www.city.ac.uk/courses/short-courses/game-development-using-unity-3d.
8) Vegard Myklebust – @usefulslug
Vegard showed us the latest update to his fun Will Smith inspired dance game for iOS called Super Dance XPerienz 92. If you want to check out the game, there’s a build on Vegard’s website: http://www.usefulslug.com/dance/.
9) Richard Hawkins
Richard showed us a game he’s currently working on called Wilson’s Adventure. The game will be available on iOS, Android and OUYA:
“Join Wilson on his adventure as his plane crashes on a strange island. Help him Find Jane, the love of his life and save her from the cluches of evil.”
10) Andy Touch – @andytouch
Andy showed us his painting game, Go Paint, in which you can place paint in a 3D environment and even build with it. You can play the game and view the gallery here: http://www.paintpaintpaint.co.uk/. He also showed us a finger painting app he’s been working on where you can paint a cube using Leap Motion.
11) Jon Weinbren
Jon presented a 3 minute showreel of the current projects being worked on for the NFTS games course. The full showreel can be viewed on the NFTS site at http://screeningroom.nfts.co.uk/video/nfts-games-work-in-progress-showreel. If you would like more information about the course itself, check out http://nfts.co.uk/our-courses/masters/games-design-development.
12) Rob Saxton
Rob showed us his latest game GnarBike Trials 2. This game is the sequel to GnarBike Trials (Androidhttp://bit.ly/ZzFYOK, iOS http://bit.ly/11pPq44) with a big focus on user creativity. The in-game level builder will be packed full of features, so you can create and share amazing custom levels with ease!
There were also a couple of announcements and follow-ups people have asked me to mention to the group:
Firstly, Ben from Mousebreaker has mentioned that they’re looking for Unity developers. He said: “I’m looking to commision games for our games portal www.mousebreaker.com. If you are a Unity developer please drop me a mail to see if we can work together. We are based in London, but you can work from remotely. Previous experience is a must.”. If interested, you can contact Ben via email: email@example.com.
And finally, Will has asked me to mention Unite Nordic. I briefly spoke about this on the night but figured more information would be helpful! Unite Nordic takes place in Malmo, Sweden, on 21-22 May. The lineup for this event looks great, with talks from Mojang, Rovio, the Unity team and more. The event is then followed by the Nordic Game Conference (22-24 May). For more info, check out the following links:
Unite Nordic: http://unity3d.com/unite/nordic/
Full schedule: http://unity3d.com/unite/nordic/schedule
As a big fan of Unity, it may be surprising to hear that I have decided to leave my role there. Today was officially my last day. I’ve enjoyed my time there greatly – the team is incredibly talented and the product is fantastic. I’ve made a lot of great friends during my time at Unity and I’ll miss the team a great deal.
However, after helping a lot of game developers and studios all over the world with their Unity games, I have realised just how much I miss game development. I really do love making games.
And so, as of today, I am taking a massive leap of faith. I’m leaving the land of employment and venturing into the unknown world of indie game dev with Mark. I will now be working full-time on our own game projects. Naturally, we shall be using Unity to make them!
We’ve got plenty of ideas and a lot of game dev/design experience between us, so we’re planning to develop many games together. We’re very excited! We’re also realistic about how difficult this process will be. I’m expecting the upcoming months to be very hard work, very challenging and probably rather stressful. At the same time though, it will be really fun and a great learning experience.
For the next few months, I’ll be developing our projects full-time, but may occasionally take on paid work from early next year. If anyone needs a freelance game dev or consultancy help with Unity projects in 2013, please do get in touch!
I’m now ready for the next chapter in my game dev adventure! Bring it on!
This weekend was the first Molyjam, based on the ideas of Peter Molydeux. The jam took place over 48 hours with hundreds of games made globally. Lots of sites have detailed the jam already, so I’ll cut to the chase and talk about mine and Mark’s game…
We decided to make a game based on the following tweet:
“Imagine carrying a radioactive baby in a pitch black environment, your baby would act as a torch. Rocking the baby intensifies the glow etc”
Over the last weekend, I’ve been hard at work trying to get an unannounced Mind Candy project (made in Unity) to export to Flash. I thought it would be useful to share some details from the experience since most of the issues I’ve encountered would probably be avoidable if your project is architected in a way that lends itself to Flash export.
During the Christmas holidays, I made a game for Unity’s Flash in a Flash contest. It wasn’t the most exciting game, but it worked. The core mechanic of that game (including new 3.5 features such as nav mesh) exported to Flash well. The reason this game worked is because I had been paying close attention to the Flash export and knew what features wouldn’t work at that time. I avoided anything overly complicated and developed the game with the limitations in mind. Fundamentally, I decided to make a new, simple game rather than trying to port an existing one.
Now, I’m doing the opposite. I’m trying to get an existing game to publish to Flash. This project is a relatively large one. The game has been in development for quite a long time. It contains a lot of complex C# code and most importantly: a lot of features that don’t yet work in the Flash export. Trying to get this game to export to Flash is no easy task. I’ve spent numerous weekends on this since the 3.5 beta was made available and I still haven’t got it to work.
Despite the export (currently) not working for our project, there are a lot of lessons to be learned. Hopefully these will be of use to other people attempting the same task, and will be a good reference point for myself when I inevitably try to export the game again at a later date.
Currently Unsupported Features
Unity have already listed some of the unsupported features in the Flash export as part of the 3.5 preview faq. Some of these features (and the ones that have proved most problematic for me) are:
- Asset Bundles
- Raknet networking
If you’re using these features, then you’ll encounter a lot of errors as soon as you try to get Unity to build to Flash. Some example errors I’ve seen are:
- error CS0246: The type or namespace name `ConnectionTesterStatus’ could not be found. Are you missing a using directive or an assembly reference?
- error CS0246: The type or namespace name `NetworkView’ could not be found. Are you missing a using directive or an assembly reference?
- error CS0246: The type or namespace name `BitStream’ could not be found. Are you missing a using directive or an assembly reference?
- error CS0246: The type or namespace name `WWW’ could not be found. Are you missing a using directive or an assembly reference?
- error CS0246: The type or namespace name `MovieTexture’ could not be found. Are you missing a using directive or an assembly reference?
These errors are effectively a checklist of all the classes you’re using that aren’t yet supported and there’s only one thing you can do: remove them from your build. There are numerous ways to do this (depending on what you’re trying to achieve), from brute force deletion to telling Unity to skip these sections in a Flash build. You can do the latter by using platform dependant compilation.
All you need to do is wrap your Flash specific code in a platform check such as:
In my case, the first thing I had to do was to try and remove these unsupported features. MovieTextures were easy to take out, as they’re not vital to our game. Networking, however was more problematic. And this is my first (and most important) lesson…
Lesson 1 – Separation of Networking Code
Our game currently uses the inbuilt RakNet networking solution. These networking elements are fundamental to our game, and as such, the networking code exists in many different areas of our codebase. When publishing to the web player or a standalone app/exe build this is fine. For Flash export, this suddenly creates a big problem when the networking solution isn’t yet supported.
As an example, if your game uses RPCs across clients to update core data in your game, then you’re going to have problems. I’m sure that there are other solutions which are better suited to Flash export, but this doesn’t fix my immediate problem: we have a game, where our chosen networking solution won’t publish to Flash. Unity suggest that you can use Flash networking instead of RakNet, but since I’m doing this export with tight time constraints (self imposed, by the mere fact it’s a weekend), that solution is not feasible for this test.
This has left me with one option in my mission to get our game working: rip out RakNet. This is not ideal, but luckily, our game copes with it ok.
This raises an interesting point in that the networking code should be as decoupled from the core mechanic of your game as possible. In some cases this can’t be done, but if you can find a way to make your networking layer easily removed/changed, then you’ll be in a much better place than I was regarding Flash export. It will also help you if you ever decide to switch to a different networking solution.
At this point, I’m going to gloss over about 10 other failed builds. It takes a few attempts at building to clear up this first wave of errors. Once you’ve cleared that first wave, you can breathe a sigh of relief and ready yourself for wave two: Attempting an actual build…
Attempting a Build
Once you’ve fixed/removed/hacked-out all the unsupported features, you’ll get to a point where the build process will now try to publish your game to Flash. The type of errors you get now will be more complex than those in wave one. Below is a screenshot of one of my build attempts at this stage:
You’ll note that these errors are more complicated than the “you can’t use ClassX because it’s unsupported” ones. In the case of these errors, it’s up to you to go into each of these classes and try to simplify your code as much as possible.
Some areas where our build failed were where we’d used generics. For example, we had fairly complex code to randomise the order of elements in an array. It wasn’t vital, so it went in the bin. This seems to be a common trend in trying to get this project to build to Flash. I’m slowly, over time, discarding features to the point where it’s a very stripped-down version of the game.
There are a couple of errors regarding our audio library in the above screenshot. This library wouldn’t convert at all (I got multiple waves of errors). My only solution at present has been to remove it.
The last item in that list is log4net. This caused a lot of issues. Rather than spending ages resolving them for this test, I decided it should also be removed. Since we used the logging in a lot of our code, I’ve ended up writing my own logging classes based on the log4net interfaces. This meant that I only had to fix up the imports in the class and our existing logging would still work using Unity’s own Debug.Log etc.
A few more iterations and build attempts occurred before wave 2 was complete. All in all, the first two waves have taken out large chunks of our features, and as a result the game feels somewhat unstable.
Akin to a game of [insert zombie survival FPS game of your choice here], we’ve just about survived the first few waves. We’re battererd, we’re bruised, but most importantly, we’re not defeated! We’re now ready for the next wave. Bring on the boss; the tank; the last major hurdle in the flash export – the conversion of your code to ActionScript.
Converting your code to ActionScript
At this stage, when you try to build, Unity will attempt to convert your source to ActionScript. Having previously spent years as a Flash developer, I find this part of the build rather exciting. The guys at Unity have done a fantastic job of getting this process to the stage it’s at.
That said, this is probably the toughest part of the process. Ripping out features and (to some extent) fixing the errors in the previous stage is easy. Trying to work out why the generated ActionScript doesn’t work is much more difficult. Luckily, when a build fails, you can find all the AS classes in a temp folder in your project (/Temp/StagingArea/Data/ConvertedDotNetCode/global/). This will enable you to look at them (if you wish) and try to understand where it might be going wrong, such that you can adjust your C# or js accordingly.
In my first attempt at this stage, I was left with 87 errors. The following are a small selection of these to give you an idea of the kind of problems I’ve seen:
Conversion Error 1
- Error: Access of possibly undefined property $Type through a reference with static type Class.
This error seems to be very common and occurs when reflection is used (and probably in other situations). Unfortunately, a lot of our core libraries use reflection, and as such, this is a large problem to try and fix.
Conversion Error 2
- Error: Call to a possibly undefined method IComparable$1_CompareTo_T through a reference with static type Number.
This has occurred because we’re trying to compare two values whose classes implement IComparable. In our case, this could be worked around relatively easily.
Conversion Error 3
- Error: Type was not found or was not a compile-time constant: ReadOnlyCollection$1
In some of our classes we’re providing access to ReadOnlyCollections. It seems that we can’t use these at present and we could work round this by simply returning a standard Collection.
Conversion Error 4
- Error: Call to a possibly undefined method String_Constructor_Char_Int32 through a reference with static type String.
A common style of conversion error that’s quite tricky to work out. I saw a lot of errors similar to this one.
These are just 4 of the 87 errors which need fixing. I expect that if/when all 87 are resolved, I’d have another wave or two to get through before the game would actually build. For now though, it’s Sunday night and I’ve run out of time to work on this test.
My next challenge in this Flash export test is to go through the aforementioned 87 conversion errors and try to resolve them. I’m hoping that I’ll be able to get the game to build after another solid few days working on the export.
If that task proves too difficult then I will try a different approach of starting from a clean project and adding features one by one. In theory, that should be easier to get working, although that’s not how we’d want to export to Flash in the long run.
If I do get the export to work, I shall write a follow-up post with a walkthrough of some conversion errors. For these, I’ll include (where possible) the raw C#, the converted AS, and examples of how the errors can be avoided/solved.
For now though, I’m going to give up and play some well-earned Killing Floor!
I’ve been trying to learn the basics of Blender in the last few weeks and have struggled to find a good list of learning resources. Rather than keeping my own list of useful tutorials/links, I thought I’d create a list here. I’ll continue to add to this as/when I find resources:
- Blender Cheatsheet - Very useful to have nearby when you’re trying to remember all the keyboard shortcuts!
- The Blender.org wiki has a lot of useful information, including a set of tutorials.
- The official Blender page also has a set of tutorials, which seem to be different from the ones on its wiki.
- CG Cookie has a fantastic Blender section. Their tutorials range from from 5min introductory videos, to detailed tutorials on modelling, animation, lighting etc.
- Via CG Cookie, I found this 2-part tutorial for how to create a teddy bear model and texture it. The video on CG Cookie seemed broken, so here are the Vimeo links: Part 1 (Creating the model); Part 2 (Materials/textures).
- “Blender 3D: n00b to pro” looks like a very useful resource on wikibooks.
- blendtuts has colour coded tutorials, from beginner (green) to expert (red).
- 3D Buzz has 58 downloadable tutorials (thanks @AdamPidgeWhite).
Only a short list for now, but those are a good starting place. If you know of any other good resources that I’ve missed, please let me know, and I’ll add them!
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:
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…
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.
- 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.”