Organization Advices

Organization Advices is part 3 of the Advices series. Here are Part 1: Design Advices and Part 2: Art Advices.

For this entry, I just want to write tips that I found helpful throughout the project, to organize myself better, to save time or to avoid potential problems.

1- Prepare your tasks for next day. At the end of each day, I do a quick recap of what I’ll be doing the next. This way, I’ll start right away the following day. It’s like that cooking phrase, Mise en place: Before starting, you should have everything ready and prepared. This is how I prepare for my next work day.

Additionally, knowing what I have to do gives me a few extra hours to define the finer details (and sometimes even get a new cool idea). It’s like my subconscious keeps working on it.

2- Have visibility on future tasks. It’s really easy to go out of scope in game development. Big projects with multiple offices working together require more specific planning, milestones and deadlines. But small indie teams might be tempted on just “going for it” and only organize daily/weekly tasks, momentarily disregarding the long term.

I find that if I don’t have visibility on what’s left to do, I don’t have a rough idea on how long it might all take. And I cannot make any adjustments this way. Considering how many projects end up out of budget, it’s too risky to disregard planning. Seeing the overall picture helps you prioritize tasks. What’s mandatory for release? What’s unnecessary and can be cut out? What’s nice to have but perhaps can be left for a post-launch update?

You don’t have to fully lay out every single little thing you need to do. If it’s easier and you don’t have the time, you can make “supertasks”, with big chunks of work/implementations. Breaking tasks into smaller chunks does help with time estimations though. This will also help you pinpoint bottlenecks or difficult technical challenges. And part of everyone’s jobs is to identify potential delays and issues, to sort them out before they become a problem.

3- Home vs Office. There are many differences between working from home or in an office, and it’s impossible to recommend one or the other. It depends on too many factors, including team members locations (not always in the same city or even country nowadays), budget to maintain an office, etc.

The important point to make here is that you should be aware of both the pros and the cons of working one way or the other. Most video game developers have worked in an office at one point or another, but many discovered work from home when the pandemic hit. Because most have experience at office and I was already working from home from long before that, I’ll focus on work from home.

There’s no denying you save time commuting. That, and the fact that you can work with just your underwear on are probably the best perks.

But on the other hand, there are several potential dangers you must be aware of:

– Because you don’t have to go to work, you might end up staying at home for days at a time. Personally I don’t have a big issue with this, but I know several people that have suffered this when pandemic lockdowns forced them at home for long periods of time. So be careful about this, make sure you go out, see the sunlight, get fresh air, meet people, do other activities. Especially if you live by yourself.

– When you’re at home all day, it means that you’ll probably end up having most of your meals at home. This means more dishes to do, more things to clean (even worse if you cook like myself). It’s quite crazy how much dirty a home can get when you’re there most of the day (vs being all day out and coming back in the evening).

– If you have kids, you will get a lot of small interruptions that you’d never experience at the office. If you’re placing objects on a level, probably not a big deal. But if you’re in the middle of coding something complicated, interruptions are going to affect you. These disturbances could also come from your significant other, parents or friends that know you’re home, or simply things that break in your house and demand your attention (when working at the office you have to wait until weekends, when you’re at home it’s different because you have more flexibility). If you’re having trouble with this, try working at odd hours, when everyone is asleep. If you’re a morning person, try waking up 2-3 hours before everyone else. If you’re a night owl like myself, then push through the night and only go to bed when you’re tired (assuming you don’t have any commitments in the morning). These hours will be your most productive, as there is really no one around.

– Be very careful with losing time just browsing the internet (aka your favorite website or social network). When you don’t have other people looking over your shoulder, no matter if it’s your boss or coworkers, things change. A lot. Only people with a lot of self-discipline can maintain the same work behavior at home as if they were in an office. I always thought myself as pretty good at this, until I realized the truth one day that I recorded a bit of Gravitators for a bug, but then forgot to switch it off. So then I had a 2 hour video recording of my screen while working. I checked it out of curiosity, and saw myself alt-tabbing a lot of times while waiting for Unity to build or to just go into play mode, and then staying unproductive a lot longer than I should have.

4- Learn to multitask. You might have experience multi-tasking already. If you don’t, this is a skill that you should learn. You won’t always be able to fully work on a single thing each day, especially if your team is small or you’re doing solo dev. You should be able to easily jump from level design to coding to art to planning to social media and be back to where you were before.

