Z1 Postmortem

Carlos Camacho —
Oct 19, 2011

uDevGames 2011 Entry

2nd place for Best Story

2nd place for Best Graphics

3rd place for Best Presentation

Background

Z1 is a fun mix of old school shoot’em-up and Japanese RPG inspired story-driven gaming. The title is based off Doug’s first uDevGames entry called Zed Nought (Z0). The original concept and story was to make an extension of that game. Previous to selecting a sequel, we had discussions of making a small fun puzzle game with a Japanese look-and-feel that would better match the constraints of the uDevGames Contest. However, Carlos came across a particle generator for the Windows system and that idea was soon shelved. One of the demos for the particle generator displayed a moving star-field with cosmic dust zooming towards the camera. The demo gave birth to discussions for a space-based game which in turn led to discussions of a retro shooter. Although the game is based on old-school shooters, the engine should easily support adding new level types without disrupting the current levels.

The Story

As Z1 was intended to be a sequel to Zed Nought, Doug provided a quick background on the story. While the story was better than the typical shoot’em-up, Carlos felt that the story needed to have a greater role in the game. Carlos sat down and thought, ‘How do we go beyond the typical aliens are attacking and you need to save human-kind story?’ With pen and pencil, the beginnings of a story took shape…

“Vast is space… complete is the destruction… in my womb you rejuvenate… fragmented visions of past horrors, endless suffering and the chaos of humanity’s great retreat stirs your soul. Reborn for my love. Reborn for my vainness. Reborn for my vengeance. Too soon we must shift to real space to anew our witness of this dread Krek plague. Cruel are their unrelenting swarms. Shorn with mercy. Yet as I enumerate their patterns I am consumed by the revelation of their miscalculation. The way is clear. Rebirth is near. All shall fear.”

These words, spoken by the character Asha, served as the base of character development and story research. Political systems, organizations and religion all game into play as the overall story took shape. The story begins on the edge of human space in a system owned by the energy consortium Drake Reliance Group. Located on the science station Shibu Control, senior scientist Dr. Albert Hwan (a nod to the great Albert Einstein) and his assistant Asha, leads a team in developing a technology that will revolutionize space travel. With strife rampart among the outer system and endless crusades between the Order of Adamah and Shorini Soran, the company has placed a garrison of its self-defense forces on the nearby planet of Lazarev under the command of Commander Ckarl. The project is behind schedule and vastly over budget. We join the story as Dr. Hwan’s daughter, Lea and her foster brother Artur of Unit 88, undergo Lea’s final pilot test.

One of the reviews of Z1 mention the oriental influence of the game. This is true in the early chapters, with future chapters also hinting at the culture of Indian and Brazil – the three dominating cultures of our future.

Development

Once we had picked a genre, various screenshots and graphics demos were sent back and forth to establish the feel of the game. Doug created a design document and started on prototypes while Carlos focused on 3d models and the story. Prototypes were made for everything – the “effects” ideas were prototyped first as we felt those were essential to getting the feel of the game right. The rushing star-field and fog effects (cosmic dust) were the first to be created (and the most used in the game). As we needed new effects, Doug would prototype them; player movement and enemy movement were also done in prototypes. We prototyped many of the screens used in the game and some that weren’t. There were some animation prototypes that never saw the light of day as well. Prototyping allowed for rapid iteration on a particular concept without getting bogged down in clicking through menus or playing through four levels in order to see a new effect.

After we felt reasonably good about the first sets of prototypes, Doug started a brand new XCode project and put it all together. He then put it all up on github and then development stopped while the bulldozer that is life crushed us beneath its weight.

Once we got back on track, we worked furiously to get something, anything out the door to show we had made something.

Game Engine

Z1 was created using cocos2d for Mac. We selected cocos2d to minimize engine development time and because we really like that we had a full engine at our disposal. We had the flexibility to go in and change the base code if we wanted to. We tried to create two types of modules: ones specific to the game and ones that could be reused in later development.

Matching typical cocos2d projects, we split the screens into separate scenes, the splash screen, the menu screen, the game screen – each running as its own separate unit. There were quite a few other screens that we took out or merged with the menu screen.

Each level consists of a set of “effects”: the player ship sprite, the level music, pre-level story text and post level story text, and a list of enemy “spawners.” This was managed by a custom built Cocoa app that simply wrote out standard plists as level files.

The enemy spawners were an interesting beast. Each spawner consisted of a start time, a duration, how many enemies to spawn, which sprite to use and finally, a named movement animation. The game would read the level, order the spawners, and when the timer reached the point of a spawner to start, it would create the spawner. The spawner would then create each enemy and give it a sprite and a movement animation. Movement animations were simply Objective-C blocks. That way we could do new movement animations in code and give them access to whatever we wanted. This proved very useful later on as we were creating new sprites with non-deterministic behaviors (the ship you escort in level 3 or the drones that track your ship in level 5). The idea of spawners and animations made the engine fairly flexible and I hope to expand on that notion as we expand this game and start others.

