Postmortems

The Good

I had done UI design work for mobile games at DigiPen before, but I had never directly created one. The first mobile game project I developed with this engine went reasonably well in terms of game size, but the second one went significantly over scope. From that point on I used those two projects as a reference for what the scope of a simple mobile game should look like. The third project went much better as a result and became the best simple project I made with the engine.

 

The Reworld engine was decent for this early stage of development, but no engine is without its flaws. The way it functioned under the hood was unlike any other I’d used before. It also lacked a number of core features that I find quite valuable in other engines, such as a fully functional prefab system. Because of this, it was very difficult to develop games using traditional methods. Despite this, I almost always found a way to get a feature working. Using years of engine scripting experience to my advantage, I was able to adapt to this engine and find creative solutions to many problems that for a while seemed impossible to solve. For instance, to solve the lack of prefab system issue I took the engine’s object storage system and created a script that could control it and use it like a traditional prefab system. As a result, game development was dramatically sped up.

 

The Bad

Due to the inability to playtest any of these mobile games on actual mobile devices using this engine, I ended up not doing much testing for these games at all. The result was that the games suffered more than they had to. Even though I was able to get some playtests completed, more playtests would have helped the games further.

 

When I was first learning the engine, I often asked questions about how to implement certain features into my projects. Unfortunately, it wasn’t long before many of my questions became too complex for the developer I was working with to answer. I started asking far fewer questions after this. However, there were still a number of problems I ended up encountering that could have been solved faster if I had asked for help sooner. Sometimes I would spend hours of iteration searching for a solution to a problem that already had one. An example of this is when I spent a noticeable amount of time online searching for how to implement a code feature that I later learned was already built into the engine.

 

The Future

At the beginning of this job, I didn’t really know what the scope of a simple mobile game was supposed to look like. The scope examples I have learned for mobile games, although most directly applicable to the Reworld engine, shall serve as a guide for any mobile games that I create in the future. Pushing through the difficulties with this engine has strengthened my adaptability and problem-solving skills.

 

I realize now that the problems with playtesting I encountered could have been solved by seeking more information from the studio and coming up with my own means of testing. In the future, I will keep this in mind when I run into issues with playtesting resources.

 

Finally, I have learned that I should never stop seeking help when confronted with a stumping problem, even when it is likely that no one has an answer. Becoming a game designer taught me that evaluating challenging situations from as many perspectives as possible is of upmost importance, both in game development and in life. Even if no one has an answer to a problem, seeing it from another perspective will increase understanding of it and may even highlight a solution. I will not forget this next time.

 

Working with Reworld has been a challenging and often frustrating experience, but I am grateful and have grown because of it. I am now better prepared for the future of working in this industry.