You might find multi-tasking slowing you down, but don’t forget you taking care of many different things at once (things that do require constant attention).

5- Get used to being out of your comfort zone. Unless very well-funded, indie teams have role overlaps. If that is your case, then you will be stepping out of your comfort zone often. There’s simply no one else to do that job. Big companies can afford having very specialized roles in their organization. But not indie devs.

So make sure you’re ready to do stuff you’ve never done before, knowing that you are still expected to achieve professional quality anyway.

At the same time, know when you’re completely out of your element. That’s when you should seek a third party to solve the problem for you.

Let me give you a couple of examples:

A- We had to create a trailer for the game. I did browse around for trailer creators, but I had my doubts. Gravitators isn’t easy to play (especially for trailer material), and a newcomer wouldn’t know the game as well as I do. If I hired someone, I would have had to create a custom version of the game, explain all the levels, all the ships, how things work, what makes the game tick, etc. etc. It felt like a lot of work.

On the other hand, if I did the trailer myself, I’d need to figure out what makes a good trailer, record all the scenes, and compile them into a single video with music. I’m by no means an expert on video editing, but the editing itself isn’t the complicated part (I’m sure most of us have edited a video at some point during our lives). It’s deciding what to show and how to show it. And while it did seem like quite a lot of work as well, I was willing to give it a shot.

First, I watched a bunch of trailers. The best way to start learning a skill is seeing how others do it, dissect it, and see how each part goes into the whole. I also wrote down what I liked or disliked about each, to keep in mind for our own trailer.

Then, I searched online about what makes a good trailer. There are plenty of guides and DOs/DONTs by experts, so I won’t get into these details.

The main conclusions I came up with after research were:

. Trailers must show your gameplay. There cannot be any doubt on how the game plays. Better if the trailer is mostly or all gameplay, and focused on what the player will be doing the most. Cinematic trailers are reserved for very story driven games, or popular IPs.

. The sweet spot for trailer duration seems to be between 1 to 2 minutes.

. Start showing gameplay right away. Nobody is interested in seeing what your engine is or looking at the logo of your company for several seconds. Save that stuff for the end. Before reading about trailers, as a player and a potential buyer, when I checked a trailer, if it had these slow logo intros I already directly skipped ahead towards the middle of the trailer video, potentially missing interesting stuff. And I know I’m not the only one. Why risk this as a developer?

. Trailers need to tell a story within the video takes you show. It’s similar to good TV Ads. Gravitators Trailer follows the following story:

– (0:00) Intro showing you fly and carry objects, making a connection to classic retro games.

– (0:16) Sudden change of music introduces a lot more mechanics, showing that the game is a lot more than the classic games. We also display the 4 playable ships using different power ups in different mission types and environments. While showing all this variety, there’s a bit of feeling of innocence and adventure here.

– (1:02) Introduction of enemies and problems you could face while playing the game. Show that the game can get tough. Pressure starts to build up as we see player ships getting into trouble, things get more serious.

– (1:18) We slow down the pace and show a couple of slow, agonizing deaths. Hope seems lost, enemies are overwhelming.

– (1:32) At what appears to be yet another death, a power up is activated, reviving the player ship and bringing out hope, followed up by the special attack of another ship, that kills all enemies on screen. Time for payback now, showing cool abilities and attacks and doing a lot of damage to enemies. The trailer ends with a sense of victory.

– (1:52) Game logo and name, then Company logo and name.

With the story structure known, watch the trailer and see how it all comes together:

You probably noticed that the “trailer story” is carried by the amazing trailer track we had, done by Cristian D’Agustini. Music is the invisible ingredient that binds it all together. The end result is good in my opinion, and I’m not sure it could have been done a lot better by a hired trailer professional.

The type of story you tell will depend a lot on the game’s genre. There isn’t a single cookie-cutter way to create a successful trailer. But the takeaway here is that you should find your trailer angle, and take your viewers through a small story within the confines of your gameplay.

. For action oriented games, short camera shots seem to work best, to keep things moving and hold interest. When you don’t do this, the trailer seems a bit too static. Additionally, I discovered that camera changes works best if they are synchronized with the music.

. It’s usually better to hide the UI (unless crucial to the gameplay), to keep video focused on graphics only and avoid being too cluttered. You can always record a full gameplay video footage with UI later.

