Computer Game Development at Michigan Week 2: Start of Unity

Published on:

It’s the second week into this course, and my feelings are still mixed. We went through a Unity tutorial in class, and I found out that Unity utilizes C# to control the logic, and C# is my forte. I may have an advantage over some of my other classmates because C# is not taught at the University, and taking a Java class is somewhat frowned upon, so working with a statically compiled and garbage collected programming language may present a learning curve to some of my classmates. One of them was agitated enough over C# that they posted on Piazza curious if they were expected to learn it on their own (the answer was yes they were expected to learn it on their own). As an aside, I find it curious that while Michigan is C++ based, at least two of the senior design projects, this and the class labeled “Software Engineering”, use C#. I’m all for being a polyglot, I just find it interesting that many students are only exposed to C# during their last year/semester.

Unity refers to C# in the terms of “Script File”, which I find extremely odd considering a script is something that is interpreted and not compiled. In a way it reminds me of, scriptcs, but I believe that Unity is only calling them scripts for terminology, whereas behind the scenes Unity is compiling the program. Files can be written in languages other than C#. Javascript and Boo, which is essentially C# with Python syntax.

Previously, I mentioned that the school’s computers had Unity installed on them but they were 0.3 versions behind the current stable version. I didn’t think much of it until a classmate pointed out that it was only in the latest versions did their support for 2D increase. This wouldn’t be a problem, but our first project is to replicate a classic 2D NES game. This means that I need 2D capabilities, and so the school computers are a no go for me to work on. The professor realized this and so sent a request to have the program updated to the latest version. As of this moment, there is no word if this request will be fulfilled.

This project is partner based, so I paired up with the guy sitting next to me at the moment. Turns out he was in another team of ENGR151++, so even though none of us have any prior game experience, our combined talent should make up for it. We were given a list of possible games to implement, and I only recognized a couple of them: Mario and Zelda. I figured that Mario would be the most popular choice, so we decided on Zelda. At this point, I somewhat regret this choice because the tutorials that we did in class all dealt 2D scrolling where the camera is looking at the characters sideways, whereas in zelda the camera is looking down on the world.

Something odd, that has nothing to do with video games but is heavily emphasized in class is Agile and Scrum. We even watched a corny intro into the subject on youtube. Each team has a burndown chart hosted in a Google Doc’s spreadsheet where we list the tasks we need to accomplish, estimate the number of hours it will take, and assign it to someone in the team. To encourage us to keep it updated, every class period a few random teams are selected to present their burndown chart and their progress. Also, about every ten days we have a demo day where everyone shows off the current state of the game and people provide feedback.

So my partner and I met Friday afternoon to figure how to attack this project. I lot of it was actually based on the sprites available to us on spriters resource. We saw that instead of having entire levels as sprites, the individual terrain, 16x16 pixel graphics, were combined to make a sprite. This would be great, as Unity has a feature that will split a sprite up into equal sized images; however, each individual terrain peice had a 1 pixel grey border around it, which would throw Unity for a loop. Thus, I have took it upon myself to delete the grey border and manually squish the peices together. If this sounds painstaking, it is because it was. Why someone had to add a grey border around the terrain I’m not sure. And the terrain elements were not an isolated case. Every single Legend of Zelda sprite was haphazardly laid out, such that one couldn’t directly import it into Unity. Even though Unity has a smart sprite detection, individual sprites may not fill up the 16x16 square with color, and so Unity would cut a rectangle that wasn’t 16x16. The problem with this is that since the sprites are compressed, the quality of the sprites were terrible. I don’t have an exact reason why this occurred, but Unity would complain about the DXT5 sprites having a size that was a not multiple of 4. The programmer in me finds it ridiculous that Unity would cut out the sprites in a “smart” manner but then complain about the result.

After four hours of manually cutting out sprites, they are almost finished. At the same time, my partner is working on creating a parser that will read in an xml file and then create the world based on that. The xml will have maps that are drawn out with individual characters, such that ‘.’ represents desert and ‘f’ represents forest, with each level declaring what bad guys appear. Are hope is that after a week we can combine what we’ve accomplished to have a basic overworld that is generated from xml files, and if we are lucky, have Link moving around.

It felt weird, but we decided to allocate time for research (three hours worth), which consists of us playing Zelda and watching others play. I felt like this may have been overkill, but I’m now reevaluating that opinion. Watching someone else play Zelda has been insightful. They give commentary on the mechanics of the game, such as

I didn’t expect it but all of this is adding up to be a lot a fun. Even the manual sprite cut outs.

Comments

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