Are We Screwed? Episode #1

Curious what happened last week? We Are Screwed! Also, let’s discuss discussions!

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

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.

Hunting a bug – it could be here, here, or here.

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:

We Are Screwed! playtesting session – are you OWLright?

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:

It took us 39684 coffees to get this far.

Are We Screwed? Episode #0

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).

We Are Screwed! Playtesting with Nef

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.

We Are Screwed! Prototype Trailer with “Programmer Art Style”

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:

reK ReplayKit Plugin for iOS and Unity 5.3.x

If you are experiencing problems with version 1.0 of reK ReplayKit Plugin for iOS running in Unity 5.3, here are some technical details and a quick fix while we re-submit a fixed package to the AssetStore for review.

The problem is that Unity 5.3 introduced some changes to how [ExecuteInEditMode] and DontDestroyOnLoad() works, which results in the destruction of the reK prefab instance whenever you open a test scene in the editor or drag the prefab into your own scene.

In order to fix this, just locate the Awake() call in UnityReplayKit.cs and change this

if (dontDestroyOnLoad == true) {
  DontDestroyOnLoad(gameObject);
}

into

if (Application.isPlaying == true && dontDestroyOnLoad == true) {
  DontDestroyOnLoad(gameObject);
}

and you are done.

The fix will ship with the next update of reK.