. Choice of music and sound are very important a well. For our trailer, we decided to remove sound effects because we felt it would have clashed a bit with the music. Other games might work better with only sound effects and voice over instead. It really depends on what you show on the trailer and how your game is. Music can enhance your trailer or ruin it. If you watch many gameplay trailers before doing your own, you’ll start noticing when the music just doesn’t fit.

. Don’t be afraid to do custom levels/scenes to fit the narrative of the trailer. You must show the essence of what the game is about, not specific levels that players will find in the game. Several of the Gravitators trailer scenes do not exist in the game, others were heavily modified, and others are exactly what you’ll experience in game. Whatever you show must serve the telling trailer. Obviously don’t promise things that players won’t be able to do. If you show the player character flying through the sky and then that never happens in the game, you’re going to get a lot of upset players. What I mean is that you arrange your game objects a certain way, so they shine their best when you display them on your trailer.

B- Soundtrack and Sound Effects. On the other side of the coin, we have Sound. Only 2 members of our team had a bit of experience composing music, but none professionally. And none of us had any experience with Sound Effects (didn’t even know where to begin).

We tried some quick track ideas with somewhat OK results actually, but we realized that it was a full time job. We couldn’t keep up with development while at the same doing the music.

Sound Effects took very little research to conclude it was out of our league. We checked free royalty sounds, but apart from a handful of them, none really fit well in our game. We still got a bunch of placeholders sounds, so we could already implement them in game already, waiting for the final ones.

But if we wanted professionally sounding audio, we needed to hire professionals. Luckily, outsourcing Sound is probably within the easiest to do in game development.

So in the case of Trailers, we decided to step out of the comfort zone and get it done ourselves. But for Sound Design, we correctly realized it would have taken us too long to achieve a good result, so we decided to hire someone to take care of it for us. Which takes me to the next point.

6- Choose the right time to hire help. It cannot be too early, nor too late. I’ll use Sound Design as an example, but it can apply to anything:

If you place the order for Sounds too early, there might be features not implemented yet, and parts of the game will probably be modified, requiring you to do another round of Sound Design. This perhaps isn’t a huge deal, but if you’re tight on budget you’ll be wasting money and resources with requested sounds that you won’t use in the end. Additionally, the Sound Designer might be busy later on, and you’ll have to wait for availability.

If you do it too late, you’ll be putting pressure on the Sound Designer to finish fast, potentially damaging quality, or you might be late on launch because you’re still waiting for the Sounds to be finished.

So you need to decide when it’s the best time. I’d say the time for Sound Design is right when you’ve finished adding new content for the game, but still have a lot of bug fixing to do. But it depends a lot on how many sounds you plan to implement. Gravitators has over 20 tracks and hundreds of sound effects, so we couldn’t wait until the very end to request them.

What you should be doing since the beginning is identifying reference music and collecting contacts.

I have a Gravitators playlist on YouTube and Spotify, where I just stored all the music I felt could work for the game. I started it even before starting with Gravitators (and now I’m currently doing another playlist for future games). So when I have the Composer chosen, I just share the playlist and show him what we have in mind. Likewise, we send placeholder Sound Effects to the Sound Designer. We grant them total freedom to work with, but we believe that, as clients, the better we explain what we have in mind, the easier the work will be for everyone.

As for contacts, there are plenty of Sound Designers out there with wildly varying prices (from free to thousands of dollars), so finding the right one for you might take time. Before contacting anyone, I had gathered a list of 40 Sound Designers, sorted out by how well I thought they fit with our project. In the end, I only contacted (and hired) my 2 favorite ones: one for the Music, another one for Sound Effects.

If you’re browsing for Composers or Sound Designers, I recommend you check all music platforms (YouTube, Spotify, Bandcamp, Soundcloud, etc. – their algorithms always suggest similar tracks from what you’ve been listening to) as well as specific platforms to contact or hire them: Soundlister, Fiverr, etc. Reels will help you decide if their type of music is what you have in mind.

7- Right tool for the right job. Before starting a project, it’s always important to do a thorough research on tools that might help you move faster. For example:

– What are you using for planning and task assignment? Many devs like working with Trello / Kanban cards. Others use good old Excel or Google Sheets to take advantage of the multi-user editing. There are a plethora of software tailored for game development, from very specific for doing 1 single thing to very broad to do many things. Browse around and pick the one most suitable for you.

