Grhyll – Page 2

Set a date

Today I’m gonna talk a bit about project organization and planning. I have been working as a programmer at The Game Bakers for something like 5 years now (I’m bad with dates), and if I’m still learning every day about coding, I am not very involved in the projects management and other marketing aspects of game developing. With Red Skies however (a personal project on which I work on my free time with a friend), I don’t have much choice, and I’d even go as far as saying that it’s one of the main reasons why I started it. I’ve read quite a lot of articles online, from very various sources, about those questions, but obviously there’s a gap between reading about it and experiencing it. Still, I find it interesting to see how other people deal with this kind of stuff, and that’s why I want to share my bits of experience (from a guy, keep that in mind, who didn’t release any game by himself yet).

So, “Set a date”, uh? When Foxbullbee and I started working on Red Skies, we didn’t have a very precise idea of the product we wanted, we just knew that we wanted to make a small and neat game. A two months long project, maybe three, nothing too fancy. Some months later, it had almost become the opposite: a pretty good idea of the game, a lot of features in the pipeline, and a very vague idea about a launch date.

At first we wanted to finish it (kind of) in the end of December, and release it (maybe) at the beginning of February. The problem every game developer has faced, though, is that when you reach 95% of the project, you get the feeling that it’s almost done, the pressure goes down, and yet you still have about 50% of the work remaining. And those 50% are not the main, sweet features the game is all about; those are the small annoying bugs that you didn’t want to fix immediately because they look vicious, the UI screens that are full of little assets that don’t require that much time individually and aren’t too fun to draw. A LOT of tiny details, polish, social integration, that, accumulated, give a huge workload. It’s also the marketing: releasing a game is nice, but without some effort, nobody will ever see it. And it takes time too.

So we sort of reached an impasse: the game was almost finished (in our minds, at least), but we didn’t work that much on it anymore (I mean, why would we, we didn’t plan to release it just the day after, and what’s left to do can be done so quickly before launch… you get my point). The issue is that if you don’t have a clear milestone, something that gives you a day on which everything has to be done, it’s easy to postpone. Just by not looking at the amount of various – yet so small – things that have to be done, you get the feeling that it will be easy and quick.

Realizing that, I opened a spreadsheet and started writing down everything I wanted in the game, classifying them among three categories:

– TODO: the core of the game (polished, including all inevitable elements such as analytics, monetization…).

– NTH (Nice To Have): it would be very nice to have on release but it’s ok if it comes later.

– V2: looks like a nice feature, but we’ll see later how things go.

Then, I tried to estimate the duration of all those tasks, having in mind that I would like the game to be released in one or two months. If at first I didn’t really care about the release date too much, as time came by I started to think that we already invested a lot of work in a “small” project, something that’s a training for us as well as a game for players. We hope the game will be nice, that players will enjoy it, but we don’t plan to revolutionize the gaming world with it, nor earning billions, so maybe it would be a good idea to release it someday and go on with another project (because it’s probable it won’t even earn enough to cover for the time invested).

So that was it. It was time to set a date, a real one; not an estimation, not a wish, but a great, final decision. If the game is perfect at this moment, great! If it’s not, well… great, too, because I’ll release it anyway. No game is ever perfect, and if you don’t stop at some point, you may work on it and polish it for the rest of your days (that is, until you’re not interested in this project anymore and give it up to start another one).

Now, having listed the features that were 100% needed in my opinion and assigned a duration to each of them, I arrived at 49 days or work. Even if I consciously overestimated most of the tasks, I know that there will be some unexpected difficulties, so let’s make it 60 days. And here is my date. I add one week for the approval processes on the various stores, and I take the most dangerous and scary step: I make the date public. I know there aren’t a lot of people (if any) that will look forward to it or even remember it, there won’t be a mad hype or huge expectations, but it doesn’t change anything: the date is set, and I am now bound (by myself) to respect it.

Of course, all of that was decided in collaboration with my partner Foxbullbee. Now we both know exactly the tasks we have to do (including those we forgot and will only discover two days before launch, because we set apart some days for them specifically – edit: localization, for example) and the time we have to work on them. I made myself a nice timeline with each task having a given set of days. I don’t know if I’ll exactly respect it, but at least it gives me a way to have a precise following of my work, if I’m late or ok, or even if I will be able to add some of those Nice To Have features in the first release because I was so fast and talented thanks to my precious and wonderful timeline.

