top of page
Search

Mobile Game Design Blog Post 1

Liam O'Hare

In my CAGD 370 class we have been assigned to group up and prototype a small mobile game idea. This first sprint we have focused on building a paper prototype and starting the Unity build for our project. This sprint was topped off with a playtest.

I am the level design on a team of three people. This sprint I built the paper prototype board and pieces as well as started the UI design for the digital build of the game.

My main cards that were completed focused on building a functional paper prototype that properly translated the game's mechanics and processes to a physical game. I spent time drawing out multiple maps until I found my most fun layout. This layout was built around the idea for a turn-based game. Gravity works against and with the player as they try and navigate falling through earth's atmosphere. Debris blocks you on the way so the player must use their jetpack and grapplehook to get through. These cards were simple and only took time and effort. I went through many drawings of levels before I found what was mainly fun for the player. After this I simplified the level so it was ready for the playtest, where players would be entirely new to the game. This level represented our first/tutorial level.

I only ran into issues on this when working with the programmer, who had the job of writing the rule sheet. There was confusion and miscommunication involved, which hurt us at the playtest, when we realized too late that our rule sheet did not properly prepare the player for the board I had made. This was solved quickly and only affected some of our findings, but it worked to teach a valuable lesson, communication was something to be worked on in our team. While I feel we are all really efficient and focused on completing tasks, we could have used more time discussing the game as well as playtesting together, rather than individually. This simple change would have easily avoided any miscommunication between us and our players.

I also had a time management issue. Working on team projects I find requires constant engagement with the project, rather than long durations of work. I have to restructure my schedule so that I can accommodate this. I am used to having classes with large amounts of work required from me, so I am comfortable with sitting down for long periods of time to get things done. I find my group works better when we meet multiple times a week and are constantly knocking cards out of the way. I will have to be prepared for my group so that I can constantly provide help and be engaged. This has meant I have changed the way I get work done in entirely separate classes. I will now be doing around one hour of work a day towards each class, rather than about five on one single day for each class. I don't know if this decision will work yet, although I am excited to see if it pays off and helps my team in Sprint 2.

I am now working on scripting some objects that will be in the game's level sandbox as well as helping build the UI for the player. I have come to some issues in how to fit my programming to our programmers liking, but I have learned from the previous mistake and quickly took to communicating to find answers. This has quickly led me down the correct path for an efficient and well build UI system so far. I do hope I will get some cards soon that will be more related to my job as programming isn't my strong suit. After finishing UI I am excited to build level assets and place them accordingly to start my path as designing this game's levels.

Recent Posts

See All

MADT Blog 10

The open letter asking for a pause on AI neural network development is in my opinion necessary. This pause on development is good,...

MADT Blog 9

The Internet of Things is a developing technology which uses many devices in conjunction as well as the internet to manage the existing...

Comments


bottom of page