For the movement of the player and the enemies, I cheated a little bit. I anchored everything to the center point and then translated the anchor point to almost off-screen. When scaled to almost 0, the object was center screen and tiny. As you increase the scale of the object, it gets larger and moves out from center. There were times it limited what we could do, but it got the job done easily. It proved to make some of the art more difficult, as facing wasn’t a simple option in this case.

What Went Right

Two developers developing two games

Carlos and Doug had a good creative dissonance thing going on. By the end, Doug wanted a classic shooter and Carlos wanted a grand story with a cast of a thousand. The respect that Doug and Carlos had for each other allowed the Z1 project to be a great starting collaboration, as well as a springboard for future projects.

2D Character Art

We were fortunate to have Noriko get on board with our project. Carlos provided her with character costumes, facial traits and overall tone of the characters. She then produced some of the most stunning character art we have seen in a uDevGames entry. Her art lent a higher polish to the game and greater helped to motivate Carlos and Doug. Noriko’s art was also inspiring to Carlos as he wrote the story – it was very helpful to see a character fully rendered as you wrote their story and script lines.

Story

Unlike the typical shooter, Z1 has a story that drives the levels. While that might not appeal to the most hard-core shooter fan, we felt that having characters and a rich story helped build player loyalty and interest in reaching the next chapter. We felt the characters were well thought out and not the typical characters of most games. One of the original requirements was that female characters would be seen as strong and as capable as male characters – not your stereo-typed bikini-clad princess who needs to be saved. In fact, one of the female characters in the game actually rescues a male character. In addition to strong female characters, we were also keen to make complex characters that had ‘layers’ to their personality. This concept is similar to the Japanese “honne” and “tatemae” traits of showing one face to the world and one which is kept in reserve and is not expressed. We’re looking forward to peeling back the layers of the characters in the story so by the end, the players think, ‘I didn’t expect that!’ It was also important to create characters beyond the typical Anglo-Saxon buzz-cut marine. Thus our characters hail from a diverse background of race, beliefs, social status and gender.

Early prototyping

Prototyping early and often meant less time spinning our wheels at the end. While it did make for quite a lot of code thrown away between the start and the end, it was still time well spent.

Cheating where needed

As discussed above, we cheated a bit with the sprites. This ended up being a good thing, as it meant we spent a lot less time screwing up the math of it all and more time on some of the other parts of the game. There were also plenty of times that things didn’t work exactly as we wanted, but we cheated to get it good enough to ship. This is a tough thing to do in game development. Polish goes quite a long ways towards the end feel of a game, but finishing the game at all trumps polish!

Modular code

The code has lots of places where things can get swapped in or out and where we could just remove big parts of the code. A perfect example of this is the quit and credits screens. We had a whole bunch of code around a whole new credits screen that we were also using for the quit screen (so when you hit quit, you also saw a “Vote for us in uDevGames!” button). But as we were working on it, it became apparent that having those as separate screens was visually jarring. So, we removed those screens and replace them with the overlay that we have now.

Doing that required a major rewrite of the menu code. We had to move from using the cocos2d menus to using our own buttons and actions on the menu screen. This proved to be a really big win, but wouldn’t have been possible if we hadn’t kept things fairly modular from the beginning.

Another example is the the level management. At one point we wanted to change the structure of the levels to streamline them and make it simpler to make a level editor. We need to rewrite the level loading code and make a few changes to the level manager code, but didn’t have to touch the game play code at all.

Incorporating feedback

We received some good feedback on our earlier builds in the iDevGames forums. We also gained some feedback by watching Doug’s kids play the game. We used that feedback to make some changes to the game. There are a few more changes we would still like to make, but those will come later.

What Went Wrong

Life got in the way

About three weeks into the contest, Doug was moving. Well, to be honest, he was looking for new house while keeping his old house clean and presentable for selling. Then he sold his house, bought a new house and moved. By the time the dust settled and the internet was back on… there was one month left. A smarter man than Doug would have cut his losses and decided to try again next year. Couple that with three kids, coaching a first year soccer team and a full time job… let’s just say that next year uDevGames should get Xanax to sponsor and give prizes.

Two developers developing two games

While it allowed for an ultimately better game, the merging of SHMUP and deep story made for some real difficulties. Much of the throwaway prototypes were because of disconnect between Carlos and Doug about what the final product would look like. That meant a lot of wasted time and duplicated effort. Maybe if we had more time, it would have been better to hash out the design document and be overly specific about what we wanted the end game to look and feel like.

Dropbox for file sharing