So if you’re working on a small project similar to mine, maybe it would be a good idea, once you have a nice working prototype that gives you a precise enough idea of where you’re going, to set a date. Of course I wouldn’t recommend doing that right at the start of the project, even if you have a good idea of what you’re planning. However, once you’ve find the core of the game, make decisions. And if really you happen to think of a new feature that really is SO good you can’t do without it, well, nothing stops you from changing your plans.

On the day of writing this, it’s been one week since I did that, and I was far more efficient in this week than during the last ones! I have finally created my Apple account, I have added leaderboards for iOS and Android and created the apps on the two stores, and I ended the minimal levels and bosses amount we aim for. If I hadn’t made that list, I don’t think I would already have started looking in those social tasks, which aren’t too fun to work on. Now that I have, I find myself one week early on my schedule (yes, I overestimated a bit, but still, 200% more efficient, that’s motivating!), and I know I’ll be able to add some NTH features.

I realize that not everybody works the same way, but I’m quite sure that we all need goals to make progress; and in most cases, I think that precise goals lead to more efficiency. So take some decisions, and stick to them (or try very hard until it’s obvious you should switch)!

And if you’re curious to see how it turns out for me, well, take an appointment to March 24th to see if Red Skies makes it!

SmallMahyemCompressed

For more articles, you can follow me on Twitter, Facebook or subscribe to this blog.

Reducing memory allocations to avoid Garbage Collection

In this technical post, I’m gonna talk about optimization, and specifically about memory allocations in Unity.

Disclaimer: I’m in no way an expert in this area, and you should take anything from this article with caution, as it may not be perfectly accurate, or there may be better solutions than the ones I give. Let’s say it’s a basic overview of tips about reducing allocations.

Second disclaimer: Some methods are here to reduce allocations, but it sometimes goes against speed performances (reasonably). Just choose what you’re looking for; it is for example more important on a mobile app than on a desktop game.

Short introduction

Working on my mobile game, I didn’t care too much about performances or allocations (I usually try to write clear, flexible, readable code without doing premature optimization) until I faced issues on device. I began with some obvious fixes, like packing sprites to improve compression, which made the game a lot more playable. Still, there were frequent micro-freezes that were almost not noticeable at first, but became unbearable as soon as I took note of them.

After some digging and playing around in the profiler, I found out those were due to some line named GC.Collect. I knew what garbage collection is, but didn’t really think about it until now, since it had never been an issue since I learned about it in school. In my project, it can take up to 8.62ms (on my high-end pc), leading to 9.79ms needed for my behaviours updates on a given frame; I didn’t check on device, but it was enough to be seen.

From Unity doc: “When an object, string or array is created, the memory required to store it is allocated from a central pool called the heap.” And the GC.Collect, which can happen anytime, as soon as the heap requires it, empties this memory by collecting garbage, looking through all the objects to see if they are in use or not. This operation can take quite a long time if there are many objects, dead or still alive.

Since I use pooling for almost everything in my game, I couldn’t really imagine where those alloc came from (the place it shows up in the profiler isn’t necessarily related to what really caused it). So I began investigating about this on the interwebz, and here are some tips on mistakes to avoid and methods to track them.

Reuse

The first obvious thing to say is: don’t create “new” things once your game is initialized/your scene is loaded. For your prefabs and even for components, use pooling and immediately instantiate everything you may need later. It also applies to arrays, list and dictionary, for example in an Update function where you have to fill an array every frame. Create one when the class starts, giving it the expected size as parameter, then clear it when you need it empty, instead of recreating it. It will keep its allocated space, and you can fill it again without extra allocation. Those are often very small allocs, but if they keep happening every frame, they will eventually cost more than the bigger ones that happen less frequently.

If you have a method filling an array or a list, pass it as an argument of the function instead of making it its return value. Have your collection be a member of the class, initialized only once, then simply cleared and filled inside your method, so you don’t have to instantiate a new one every time.

The strings create garbage as well, even when you concatenate them, so if you have to handle a lot of text somewhere and manipulate it heavily, use a StringBuilder that will take care of those memory issues alone and avoid the creation of garbage.

In the same spirit, cache everything you need to check frequently. If GetComponent is supposed to only allocate memory in the editor and not on device, other functions like GetComponentsInChildren will never be good to use on a regular basis (which is obvious since it returns an array). So call it once if you need it, then keep the result to reuse it and update it if needed.

Best practices

Another well-known garbage creator is the foreach. Because of Boxing (I’ll let you look for it if you want to go in detail), a foreach loop used on a collection containing objects creates garbage, so just use a simple for loop.

