
Zal vs May
Developed in 6 months
Summary
Gameplay
The moon of Cheese and the planet of a space elfs have been invaded by the evil space queen May O'Niece and only the superhero Zal-Zalazar can confront her...
At least he could have before he died in the intro, so the elves decided to send Zalza instead so he hopefully dies in the process.
Zal vs May is a space shooter with scenarios designed to be a full on adventure, the point of the game is to reach the end of every stage.
Zalza, your character, has a variety of weapons and enemies. The weapons are weird so they accomplish a nieche role in game. Such as weapons that behave like bubbles, or bouncy balls. The enemies on the other hand are simple so the player can predict simple patterns.
My work
I worked on the entire code of Zal vs May, some of the code is just not perfect but it was functional to solve the addition of features, such as the checkpoints for which I originally did not intend to add them.
The level design was also done by me, the part that took too much energy was deciding what shapes the scenarios would have, by stage 6 I was incredibly tired, so that was when I recalled the words of one professor I had "We are programmers, we automate", that was when I decided to take 2 days of the project time to make a tool to automate scenario shapes with a "complication" increase. Note: I did never expected it to be able to generate scenario shapes for full open world RPGs but I am proud of the result.
I made Zal vs May to be small on graphics, as it is pixelart simplified to allow more enemy movement over animations, with the exception of bosses. To keep the aesthetics of the 8bits, I made a general game pallete which every element in game is forced to mantain, that also helped on keeping the elements light for the player's eyes.
And finally I made the entire soundtrack of the game, it is curious but a couple soundtracks such as the castle theme and the main title screen were harder to make than most of the game code.
Zal vs May got even better than I anticipated thanks to the participation of Jacob Parra, and Maximiliano Borraz as game testers, they gave amazing insights. Such as decorations, backgrounds, enemy nerfing/buffing, and making some parts different.

Level design

It is easy to design one level or four in a week, but I had to create twentyfour. At first I could design stages quick, but after some time I could not decide if the stage should continue up, left, right, or down, I was burned out by the stage 6. So that was when I decided it had been too much and took the time of making a tool to generate shapes for me.
The tool did not automate the creation of every part of the stage, it just created a shape and I decided later what event was to happen in a "room" of that stage created. I generated a stage shape and then in a UML editor I wrote what events were going to happen in every part of the stage. The entire game flow was already decided in my Game Design Document "GDD". On the GDD I decided what obstacles, weapons, enemies would appear and in what order. For example:
-The slime enemies start appearing in stage 3.
-The lasers start appearing on stage 5.
-There is a boss-fight on the stage 15.
So with the GDD deciding what a stage should contain, the "automatic stage shape generator" creating a shape to follow, and a UML drawing tool I was practically printing stages.
Part of what I outlined on the GDD was the type of section an stage could have. I had separated parts of my entire game in the following:
-Combat arena: Just a regular enemy encounter.
-Speedrun: A section where the player is meant to move fast.
-Swift strike: A combination where the player has to fight enemies and avoid obstacles.
-Boss fight: A huge enemy encounter with a super-enemy.
Also on the GDD I had outlined the theme of every game world:
-Abandoned honey-moon: Simple enemy encounters and tutorials
-Moon of cheese: More complicated arena encounters and plenty of "Swift strike" sections and more cheese pieces (Colectables) in the entire game-
-Minion factory: The world that introduces most of the "speedrun" sections, introduces 3 new weapons, and has enemy encounters in narrow spaces.
-May O'Niece's Castle: This world is a combination of the previous three worlds, as it is the last world of the game and for that reason needs to put what the player has learned to test. Also the other theme this world has is the backtracking, the player collects plenty of keys for doors in the castle stages to backtrack to previous rooms and progress further.
My experience

Zal vs May was my first full game released, not a demo nor a half baked game. It was a great experience to show something complete and with a lot of things to entertain people with, a full adventure.
This experience taught me a lot about organizing my time, and using my knowledge to solve problems as they appear. Also this project forced me to improve my game in order to keep up with the standards I gave myself, such as learning new ways of animating.
I also learned about what decorations can improve on a game, the experience feels different overall than the one I had originally planned, small things like gears, backgrounds and vases made the entire experience better, and more engaging.
On the programming part I learned better ways to keep my code clean. I am specially happy about the multiple "inheritances" some items have such as the enemy "parent". I also found out Unity can handle developer tools, so I took a deep dive into learning about them, these are my personal favorite self-created tools:
-Stage shape generator: It creates a shape for the stage depending on a level of "complication" written by its user
-Player path outliner: It marks the path the player follows and each mark has a time stamp that tells how long has taken the player to reach that point.
-Override savedata: It overrides the current saved data of the game to lock and unlock stages, it can also mark the stages as a 100% complete (Full game completion opens 3 special stages)
Also I learned about creating rush routes for the player to follow in combat scenarios. The game weapons and the enemies placed provided varied encounters that forced the player into creating strategies to handle them. Sometimes the enemy encounters felt incredibly smooth as the right weapon, positioning, and enemy spawned worked perfectly into making the combat encounter fun, specially in times where it made the player feel smart for thinking what I already thought for them.
Link to the project
Image gallery







