Rarebyte DevBlog

Two weeks have passed again – which means, I have to write a new dev blog entry – this one. At least I try to write a new entry at the end of each sprint. This time, I am a bit late to the sprint end party, because the sprint has already ended last Friday, but I just couldn’t manage to write up what has happened in the last two weeks.

Before I go into detail about that, if you are new to this blog, and want to catch up, here is a handy list of all previous episodes:

• Episode #0 – Time Estimations
• Episode #1 – Let’s Discuss Discussions
• Episode #2 – UI Madness
• Episode #3 – Polish, Polish, Polish

Coming Up Next: gamescom

The main reason for being very busy these days is gamescom of course. We have been attending this event for about 10 years now, and almost every time we were part of the Austrian booth in the business area, together with a few more Austrian development studios and companies. This year things are a bit different, as we have another booth in the entertainment area – at the Indie Arena Booth.

New Trailer

As we are currently preparing the We Are Screwed! Steam page, we have updated the game’s trailer with our all-new art style. We haven’t really made the video public on our YouTube channel yet, so here is a sneak peek.

Usually, I would pick one topic relevant to development/production of a video game, and write a few thoughts about it, or give a few insights on how we try to handle things. But it’s right before gamescom, and everything is very fragmented – a lot of things to do here and there, just to make sure we are prepared as good as we can.

In a way, this entry reflects this fragmented nature – as you can see, I’m hopping from one topic to another one. Let’s just talk about a discussion the team and I had a few days ago.

Naming Items/Modules in the Game

“Let’s add funny and hilarious names for everything in the game!”

Anonymous Game Developer

Depending on your game, its genre, and style, you definitely want to set a tone supporting all of that with everything you add to the game. Names for items are no exception to this. If your game is supposed to contain a lot of humor, of course you want hilarious names for your items – like we want for We Are Screwed!.

Funny names, wordplay, and puns – that’s what I was born to do! Image everyone else now facepalming, or just walking away with the head-shaking of disapproval.

The best strategy is to write something where those who get the pun will find it hilarious, and those who don’t, still get some information out of it, e.g. such as in how this item works, what its nature is etc. You have to be aware of cultural differences as well. It could be the case that you find something very funny, but it is actually offending someone else.

…but what if there are people who like to be offended?

Still Anonymous Game Developer

Let us take a look at a discussion we had for We Are Screwed!. In the game, we have so-called ship modules – those are items that you can put into slots on your ship. Some of those you can operate directly, such as turrets for example, while others give you a passive boost or enhancement. There is a ship module that we internally called “Push on Damage”, and what it does is exactly that. Whenever your ship takes damage, it will create a shockwave pushing away (and damaging) everything around it.

Because “Push on Damage” is not a very catchy name, we were discussing potential names. We wanted something that reflects its behavior, in a sense of “what you are doing to me, I will do to you”. Here is a list of what we came up with, and pros/cons.

• Inverse Damage Recuperation Device
  Pro: Very technical and twisted, as it was developed by a mad scientist
  Con: Too long as a title – this is never going to fit well in the UI
• Roland for an Oliver
  Pro: It’s a saying with the exact meaning of what we wanted it to be
  Con: No-one knows this saying, especially not non-native speakers
• Tit for Tat
  Pro: Also a saying with the exact meaning of what we wanted it to be
  Con: Well, you don’t want to name anything with “tit” in your game – no, you don’t
• Anger Vent
  Pro: Sounds weird and funny
  Con: Does not convey the exact functionality of the ship module
• Favor Returner
  Pro: It is the exact functionality of the ship module, and it expresses something bad for your enemies by using a positive word such as favor
  Con: We are all ears – you tell us!

Stay tuned for more insights coming to this dev blog after gamescom in two weeks! And if you are attending the event, drop by and say hi at the Indie Arena Booth!

To be continued…

In the meantime, please feel free to reach out via:

• discord.gg/rarebyte
• @RarebyteGameDev
• twitch.tv/rarebyte
• fb.com/rarebyte
• @rangermann

It took us 40219 coffees to get this far.

Welcome back to yet another episode of our We Are Screwed! development blog! If you are new to this blog, and want to catch up, check out the previous episodes:

• Episode #0 – Time Estimations
• Episode #1 – Let’s Discuss Discussions
• Episode #2 – UI Madness

In some industries, especially summer is the time of the year when everything is a bit laid-back – some call it the summer slump, the silly season, or they just say, “nah, it’s too hot to do this right now”. All perfect and legitimate reasons to get away from work, and recharge batteries. For us, summer is typically divided into two phases: Before Gamescom, and after Gamescom. Before Gamescom means we have to work hard on what we want to show there, after Gamescom typically means taking a deep breath before getting things ready for the next local event, the Game Dev Days Graz.