We used dropbox after struggling with email attachments for a while. Dropbox made it much simpler to work with “master” copies and make sure we had the latest and greatest. The difficulty in using Dropbox was the lack of versioning or diff control. At work, we use subversion and git. For home stuff I use Mercurial and git. I was keeping a master repository of the game on github, and if Carlos had time to be comfortable with git, we would have used that.

What git gains you in this situation, and a good reason to get your artists, designers, audio guys on board with git is that everyone is working on the same “copy” of the data. I can do my work on my local working copy and know that I won’t break the other person’s work until I do a full push to the master repository. Please go read the Mercurial tutorial (http://hginit.com/) to understand distributed version control and use it for your next project.

3D sprite creation

Sprites were fully modeled in Strata 3D, rendered and post processed in Photoshop. A great amount of needless time was spent on creating these high resolution sprites. In hindsight, since most of the sprites were scaled to 64 × 64 pixels, the amount of detail in the 3D models were unnecessary and the time spent on them, could have been placed on level development.

With limitations in the engine, enemy sprites needed to be rendered from a top-down view and have no ‘facing.’ One set of our sprites matched this requirement but several sets did not, thus the visual consistency was broken.

Originally, the sprites were to have animation frames however that was also shelved. For example, the asteroids would tumble towards you or the player ship would bank and its rendered angle would change. Overall, the sprites had a ‘flatness’ to them that we need to address in future versions.

Music and Sound

David and Carlos worked on the music background for each level and cut screens. Since the tracks were saved in MP3, the format made it difficult to properly loop the music. In addition, since the music was made before the level’s game play, we weren’t able to adjust the musical hooks to match the on-screen action. Thus, some tracks start out too slow and build to their climax too late.

As a science fiction fan, Carlos loves the genre but often cringes at the science bloopers many shows and movies make. Carlos’ original hope was to make the space environment as real as possible. That meant little to no sound effects. However, Carlos soon realized that gamers would not expect a sound-less game; they want to hear people scream when they die in space. A great number of sound effects were created however the level editor lacked the ability to assign them to actions such as weapon engagement, shields, explosions and movement so they went unused in the uDevGames version of the game.

Leaving gameplay for last

Level design and gameplay tweaks were the very last tasks on all of our list. This shows with the game. We think it’s fun, Doug’s kids are still playing it well after all the play-testing they did in order to get out of housework, but it is nowhere near where we wanted it to be. The final level, where you meet the true enemy? Is a leftover test level we did just to make sure the engine was working. In the end, it should have been about gameplay. We should have made that a priority.

The game lacks multiple weapons, bosses, and other elements of many top-notch shooters. In some levels, it is possible to stand still and progress to the next level. Ideally, we would have a third key team member to focus on the levels.

Since the story was being written during the development, Carlos also requested several functions of Doug that took him off his main tasks. In hindsight, the complete story would have been created before the development period so that levels could be properly created.

As previously mentioned, the game allowed the bypassing of levels. However, there was no ‘god mode’, so we had to test each level as a player and check each script dialog manually, which wasn’t the most time efficient method.

Story database

The story was written by Carlos with pen and paper and within a few weeks, the scribbles and notes become unmanageable. “Who was doing what?” and “Why were they doing this or that?” became confusing. Carlos began to develop a custom database in Filemaker to track characters, locations, chapters and so on. Weeks passed by while this database was developed. In the end, it was scrapped for a simpler off-the-shelf novel writing program.

A Thousand New Paths

We hope to continue development on Z1 and release it to the Mac app store once we feel it is at the level we envision. There is a whole lot more story to tell and many new characters to introduce, with the potential for a sequel and even a trilogy! For game play, we would like to introduce various weapons for the player and enemies, along with generous use of particle effects and new level effects. If possible, some true RPG elements could be added to make the game even deeper and appealing.

About the Team:

Doug Whitmore: Coder

Doug works on a combination of Mac apps, iOS apps and web apps for his day job. The uDevGames contest is a great chance to do something fun and creative. Doug has entered uDevGames three other times before this one.

Carlos Camacho: 2D/3D Artist, Writer and Sound Designer

Founder of iDevGames, Carlos stayed on the sidelines during past uDevGames contests. Now that he has passed iDevGames to a new generation of Mac developers, he finally has time to work on the many games he has dreamt of in the past.

Noriko Jepson: 2D Character Artist

Noriko is a Japanese artist that works in freehand using a graphic tablet. Her program of choice is Corel Painter and she has been painting characters digitally since 2001. She’s an avid science fiction fan and is currently enthralled with the re-imaging of Battle Start Galactica.

David Juteau: Musician

Originally from Canada, David resides in Japan and teaches English at a Japanese university. He often uses music as a means to teach and motivate his students. He enjoys the acoustic live world of music as well as the digital power of electronic music.