Pogumono is the 1st of 4 games made for prototype concepts session in our Game Production II class. We have a week to make a prototype for a game idea with 4 prototypes being made in total. For our first game we wanted to do something that wouldn’t be too complicated since we had just started a new semester and didn’t want to go overboard right away. Pogumono is a casual strategy game where you can train creatures called a “pogumono” and take them into battle against other pogumonos.
Concept Art of Pogumonos by Sarah Shaw
What We Did Well
Overall, I think we did a decent job at not over scoping our prototype. In the beginning we thought it’d be cool to have a 3D game or have the background 3D with the pogumonos being 2D. However, we decided that since I haven’t had much experience coding 3D anything (besides my solar system simulator) and that our artist is mainly a 2D artist and wasn’t too confident with making 3D models in a week, we decided to keep the game fully 2D.
We were also able to get more systems/polish into the prototype since our designer has decent programming skills and we decided to split some of the work. I’ve worked with other programmers in the past but I haven’t done much programming with another designer. It ended up working really well since the designer was able to get a lot of the code for the UI for the pogumonos and shop done which gave me more time to focus on the game mechanics and getting the prototype working. It made me keep in mind to see if future designers I work with also have a nice programming skill that we can use to help get more work done than we would be able to if I was the one programming everything.
The final thing I believe we did well was solidify the game concept and systems early on in the week. On our first day we had made a list of the concepts we’d be going with and we we’re able to get a rough outline for how pogumono would play out. The very next day we had a meeting to solidify the concepts which allowed everyone to have more time to work on the prototype.
VDD by Benjamin Voter
What Didn’t Go Well
One of the things that we could’ve done better was our communication. While we kept each other more or less up-to-date, sharing documents we were working on, we could’ve done better on making sure everyone is on the same page with the details of the game mechanics. Even though we did get the basis of the game set-up early, the finer details weren’t clear for everyone for a decent portion of the week. More specific details like how the evolution system would work and how the shop would exactly work were quite messy for about half of the production since we would end meetings without having everyone full clear on how the mechanics work. We also should’ve wrote them out in detail on some sort of shared google doc for us all to reference if we weren’t clear about a mechanic.
Another thing we weren’t the best at was staying organized and using git. We didn’t have a proper, dedicated location for everyone to upload their files for everyone to have access to. This also played in to our issue with communication since if these files were in an easy to find place, going back to check something like a VDD would’ve helped keep everyone on track in terms of the gameplay details. While myself and one of our designers both used the git (mainly since we we’re both programming the game), the other members like our artist and other designer/producer didn’t use the git. In the future, I think sending a link everyone has access to with explanations on how to use git and holding members accountable to use git consistently can help solve this issue for future prototypes/game developments.
The last thing I’ll keep in mind in the future is reminding that this is a prototype that needs to get done in a week. We don’t need the best coding, we just need a working prototype. The prototype would most likely be created from scratch if the game was to be greenlit and into full production. I have a habit of doing my best to make sure my code is expandable for future use. That way if we want to mess with very specific variables or add something to the game we won’t have to rework immense amount of code. While this is good for when we’re working on a full game, for prototyping I need to focus on getting mechanics in rather than implementing them the most expandable and cleanest way. I could’ve gotten a bit more stuff done in the prototype if I didn’t spend extra time in the beginning trying to make out code expandable and efficient.
Attack Pogumono Art by Sarah Shaw
Defense Pogumono Art by Sarah Shaw
Final Notes
Overall, I think we did a good job. We had a working prototype in time and were generally happy with our idea and what we we’re able to get done. While it would’ve been nice to have a more polished prototype, we have to keep our expectations in line with the amount of time we had. We focused on the mandatory mechanics rather than spending unnecessary time on polishing, in the end it is just a prototype. In the future we’ll make sure to keep our scoping reasonable and I’ll make sure to work more with designers who are comfortable with programming on the game. We’ll also work on our communication and getting everyone on the same page with things like git. I’ll also make sure to focus on getting a game working rather than making expandable and efficient code, keeping in mind that it’d probably all be recoded anyways in the future.