So after dealing with a lot of UI tasks and UI-related issues in the last sprint (see Episode #2), we actually wanted to finish implementing the boss for the first stage of the game, and then do some polish work to get a build ready for both Gamescom and showing it off to publishers and potential partners.

My original idea was to write a new dev blog post at the end of each sprint, but I have to admit, this time it didn’t work out. We wanted to do a one-week polish sprint which ended up becoming more chaotic than expected, as unforeseen events and delays hit us. When we realized this mid-sprint, we decided to still close this one-week clusterfuck of a sprint, and then continue with a two-week sprint dealing with all the leftovers that still need to be done to get a build ready for Gamescom. So this entry here covers those two sprints.

The goal of the last three weeks was to create a build of the game where the complete first stage is playable, which means content for 6 levels including the first boss fight. As of writing this, we are still not done. Why? Partially because we were caught up with some bug fixes in other areas of the game which delayed the boss level again, but also because we are never satisfied with what we have.

Before diving into details, let’s quickly take a look at what we are aiming for at Gamescom. This year, we are exhibiting in both the business and the entertainment area. As usual, we are part of the Austrian booth in the business area (hall 4.1 B51/C60; make sure to drop by for a strong Austrian coffee!), where we have our business meetings. On top of that we will be showing We Are Screwed! at the Indie Arena Booth (hall 10.2 021G-031G) in the entertainment area (make sure to drop by for awesome loot – no spoilers here!). There are tons of awesome games from indie developers there, check out their trailer:

Polish, Polish, Polish

The problem with polishing a game is that you always find something to tweak, change, or add. You think you can’t release anything before it is really, really polished. You are going to hate me for this, but I’m going to say it: There is some truth in that.

I still want my game to be perfect!

A developer about to release his/her first game right before turning 100 years old.

What we are actually talking about is getting priorities right, and that’s one of the hardest things in game development. You need to identify the very core of your game – because that is what really needs to shine, and what you really need to polish. Everything else is secondary.

As developers, we also need to be aware of this trade-off in overall production quality. Often, you would set yourself a goal for a target level of quality. This sometimes means you start with a certain art style, for instance, and then you are stuck with it. Having a half-baked game does not work, you have to pull through. And that’s exactly what produces a lot of delays – estimations are too optimistic, strange bugs appear, unforeseen events occur, and you miss deadlines.

The truth is, when you look at your game, you will always see things that look odd, wrong, broken, or just plain ugly. But that’s what you see – and it makes perfect sense. You have been developing the game for so long, you see and play it every day (if not, then something else is wrong), so of course you are aware of all those little glitches. The trick is to let others play the game. Just observe, and then ask yourself the following questions:

• What is the players’ experience regarding the core loop/minute-to-minute gameplay?
• What is the first thing in the game they don’t get the hang of?
• When do they stop playing the game? Can you identify the reason?
• What are the areas in the game players are most interested in?
• Which game mechanics and strategies are used more often than others, and why?
• Was that tiny little detail on the mesh on the backside of that decoration object really that important?
• … and the most generic question you can’t ask your friends: Are players having fun?

We’d love to hear more about your experiences and thoughts on the topic, both from the perspective of delopers and players. Leave a comment and tell us your story!

To be continued…

In the meantime, please feel free to reach out via:

• discord.gg/rarebyte
• @RarebyteGameDev
• twitch.tv/rarebyte
• fb.com/rarebyte
• @rangermann

It took us 40084 coffees to get this far. Don’t say you missed the Coffee Hammer 40k.

If you are new to this dev blog, and want to catch up, check out the previous episodes:

• Episode #0 – Time Estimations
• Episode #1 – Let’s Discuss Discussions

Development Update

Can you hear the roaring sound of the alpha? No? Well, that’s because there is no sound in the game yet. However, gameplay-wise we are getting there!

We Are Screwed! features a unique split-screen view that shows you both the inside of your spaceship as well as what’s going on outside the ship. For a long time we had a rather polished inside scene right next to a more or less blocked out version of the outside/surroundings. In the last couple of days, things finally started to come together, check out this sneak peek:

We tried surviving the hottest days of the year (so far), and we partially succeeded. Could you all comment “I’m ok” so that I know for sure? We don’t have AC in the office, but luckily, a big metal fan was there to help out – as can be seen in last week’s stream recording:

As with every blog post, I wanted to choose a topic that we had to deal with during the sprint. First, I wasn’t sure what to pick, but at one of our super rare meetings at the coffee machine, Felix strongly confirmed that we must talk about…

User Interface Madness

In the last two blog posts I wrote a lot about planning and time estimations. Let’s now come to the most underestimated type of them all: User interfaces. When you start planning a project, you typically have a ballpark figure in mind when estimating all the tasks. In almost all our projects, user interface is typically the thing that does not get enough time in schedules.

So I asked a few people on the team what they thought about estimating user interface creation…

Estimating the creation of user interfaces is the root of all evil.

Everyone on the team

But why is that? Let’s take a look at it step by step. Before starting the actual work on the UI, there is the situation were you have to block out a certain amount of time in your schedule. “Alright, let’s just assume 20 hours for this, it’s just this simple menu”, is something to be heard at that time. The dilemma is right there: You have no idea how the UI is going to look like, how the user interaction works in detail – hell, you don’t even have a mockup.

So someone on the team will start working on a mockup for it, eating up time from the original estimation. Most of the times, it needs a second iteration for getting this right. Next, maybe someone else starts implementing that mockup, and there comes the next issue: Mockups are never complete. They are always lacking something. Maybe there is this additional panel when you click on this button on the second subpanel of the third tab, or you realize that mockups are often just static images that do not show any animations, effects, fading, or timing.

Then, when you have the first version working in the game, you realize that it needs another iteration because it does not work as smoothly as expected, or some things are not clear to the player – and so you put yet more time into it. How much is now left of those 20 hours?

And so the new UI makes it into the actual game and is being tested for the first time. There is more feedback and more little details where improvements can be done.

It just takes so many iterations to get everything right.

It can help a lot to look at other games, and how they solved similar menus, HUDs, widgets, or UI panels. Sometimes you don’t have to reinvent the wheel. Also, make sure to playtest with fresh players who have not seen any of the previous iterations, otherwise they might be biased or used to what they were experiencing before.

Here is a magic rule of thumb for estimating UI tasks. First, think of all the steps and number of iterations it is probably going to take. Be aware of the fact that mockups are never complete, usability needs to be discussed once you created those mockups. Break down UI work into granular tasks, don’t assume any hours before thinking about specifics and details. Ask yourself about the level of quality and polish you are aiming for. Think about the workflow and the people needed to actually create it – sometimes it’s not just one person, but a lot of people involved as you have to deal with mockup creation, implementation, animations, and effects.

Then, together with the team, do a conservative estimation of the work to be done, and correct it as follows:

• Optimistic developer? Double the estimate.
• Experienced developer? Still double the estimate.

We would love to hear your thoughts, and discuss your experiences with creating or dealing with user interfaces – feel free to reach out, write a comment here, or hang out with us on our Discord.

And now, for the fun of it, here is a comparison of how the options screen evolved in We Are Screwed!

• 

• 

• 

Oh wait, why is the “Apply Screen Settings” button highlighted in green here?! Oh no, we need another iteration – this needs to be fixed!

To be continued…

In the meantime, please feel free to reach out via:

• discord.gg/rarebyte
• @RarebyteGameDev
• twitch.tv/rarebyte
• fb.com/rarebyte
• @rangermann

It took us 39870 coffees to get this far.

Welcome to another episode of our We Are Screwed! production blog. If you missed the introduction, here is episode #0.

Development Update

We work in two week sprints. Typically. Well, wait, there are some public holidays, then there are people on vacation… so the current sprint was only running for 7 work days. Adding bridge days to the team’s schedule isn’t a good idea either, so sometimes sprints are just shorter.

As we are getting closer to alpha, of course we have been bugfixing a lot in this sprint.

Some of those bugs were discovered in the playtesting stream at the end of the previous sprint. It’s actually quite useful to create clips on Twitch as you encounter issues. Thanks to our nice community for helping us out with that!

If you missed the stream, here is a recording:

Play Austria

We exhibited the game at Play Austria in Vienna last week, and needed to decide which build to show there. So we evaluated the build from the previous sprint, and then prioritized issues and bugs to be fixed for the event.

It’s always a good idea to have an older build ready to use as a fallback (and you will have one once you manage to survive at least one event!), but aside from a rare outside screen/possible camera issue, using the latest one went well for us this time. We received a lot of great feedback at the event – thanks to everyone who came by to play We Are Screwed!

• 

• 

• 

Let’s Discuss Discussions!

Imagine you want to implement important feature A in the coming sprint. The team is confident that it can be done within just a couple of hours, and there is enough time left in the schedule. Should you do it? Well, it depends.

• Are all the prerequisites met to go ahead and implement this?
• Is the feature specified well enough, both technically and gameplay-wise?
• Are there any dependencies to be resolved in the same sprint?

What happens a lot, is that when discussing the tasks for the sprint, you are not exactly sure what the game design looks like in detail for a feature. Most of the time, you have a basic idea where you want to go with this, but the details may not have been fleshed out yet.

“Ah, let’s just discuss this when we get there, and it will still get done in this sprint, right?”

No. In almost every instance, there are multiple people involved in this discussion and the decisions to be made. If you have the discussion and the implementation planned for the same sprint, it is very likely that it is not going to be implemented. The reason for this is very simple: Discussions tend to be postponed a lot, because people are busy. They are working hard on the game, fixing bugs, and adding great pieces of art. When asked to start a discussion, the answer is always something like in a couple of hours, tomorrow, or even next week.

What we are trying to do here, is to have discussions scheduled for one sprint, but the implementation of its outcome in the next one. That enables the team to move around the actual date of their discussion meeting to their liking – and it’s not an issue even if it’s right before your TGIF round of beers.

However, there is another important lesson to learn about discussions: You never know how long they will take. It might be the rare case to decide something within five minutes, but in general, you don’t know whether it will take you one hour, two hours, or maybe six. At first, we tried to plan discussions as tickets, and give them our best guesstimate. It just didn’t work. So we changed the workflow here a bit, and while we still have tickets in our system for discussion, there are no time estimations on those tickets. They only act as reminders – and it’s a good thing to be reminded that we need to discuss something like the stage 1 boss, right?

We also don’t log work hours to those discussion tickets, because this would tamper with the burndown chart. The idea is to log discussion hours somewhere else (we do this via Toggl), so that you are able to reevaluate the overall discussion vs. work percentage. Only schedule a certain percentage to development work, and leave enough time for discussions. Taking a look at previous sprints’ actual percentage will help you plan for the next one.

To be continued…

In the meantime, please feel free to reach out via:

• discord.gg/rarebyte
• @RarebyteGameDev
• twitch.tv/rarebyte
• fb.com/rarebyte
• @rangermann

It took us 39684 coffees to get this far.

At Rarebyte, we are always working on multiple projects at the same time. Some of those projects are contract work, while some others are our own IPs. Developing games can be a risky business, and that’s why we – and probably a lot of other studios – chose this strategy for surviving as an indie studio.

After more than 12 years in the industry, we have to announce that…

…is the title of our latest game!

Yes, I might have used that kind of introduction (with a distinct pause) at the Subotron Live Pitch event which we won last year – and thanks to the organizers, we will be showcasing our game at the Indie Arena Booth at this year’s Gamescom.

We Are Screwed! is a space action local coop game, and we have been working on it for about 10 months now. If you have been following its development, you might have already seen it in one of our playtesting live streams (or a recording on YouTube).

You are the rag-tag crew of the worst space vessel in the galaxy, but that is exactly why you are destined to boldly go where no one has screwed up before!

The game was originally a prototype by Felix, one of our programmers, who created a first playable in his spare time, which we then turned into a Rarebyte project, and added more people to the development team. There has been a long period of prototyping, experimenting, and pre-production.

While it is a good thing to be able to experiment a lot before moving to (full) production, it can be a bit chaotic when trying to coordinate everything for an upcoming deadline, playtest builds, or for showcasing the game at an event.

As we are now getting closer to an alpha version of the game, we decided that this is the right time to add an internal producer. I was taking care of the business side of the project before, and also streaming our playtesting sessions (sometimes with great guests in our studio, sometimes with the nice people from our community), but from now on I will also be responsible for internal producing.

As We Are Screwed! is our own IP, we will be able to share a lot about the game, its development, and the overall process of creating it. We’ve now started working in two week sprints – and just by changing the process, the typical problems come up.

Time Estimations

“Give me 2 days!”

Scotty

Although we might be repairing and pimping space ships in our game – just like Scotty! – getting time estimations right is a very difficult task. Motivation and optimism are good ingredients for development in general, but really bad ones when it comes to planning and schedules. Estimating tasks is nothing you will get right from the very beginning. It relies on both the time estimation skills of the developer looking at a task, and the producer gauging the developer’s estimation.

Good questions are:

• How much overhead will there be for discussions?
• What is a good target work load percentage for a developer?
• Is there any time scheduled to be used up by unforeseen events (e.g. sick leave, or an annoying crash bug)?
• What are the dependencies of multiple tasks to be done by multiple developers?

All those questions cannot be answered in the first sprint. It needs time, data, and (re)evaluation to be able to get better at estimating tasks and making schedules. It really is a continuous process.

In the coming weeks, I will create more posts for our freshly revived dev blog, and hopefully write down some insights we gain during the development of We Are Screwed!

To be continued…

In the meantime, please feel free to reach out via:

• discord.gg/rarebyte
• @RarebyteGameDev
• twitch.tv/rarebyte
• fb.com/rarebyte
• @rangermann