– How about bug reporting? Do you use a bugbase or you’ll keep the bug records and status someplace else?

– Same for coding, drawing, modeling, etc. You have plenty of free and paid options today, so you should be able to find one that fits your needs.

– Don’t be afraid of pen and paper. I found that doing the level design on paper and then “transfer it” to Unity was much faster than starting directly on Unity. I could quickly spot and modify issues, add notes, change things around, etc. If I would have done it all directly on Unity, I’d have taken twice the time if not more.

– Assets. Unity Asset Store has a ton of stuff. Before delving into deep waters by implementing things you have zero experience with, try searching for what you need online and on the Asset Store. There are plenty of paid and free options (or tutorials) nowadays that work with most engines, and it’ll help you save time and focus on your game. You should always calculate the cost of the asset vs the cost (time) of doing it on your own. You’re not a better game developer by doing it all by yourself, you’re just slower.

8- Playtest throughout the project. This doesn’t mean to just send the game to people and wait for feedback.

First and foremost, you and your team should all be playtesting the game. It’s common to get wrapped up in features and bugs, and only test specific parts of the game as you work. But you should also be playing the game. Not only you’ll be finding new bugs, but you’ll be also fine-tuning the most important component of a game: the fun.

When you start sending builds to people, start with a reduced number of them. It is obviously better if you know them personally, if they play games on a regular basis, and even better if they like the genre you’re working on. Ask them beforehand what you want them to check. This can go from very simple questions (is it fun? Does it perform well on your computer?) to more complex (difficulty progression, preferred weapons/items), or even more subjective (art style, music, story). Alternatively, you can just send them a build without any notes, and just ask them to tell you what they think. But I find it better to create some structure on their minds by telling them what we’d like them to check.

As you expand the circle of playtesters, you could consider adding some A/B testing if you’re not sure about a specific feature or if you have doubts which is the best way to go about something.

Once you feel the game is polished enough, you can put a demo on Steam or Itch. Be prepared to receive harsh comments though. Not everyone will like your game. And people can be rude sometimes to random strangers on the internet. In those cases, just “filter out” the rudeness, see if there’s any useful feedback to improve your game, and thank the player for taking the time to write the suggestions (or problems found). After all, that’s what you were looking for when you put your game out there for players to try. You got what you wanted, so the rest doesn’t really matter.

9- Keep records. This is something I’ve never seen suggested before I started out, but would have been helpful. I’ll start with the obvious ones that everyone should be doing already, but then move down to the ones nobody talks about:

– Planning, Tasks, Bugs. We’ve spoken about this already, and I don’t really see how it’d be possible to do game development without keeping a record of them.

– Code and Assets. I don’t think there’s anybody anymore not using some sort of versioning system with back-up / online capabilities (GitHub, SVN, etc.), but if you’re not, start NOW. You don’t want to be those people asking in forums for help because they lost their whole project due to lack of back-ups and broken hard drives.

– Expenses. It will be impossible to know if you’re making money with sales if you didn’t keep a record of your game dev expenses. Additionally, if you’ve set up any form of legal entity this is a must anyway.

– Post Launch Ideas. You’ve planned everything until launch. Great. But how about the future? Start writing ideas for potential DLCs, free expansions, major improvements and additions, etc. etc. all in 1 file. When you’re near your deadline, you’ll be thankful you have this.

– Keep pics and videos to document progress. Especially when implementing specific features. Not only this is a great morale boost for the team (“see how far we’ve come this year”), but time to time there are Before & After challenges in social media that are cool to gain visibility. Additionally, if you’re ever writing a blog or an article (like yours truly right now), they will be useful to show improvements. You can also save funny bugs or weird behaviors, those are always cool to post online too.

– Write Post Mortem notes and team feedback from day 1. If you want to improve, identifying problems during development and suggesting solutions is a must. But if you start thinking about feedback after you’ve finished the project, you will most likely come out short. When you spot a problem, even if you fix it during the project, write it down. Idea is to avoid the problem entirely next time around.

10- Hardware. Unless your game is very lightweight, don’t go cheap on hardware. Take it as an investment. Projects can take several years, and get heavier and heavier over time.

You will be building your game an infinite amount of times throughout development. Set up your work PC to be as fast as possible to do all this.

On the other side, keep in mind that you will also need to double check minimum requirements for your game, so don’t get rid of your old PC just yet.

ORGANIZATION ADVICES

Follow us: