Computer Game Development at Michigan: Zelda Postmortem

Published on:

Screenshot from our zelda project

It turns out for our first project we also have to complete a postmortem document, which is fitting because I was going to write a post regardless!

Introduction

Our team is composed of Tyler Stokes and Nick Babcock, we decided to implement The Legend of Zelda’s first dungeon along with an original level of our own design. The game is implemented using the Unity framework, which none of us had any prior experience working with. Overall, we are pleased with our work and the following explains, in detail, what went right and what didn’t.

What went right

Prototyping quickly allowed both of us to develop independently of each other with little to no flaws. Since both of us are separated by significant difference, remote working was key. Our first meeting consisted of divvying up the rough framework we had outlined that would allow us to achieve that “Zelda” feel. One of us would focus on maps and the original level, and the other would focus on everything else. This worked remarkably well, but there was a time when the map was needed, and instead of waiting for the map to be finished, a series of solid colored rectangles were created to simulate the map. Once the map was done, the rectangles were deleted. While seemingly insignificant, prototyping the map allowed both us to work simultaneously and not have to wait for the other, thus increasing the total amount of work accomplished.

There was less face-to-face communication than anticipated, but this did not cause a problem. The only times we saw each other were during class time, and in this time we were able to flesh out goals and stretch goals to be met for the next class. This made us both accountable for things we said we would accomplish, and kept us on schedule, so we never had a crunch time. In fact, the few days prior to the deadline were some of the least stressful because we had planned accordingly. Outside of class, there were some text messages and discussions over the internet, where we addressed overlapping issues. The ability for us to cooperate so well working remotely is a boon; else a meaningful amount of time would have been spent in planning and traveling to meet up.

Using source control, specifically git with hosting on Github was key to our success. Development was facilitated as we both could be working on mutually exclusive aspects integrate each other’s code without hassle. Those familiar with Unity development know that scenes and some of the assets are binary files. If both of us edited binary files, we both couldn’t commit these to the main repo on Github. Thankfully, this didn’t happen often and when it did it only created a minor problem as we both committed often, so the person who didn’t commit their changes would pull the changes from the main repo and re- apply their changes, pushing after a successful merge. Github Issues played a minor role complimenting the burndown chart as we could close issues with specific commits. These features along with ease of use allowed us to develop with the safety net known as source control.

Not focusing on the minor details allowed us to focus on the bigger picture. Instead of spending hours perfecting a minor detail, we spent the time implementing a needed feature. This can be seen in Link’s walking, fighting, the rooms, enemies, and pretty much everything else. Apparently, Link moves on a sub grid, each enemy type is distinctly different, and the death sequences are animated differently. We didn’t implement any of the preceding aspects, but these imperfections don’t phase us as only a professional can churn out a flawless game. We decided to implement many aspects of the game and make them as playable as possible, which is the goal of the project. There were several other Zelda groups, and it was quite interesting to compare their progress with ours, as ours is one of the most playable renditions. Other groups have better animations or have more of the Zelda storyline, which we are jealous of, but we know that our time is better spent on other features.

While we did have some difficulty with sprites, overall they turned out well. A lot of our difficulty stemmed from our inexperience. A good example of this is that the sprites we downloaded off Spriter’s Resource were quite large and had significant spacing between the sprites. When we imported the sprites into Unity and had Unity cut the sprites into individual images using the smart technique, the resulting images were so distorted that it was hard to tell what they were. We decided to remove all space in the sprites, which slimmed down the height and width of the image, and used the grid splitting in Unity. The result was exactly what we wanted. With this successful experiment, we began cutting all the sprites down to size. This was often a tedious process, as this space was removed manually using an image editor. It was only until the majority of the sprites were cut out did we recognize the true underlying problem with the original sprites. It wasn’t the space between the sprites causing the distortion; it was the sheer size of the sprite! Unity defaults to a maximum sprite width of 1024. It should be no surprise then that trying to use a sprite with a width of 1624 didn’t work. After this discovery, we used our newfound option to increase the maximum width to save hours of development.

We knew that what we were developing wasn’t going to need to stand the test of time, so we decided to cut corners. This can be seen by inspecting our code and looking how we implemented Link’s sword. His sword isn’t another object, it is simply a different sprite with collider box that is positioned and sized depending on the direction that Link is facing. This is bad practice because Link and his sword shouldn’t be considered a single entity, which could be a limiting factor if we wanted additional features in our game. We knew this but decided against fixing it due to the time that would have been involved.

What could have gone better

Another game screenshot

Another game screenshot

Agile and Scrum methodologies were prescribed to us, and maybe it is because we are both new to it, but our enthusiasm for it is lacking. Updating the burndown chart in Google Docs is a chore at best. It is quite hard to motivate one’s self to update the burndown chart after a chunk of work, as the benefit isn’t obvious for a small project. We ended up using the burndown chart as more of a guideline rather than a strict to-do list. It didn’t help that our spreadsheet, for some unknown reason, lost a significant number of cell references, which made updates even more tedious. When working on a larger project with more team members then Agile and Scrum show their uses, as the team will be more focused. This is especially true when there is a designated Scrum master who is able to lead the team to a successful deadline. However, when a team is just two people working independently then Agile and Scrum are overkill.

Every week when we uploaded a new version and our classmates posted reviews we wouldn’t look at the reviews. We’re appreciative of them taking the time to review what we had, but the perceived value of reviews were small. What else could they tell us that we didn’t know ourselves or couldn’t glean from playtesters who we were immediately interacting with? So instead of wasting time and emotions on the reviews, simply ignore them and focus on work. There may be a good suggestion or bugfix buried in the reviews that we don’t know about, but then that would mean that the suggestion or bugfix wasn’t blatantly obvious to us or our playtesters, so our efforts are better focused improvements and bugfixes that are blatantly obvious to most players.

As far as from a design perspective, we should have invested more time in the beginning setting up the interface. The interface was one of the last items worked on and the end result looks a little goofy. This is because we positioned link in the middle of the camera, when in reality he is supposed to be placed in the lower half of the screen to make room. The reason why we couldn’t just reposition link was that because a significant part of our code relied on the absolute position of the camera and Link. If we did the move, then we risk introducing bugs into our code, and we decided that it was a risk not worth taking.

There were definitely some parts of the project that were tedious, but that is probably due to the nature of video game programming. For instance, programming around collision boxes, triggers, animations, etc, is quickly tiresome. Not to mention, if something didn’t work as expected and a quick internet search didn’t yield results, good luck solving the issue. This is probably the one disadvantage to using such a comprehensive framework as Unity. It didn’t help that we were programming a 2D game, and 2D is only a couple month old feature of Unity, so we were never sure if it was a bug in our code or Unity’s (the former was always true). I guess this is more of a tribute to the programmers of successful games than anything is because they are able to put up with these difficulties and create masterpieces.

Conclusion

It would be interesting to see if there is a difference between hours spent between different games and which one took the longest. There are other groups doing different games. The games where there are multiple groups developing them are Super Mario Bros, The Legend of Zelda, Kirby’s Adventure, and Castlevania. Since we’ve done a few Mario tutorials in class, I think I’m biased into thinking that the Mario groups had an easier time. The professor did just release a difficulty rating for development (5 is the most difficult):

We are happy with how the end result. We went from knowing nothing about Unity and game programming to pulling off a decent rendition of Zelda’s first dungeon and an original level of our own creation.

Comments

If you'd like to leave a comment, please email [email protected]