Rocket Bullet Storm: Postmortem
Rocket Bullet Storm was intended to be a simplified space shooter, from the very beginning. When we received the project from Vodafone, they made a couple of guidelines for us: It has to be a shooting game or something that might resemble Space Invaders, it had to be easy enough for a plethora of different types of players to operate the game, and could only have two buttons. Both of those last two revolved around the fact that this was a game designed for immensely drunk festival goers, and could be enjoyed by all.
The game consisted of a “left” button and a “right” button on the phone, which allowed the player to move on the X axis. The player’s ship was set to auto fire as soon as the game began, and never stopped unless they were killed or won the game. We had planned a number of classic weapon systems that are generally used in this genre of game, i.e. faster shot, spread shot, homing missiles, etc, but as usual not all of these features made it into the final version. The full game was to run a maximum of 6 minutes to allow for a maximum number of players to get a chance at using the game. It consisted of 3 stages, the first two with only the three of the five enemy ships that were drawn up, and the last stage containing only the boss that would randomly shoot out ships. Two players played at once, in a competitive / cooperative mode, as players competed for high score throughout the day. Score was collected in three ways, hitting an enemy, killing an enemy and collecting “debris that fell when an enemy was destroyed, the latter being worth the most points. This was to encourage players to move around more to collect points, in turn making the game more challenging if you wanted to be on the top 10 leaderboard.
We knew from the beginning that we had to try and keep this game from being a completely scripted experience, as we thought users would come back and try to learn the patterns of the enemy waves. So, we decided to add randomization in where we could to preserve somewhat of a fresh experience every time the game was played, whether by the same user or a different one that had been previously watching the action from afar. We did this in a few ways, one being that each enemy that was scripted to spawn at a certain time, spawned randomly inside a certain area, thus ranomizing the timing a bit while maintaining visual composure. Another form of randomization was when the stage two was reached, the boss would peek out of the side screens and randomly spawn in enemies to add to the already incoming waves.
The biggest “selling point” of the game is that it was to be controlled via a mobile phone app (created in-house) that communicated with WiFi and it was all to be displayed on 250 sq. m. of LED screens, in an assorted manor, on the front of a 4 tower installation that was connected by 4 bridges.
Our initial image of the game was to utilize the center tower (which was closest to the player) as the main staging ground of our game space. There were also two side towers and a back tower with screens on them as well. All of the screens on the towers were attached to each other via the bridges, which were also outfitted with LED monitors. Because of the extremely large and oddly shaped game space we were presented with, the player was constricted to movements only on the main screen in front of them. We used the side screens for displaying in coming enemies and giving an overall feel of being in space, with an invasion of ships incoming.
Due to the previous idea of our contractor to have something with a similar feel to space invaders, we decided to give the game an almost retro feel with the art work. Very blocky (somewhat pixelated) with ship and bullet assets, as well as the nebulas that were displayed in the background.
What went right:
Music / artwork
Sounds and music are not always the first thing to cross a developers mind as soon as they get a contract, but in this case, we started a little backwards, with the music anyway. Instead of going the usual route of hiring out the sound and iterating from there, or using an in house sound-guy with a similar process, we decided to use another indie community. We are an up and coming independent game company, and we thought we should promote other up and coming artists as well. There is a plethora of solo artists that do good work in their spare time, and would like to get some recognition or a bit more popular. To utilize this community to its full potential, we surfed through numerous tracks and artists on Sound Cloud in the genres of music that we thought would fit each stage of the game. This didn’t take too long ( a couple of weeks) and it was quite an enjoyable experience, exploring music as the programmers were working on a lengthy piece of code that we couldn’t play with for long periods of time.
One group that we thought we should emphasize more than others was up and coming Hungarian artists, as it is the location of our studio and almost everyone here is Hungarian. Everyone we asked, Hungarian or otherwise, was very accommodating and enthusiastic about letting us use their music in the final game. We would highly recommend this to any Indies that have little to no budgets for music. Some people were even nice enough to go back and edit tracks for us to fit the timing better, instead of us having to go in and alter things ourselves.
The creation of the graphics went incredibly smooth, there was perhaps one or two days where we were unhappy with what we had planned out, and things were adjusted promptly. We wanted to build a mesh between the feeling of pixel and vector art which, thanks to Dávid’s expertise, melded together very well. In the end, the vector graphics was dominating the screen a bit more than the pixels, but it still worked fine.
Difficulty
We had an odd requirement for this project, its main target audience: drunken holiday festival goers. This posed a particularly difficult level design problem. How do we accommodate drunk players, drugged players, sober players and anyone from those categories can be an avid gamer to someone who has never touched a game in their life. The challenge of adjusting your game to the largest demographic possible is something that almost every game created was faced with, but the addition of alcohol and drugs mixed things up a bit.
When all was said and done, we wanted around 15 – 20% of the people to actually get through the entire game and defeat the boss. Iteration is what saved us in the end. We started off with it being way too hard that even one of our battle hardened coders could not finish it, and it slowly evolved into a much easier version with some visual kinks in it. Meaning, the flow of enemy ships coming in from the side screens was too cluttered and had to be ironed out to be visually appetizing. Every time a change was made to the code that significantly affected the flow of the game and/or the ships (e.g. the change of a ships flight pattern to look more visually appealing), the iteration process would have to be redone to get back on the same level. Some might have said, “why not wait until the end to push out the stages then?” That would have resulted in us having a much different flow to the game, one that might not have been as ideal as what we ended up with. The method we executed was not the best way to go about designing levels, but for the scale of this game it worked.
Proper Planning
From the very beginning of this project, we knew it was going to sum up to be almost all crunch time (1 month). Anyone that’s worked in the industry with a deadline knows how much they can be stressful, and how much planning will always go awry. We wanted to be prepared for every step of the development, so we utilized what is known as a burn down chart to keep our work at a steady pace and on task. For anyone that has a team under them and has not utilized something like this, it is highly recommended. They allow everyone on the team to visualize the progress that is being made, see where holes are and potentially will be soon, and if paced correctly, will keep the process smooth. There were many late nights, as there always is during crunch time, but the panic at the end of development was crushed due to the hard work in the beginning.
What went wrong:
Connection problems
As it was mentioned at the beginning of this article, the controllers for this game were android powered phones that connected via WiFi. This is something that I was skeptical about, due to many problems with WiFi in the past. The set-up of the devices was great and everything was working smoothly during the day as we were testing it out. As soon as the sun started to set, so did our luck with the connection. We are not sure why it lasted for a little bit of time, and then kicked out on us, but we found two problems with the set up that we had.
The first being that the router was just a bit too far away for the phones to handle; one phone would work perfectly fine and the other would have trouble moving the player’s ship from side to side. This would happen on and off, sometimes having long periods of time with connection issues. Our initial plan to solve the issue for the night and the next morning, if we didn’t get to it in time, was that we ran a new cable above the crowd and placed the router under the small stage where users played the game. This was a temporary fix until we finally replaced the antennae on the router with much larger ones, which compensated for the initial distance of our original placement of the device. This didn’t work as much as we had hoped, unfortunately. There was one thing that we did note during this particular experience. There were two different WiFi connections in the area (that we were aware of anyway), one being dedicated to our system and no one else had access to it but the two phones that ran the game, and the other was free public wifi for the bar and dance area. During the days, when there was less people around, the connection issues with the phone didn’t happen as much as it did at night, when more people showed up and utilized the public WiFi. Our only theory is that the sheer number of people that were using any of the WiFi connections was somehow clogging the ‘airwaves’.
Our second problem was the phones again, would lose connections of they were covered too much by the player’s hands. It was noticeable only if the user attempted to block it by hugging the phone, or just having bear hands. As the choice of phones was out of our hands, the only choice we had was to forewarn players not use an iron grip while playing. There was also some optimization of the network protocol in the middle of the week to attempt to make it better. It helped a little, but did not completely solve the problem.
Dead phone batteries
The phones mentioned above were not the most marveled piece of equipment to hit the market this year, but they were functional for what we were using them for. This is something I was afraid might happen while we were setting up and it did. When the game received some exposure to the festival, people started to line up to play and the game ended up taking over the tower. After a while they didn’t even use the VJ show until they were required to shut down the game for dance parties that ensued during the evenings. This caused phone batteries to die, quite rapidly as the screens were constantly on. As we were equipped with only 3 phones, we ended up having to run around and recharge one of the phones as when they reached 50 percent. This wasn’t too much of a hassle, but it interrupted our idea of having a system in place that we wouldn’t have to touch beside an on and an off switch.
Not sealing our interests with our contractors, when there were others on the project.
A firm warning to anyone who takes contract work, always have at least daily contact with who you are dealing with. We didn’t have too much trouble over this, but the potential for a major mistake could have been big. After attending a meeting we became acquainted with everyone else that was working on putting together this extremely large installation and injecting entertainment into it. There was another major project that was set up to displayed on the screen as well, a VJ show for night viewing. After the meeting and discussing our plans with everyone, we thought, “Ok, we have our task, they have theirs. We need to focus our efforts on making the game, they will do their VJ thin.” Sounds fine, right? Wrong.
It turns out they were in contact with the people that were constructing the installation, and had a very large say of the arrangement of the LCD screens that were to be placed on the towers. This, in turn, affected the screen layout that we were presented with and how we would orchestrate our enemy ship entrances. Luckily, our initial design of keeping the players interaction to the main screen in the front had some room for flexibility. This problem was easily solved by some alterations of enemy and boss entrances to the screen.
We experienced a similar issue when everyone involved in the installation found that the configuration of screens was not structurally sound due to the weight capacities of the materials being used in the construction. This problem was again diffused in a similar manner. Many might classify this as something went wrong and they would be right, but because of our outlined flexible design, we were able to adjust to any major situation that had come our way. Again, this is not a method that is recommended with every project, but the size and restrictions we had worked in our favor here as well.
-Zach
|
