Technical advices from our lead developer (formerly an app/web dev).
Disclaimer: This is a great text I took from Made with Unity blog.
Original post can be found here.
I decided to repost it, just so I know that everybody that follow us also get to read this.
LESSON 1. THINK ABOUT THE FINAL PRODUCT FROM THE BEGINNING.
Back when we started, we just wanted to make a demo of the gameplay, so we went for the basics implementation of the main character systems, like physics, inputs, behaviours, etc. for over 6 months. Before we knew it, and having over 2 levels already finished, we realised that we didnât have a solid architecture, there were no player states, no managers, no tools, and everything was a bit of a mess, so we took a step back and spent about one month redesigning our architecture. So basically we did the following steps:
We divided the principal functionality of the game in many controllers:
GameManager: Controls the principal connections of the game, the game manager knows the actual state of the game and gives away the responsibilities to other managers.
SaveManager: Controls the saving functions and loads the files from the cloud.
AudioManager: Controls the volume, also plays and tops the audio clips.
AchievementManager: Knows what achievements are unlocked and how to unlock them all.
NotificationsManager: Sends messages and works as an intermediary for sending messages through the game.
We also put some effort on creating âtoolsâ using the Unity Editor, this tools allowed us to test the game with certain ammount of coins, abilities, achievements, life, killed enemies and so on.
Word of advice: So before you get excited about doing that vertical slice and have some fun, you should design a solid architecture of how everything in the game is going to interact.
LESSON 2. THINK OF PERFORMANCE AND OPTIMIZE YOUR GAME THROUGH THE WHOLE PROCESS:
Initially, we used 3D low-poly models for most of the objects in Flat Kingdom scenarios, we that way we didnât expect to hurt performance that bad... but we were wrong. After the first part of level 1 was completed, the game was running dead slow in some computers, that and other problems led to change the 3D models for 2D sprites, so we had to reassemble the level again. This time performance was a lot better, but again, after finishing about 3 levels we realised we used huge sprites for the backgrounds and none of them where power of two, so they were not compressed, we had to change almost everything again.
(This is a GIF, watch it here)
Word of advice: Always try to optimize your graphic resources as soon as you get them, that way you wonât waste time and time in the later stages of development.
Here are some tips about optimizing your game that we learned through all the process:
The âProfilerâ, your best friend. Donât hesitate to use it as the first step in your optimization process.
The easiest way to optimize for us was looking again at the scripts, a lot of the ones we did in the beginning used algorithms that had unnecessary steps or loops, like we had algorithms where we initialize, find, create or destroy Game Objects, using lots of resources of the game. We realized that we could make better instructions in one loop, and discard others loops, and this improved the performance of the game. Â Also, we learned that some methods like FindGameObject(), SendMessage(), Enum.toString() are resource-heavy.
Use the memory wisely, in Unity we canât manually free memory, but you can make things easier for the Garbage Collector. We recommend you consider the fact that classes generate Memory Allocation when you are creating each one. We can use structs since they are faster than classes. If you donât know the difference between classes and structs, I recommend you this tutorial.
Always avoid using real physics unless your game really needs it, Real physics are heavy for processing, for example, at first we used real physics to move the player. At the end, we opted to change everything to Character Controller and simulate all the external forces.
Avoid moving static objects, this is heavy on processing too, Â if you are going to move an object, userigidbody. Since moving static objects forces the physics engine to recalculate the physical world all over again.
LESSON 3. ALWAYS BE AWARE OF THE TIME NEEDED TO CODE AND TEST EVERY NEW FEATURE.
This is our first baby, we want it fun and perfectly polished in every corner, so everything you add to the game implies loads hours of code and hours of testing. At some point we wanted more levels, more abilities, sidequest characters, NPCs, epic boss fights on each level, and spent one more year of development, of course we had to fix tons of bugs, and spent hundreds of hours testing we didnât plan, and time is money, maybe you cannot offer everything in your first game. But try to choose carefully between features and gameplay, always being aware of how much time you would need to spend.
LESSON 4. DON'T REINVENT THE WHEEL, IF IT IS GOING TO SAVE YOU SOME TIME, USE PLUGINS.
At the start we wanted to do everything by ourselves, the water physics, how we saved the data, the localization manager... then we realized that there were plugins already available in the Unity Asset Store that could simplify our coding process. We ended up buying some of these and saved tons of time, so before you try to reinvent the wheel, check out the Asset Store! Maybe somebody else already took the time to implement system to build some of the features you want in your game.
We recommend you the following plugins, from all the ones we used:
Platform Builder (We used this plugin to make all the platforms of the game).
Easy Save (Cross-Platform Secure Save data with Encryption).
Smart Localization (Easy to setup localization plugin).
Cinema Director (Easy to make in-game cinematics).
LESSON 5. ALWAYS TEST YOUR GAME WITH YOUR TARGET AUDIENCE:
At first, we made a couple of demos to invite people to come and play at the studio, it took us about 8 months to deliver our first decent pre-alpha, I mean, we were learning and doing, all at the same time, trying to build a game with complex dynamics, player physics, inputs, level design and so forth and so on. So the day to test that pre-alpha came, and we thought the game was going to be a bit hard but very user friendly... we were wrong, again.
Here you have a couple of early pre-alpha gameplays:
Flatman - Demo! by lady wasd.
We found simple things like jumps, secret areas, and the gameplay in general were not very clear and obvious and turned out to be a lot harder for our users, a couple of reviewers made Youtube videos and they couldn't finish the first level! Since then, we tried to test with people every time we had a new level or a new feature, so while they played we were in the back watching their movements. Looking out and taking notes of every point in they had trouble with. In the end, the game turned out a bit easier but a lot more user friendly. We tested our latest builds in 3 events in Mexico during 2015, and lately at PAX South and the GDC, in conclusion, we can say the users understood the mechanics and the general game concept much faster!
Thanks Gustavo for sharing your knoledge and making such an inspiring text.