Some basic methods or functionalities provided by Unity also generate garbage for weird reasons. The best way to track them is to use the profiler after encapsulating your code in Profiler.BeginSample(“SampleName”) / Profiler.EndSample(). Those sections will have their own line in the profiler, allowing you to find exactly what line generates garbage and finding those tricky allocs.

Vector3.Equals, for example, generates garbage; just compare the coordinates of your vectors one by one. Also, don’t use enum values as dictionary keys, cast them to int. There must be several other tips of this kind which I did not have to deal with, so be sure to profile until you find the very line making the alloc.

Finally, you can trigger the garbage collector by yourself by calling System.GC.Collect(). I naively tried to call it every 30 frames, so that the garbage don’t have the time to grow, but the thing is that garbage collection duration will take as much time whether it has a lot to clear or not, because it scales with the total amount of objects. The best thing to do (besides not allocating anything) is to call this at the right time: just before starting the gameplay, when the player pauses the game, during loading of cutscenes… In those occasions, the collection spike will be invisible to the player (but your code still has to be clean enough so that it doesn’t need to be called outside of those circumstances).

Limits

Sadly, some of Unity’s methods generating garbage can’t really be avoided without doing some programming weird tricks. I couldn’t find anything about some obvious “leaks”, like Text.OnEnable or OnGUI functions, which can generate quite a lot of garbage if you use them frequently.

Changing game state, reenabling the HUD… That hurts.

In those cases, if you don’t want to recode yourself the whole system, you’ll have to be smart about the way you call them. Maybe you could just put that label offscreen when it’s not used, instead of disabling it? Rather than calling Clear/Stop on your particle system when it’s not used anymore, store its end date when starting it (don’t check each frame if it’s still alive!), and if it went until the end when you don’t need it anymore, don’t bother clearing it.

There are a bunch of other methods from Unity that allocate memory on the heap, some of which you can bypass, some of which you’ll just have to deal with. Just remember that it’s not always essential to reach 0 alloc; if a function called once in a while generates some KB of garbage, maybe it’s ok, as long as it’s not every frame. Optimize wisely.

Some other perf considerations

To end this note, I’d like to point out some very easy optimizations to improve performances:

On the rendering side, there is a lot to do. Pack your sprites in atlases, use an uniform scale on all of them in game, don’t modify the shared material of only one instance. In my project for example, I used an additive shader to make the enemies blink in white when hit, but every time I did that, a new instance of the material was spawned, and the enemies couldn’t be correctly batched anymore. Instead, I added a white sprite of the hit enemy, and just enable/disable it when needed (which fortunately doesn’t have the same memory impact as UI.Text).

On the physics side, it can often be easy to optimize things as well, if you started with a naive approach. Check your collisions matrix, remove all unnecessary cases. Try to use less colliders if you have several of them on some objects, prefer circle/sphere colliders to square/box or capsule ones. If you use Unity’s UI system, disable the “UI Raycast Target” option (checked by default) on everything that doesn’t need it.

Don’t leave empty Unity callbacks, especially like Update or FixedUpdate: because of the way they are called, it can be costly if you have a lot of behaviours, even if there is no code in them.

Well, that’s all for today. Please get in touch if you see mistakes or inaccurate advices so I can fix it before more people read it!

If you liked it and want more, don’t hesitate to subscribe to this blog, or follow me on Twitter: @Grhyll.

Thanks for reading!

Red skies

Red skies big banner I’ll open this blog with a short note on the game I’m currently working on in my free time: Red Skies. It’s an infinite, side-scrolling, retro shoot them up destined to mobile platforms, set to be released on March 24th.

The checklist is quite classic:

Bullet hell
Tight controls
Big bosses
Power-ups
Upgrades
Accessibility options

I’m working on that with Foxbullbee handling the artistic side, while I do the code and level design. We started this little project around September, and of course, what was supposed to have a very small scope grew up slowly to reach its current state.

In the end, it’s gonna be a 6-months project, but keep in mind that we both have a real job beside, and that we only make progress on Red Skies on our free time. And who knows, if more than 3 people download it and like it, maybe we’ll do some updates, because you can be sure we already have a lot of ideas about things to add…

It should be published at least on Android (under the Weeky games account) and on iOS (under the 3-50 account), and probably on Windows Phone (but I still have to investigate this).

Red skies early gif — Short gif of the current state of the game. Yes, the Pause button is a placeholder.

I’ll try to update this blog once a week, with technical notes about Unity, design or production thoughts, and news about Red Skies or future projects. You can subscribe to my Facebook page or my Twitter to be warned when new posts come out. Don’t hesitate to give your feelings about this gif in comments!