After forming a team, or initial ideation mostly involved building a game, something that would be fun and engaging for the paper. After looking at potential partners and competitions we could enter, we decided to take things in a more informative and serious direction. Looking through our options, my interest in evolutionary programming and space activation led us to create Yooka (the name taken from the term eukaryote), aiming to create an interactive, simulation toy type exhibition, and work with Auckland Live’s Urban Screens project.
After some brainstorming and planning for the first couple of weeks, we finished our first full conception of Yooka as an exhibition, and had our mechanical design complete. I’d learned enough from previous over-ambition in my work to make sure our plans were simple enough that we were able to stick to them without any major changes through the rest of the semester.
Interested in learning Unity, I chose to work on the front-end, building the game engine and code that would pull from the server to create and display Yooka.
Working with a program I’m not used to often creates a dilemma, where I’m not sure whether to work in an area I’m more comfortable with and likely create a more polished piece of work at the cost of learning less, or attempt to learn something new, and run the risk of handing in something incomplete or even non-functional. In this project, I attempted the latter, my first time using Unity meant that a great deal of my time was spent learning the basics of navigating and utilizing the engine. To avoid delving too far into the unknown, I attempted at first to program using JavaScript integrated with Unity, however after the inbuilt text editor started to fail to recognize the Unity engine commands, I was forced to switch to C#, and learn another tool for the first time, instead.
Thankfully, even if there is no easy set of guides for creating something a little more experimental like Yooka, when I had specific programming problems, most of the time the trawling websites like answers.unity3d.com found threads with solutions that were close to my own issues.
Of course, this was a team project, and I enjoyed working with Matt. Overall, we communicated well during the project, messaging across Facebook messenger and updating our progress on Trello. As a side note, this was the first time, after a few team-projects attempting to use Trello, that I felt it kept me organized and was helpful. Perhaps this is because programming is especially suited to being broken down into a multitude of tasks and sub-tasks and I didn’t have the luxury of thinking in that fashion in my previous work, but I will continue to use Trello in the future, and I hope future teammates will too. We didn’t coordinate our appearances in class, however, and I felt that more in-class time could have helped us to focus more on the coordination of our ideas, as it was we both worked from opposite ends of the project, and while I felt that both of them were successful, it was connecting those two together into a prototype that was delayed to near the very end of
the project.
It’s these two topics, my inexperience with Unity and the disconnect between the tasks of myself and my teammate that I felt created the greatest issues in the project. Retrospectively, I feel that despite being slow with Unity, we might have been more successfully had we first made a base unity project that did nothing except take input from a server, and then build the API and developed the rest of the Unity program outwards from that, rather than inwards from both ends. If we’d done that, we would have been developing the same project from the beginning, rather than having to test connectivity and link them together at the end. I also think that this may have allowed us to avoid unnecessary work by increasing communication and letting us more easily test and check each other’s work. On top of this, had we worked outwards, we might have used a very primitive input and output to simulate the learner experience physically, and get some-thing of a play-test running, rather than having to assume that our current design was the best option.
In terms of my learning, from just a programming standpoint this was a great experience.
Yooka is easily the largest chunk of code I’ve ever written, at almost 600 lines of code, divided into 23 functions, not taking into account all the non-scripting work on the actual Unity engine.
This is only the second non-programming paper where I’ve used programming as a part of my work, it’s good practice to code for projects that simulate the real world a little more, in that the output and functionality is more important than creating a pre-determined program with a very specific method. However, sometimes I feel like the final product is so much more important that the programming itself is somewhat devalued. My code isn’t submitted as a separate element for perusal by a programming teacher and I know that, regardless of comparative complexity, my work will probably look less visually impressive than the number of teams who submit 3D games and virtual experiences each year. On the design side, I learnt that it’s not just the outcome being over-ambitious that can damage a project, but also the process. Learning a lot of new tools, and attempting to build inwards from the front and back end of a program, then coordinate in the final weeks to create a functional product was the real ambition of Yooka.
With that being said, I’m very happy, and I feel very lucky, that things went as well as they did. Yooka is essentially everything we wanted in a prototype, it stores DNA, functions as an environmental simulation, takes tweeting photos data and parses them in. I was even able to add extra details like parents, siblings and children avoiding consuming each other, and Yooka also navigating to spawn foreign eggs. This project could so easily have ended with me handing in a broken had it’s errors and worries, and it still needs work before it can be displayed as a finished project next year, for Auckland Live, but I’m pleased with the finished result, and excited to keep working on it outside of Uni, for the Colab exhibition and eventually for Urban Screens!
