You can check out the game
HEREDon’t Croak was made by a team of four people I led over the course of ten weeks, and the core idea was to make a puzzle platformer taking inspiration from games like Pikmin where you lead an army of small creatures to do your bidding.
I was the primary programmer and designer, and I had two artists and a level designer on my team. In the game, you play as an infant who has been cast into a swamp and is now tasked with delivering as many frogs as possible to the great Lord Broap. Being that you play as a baby, your mobility is extremely limited, unable to do anything except crawl back and forth. The twist is that through enamoring frogs hiding throughout the swamp, you’re able to build bridges to cross gaps, break down obstacles, and weigh down objects the baby would otherwise be too light for.
In this, the primary mechanics are frog resource management, and building bridges. This is what the majority of my time working was spent on, as these concepts went through several iterations. Early ideas involved being able to make chains (originally the concept was inspired by the barrel of monkeys toy) and swing about from place to place, and there were frequent switches between ideas of only allowing frogs within a certain radius to be used (vs allowing the player to use all their resources at all times).
Unfortunately, time constraints forced some of these expansions on base ideas to the side, as I spent a substantial amount of time getting the hang of using Unreal to code for my first larger project in the engine.
Given that the development time was so quick and I had such a small team, I feel it is better to showcase this project in the context of a post mortem.
What went right?
Throughout development communication with my team was consistently clear and productive. At the end of each meeting I delivered my expectations for each member and each one almost always delivered either what I had asked, or enough work that the result could be easily workshopped during the next meeting. We virtually had no bottlenecking, with the possible exception of myself, since my level designer was building the levels around the mechanics that were in progress.
Another thing that went well was that I was very on top of bugs, especially when it came to the core mechanics. Bridge building was especially susceptible to bugs, as my more granular ideas for how the system would work was really difficult to balance. For example, determining the collision for the bridges is done through the frogs that spawn in place themselves, like so:
This meant it was very important to make sure the bridge frogs spawned with correct spacing according to one another so the player could cross each gap.
Making sure the player was never stuck in the middle of a bridge or the bridge correctly spawned between the two goal points was a constant struggle but in the end my system turned out to be extremely consistent.
Additionally, getting the player’s frog minions to stay alongside the player proved to be a significant challenge, as these creatures obviously move around primarily by jumping, rather than flying or walking right behind the player. This meant that in a vacuum frogs easily get stuck leaping into random pits or unable to scale certain heights, and after wandering around for even just a little bit, it would appear as if the player has no more resources. This was another piece that had to be tweaked constantly over the course of the project, changing the speed, jump height, and collision profile of the frogs based on their distance to the player, so that they travel far more unrealistically while off screen but still jump into frame naturally.
Both of these also worked well with the save/checkpoint system included, which properly stored both bridge locations and the status of the player’s frogs, and allowed the game’s state to be accurately unloaded and reloaded upon death or quitting. Since the bulk of the game relied on the success of these things, I was happy to end up with a product whose components all functioned reliably.
What went wrong?
Unfortunately the work that went into making the base of Don’t Croak successful led to its biggest issue, being its length. Games with any kind of puzzle elements beg to have their base mechanics explored over time on different levels, and with much of the ten week timeframe being given to the mechanics at a core level, this proved to not be possible. Our team was hoping for a minimum of 15 minutes of gameplay with multiple levels, but in the end we barely managed one complete level with about 5 minutes of gameplay if the player knows what they are doing.
While we could have taken the concepts in this first level and rearranged them for a second level, we were hoping to come up with additional unique components to expand on the game’s concept. Our first level had several pieces working in tandem: the leaf piles, tire swings, fly blockades, snake enemies, etc. and perhaps if our team had a dedicated level designer, we could have ended up with further components that could make up a second level.
This leads into our second main issue, which is that while our team had good communication, we had a slightly awkward combination of talent. We had one programmer/systems designer, two artists, and one generalist, and this proved to create a huge weak spot in terms of efficiently creating different kinds of puzzles with all sorts of unique components. Throughout development our generalist was responsible for level sketches, level blockouts, asset placements, particle effects and various menial tasks. Given that he had no previous emphasis on level design and also volunteered to take up plenty of unrelated tasks, level design remained a slow burn of a process.
This assortment of talent also led to some lacking visual movement in our environment. While we had no shortage of 3D modelers, the limited visual effects and animation led to the game’s world feeling less lively than it could have been. A swamp by itself is not the most beautiful or exciting place to tell a story, and our inability to breathe additional personality into it made it feel more bland and unappetizing than it could have.
In the vein of having much of the development time spent on the game’s mechanics in their most basic form, I was also disappointed in being forced to scrap more liberal interpretations of our concept, such as being able to create and use chains that the player could swing from or attach objects to.
What did we learn/what can we do better?
Given that this was my first project as a team lead there was a lot I learned about running a game’s development. To start, it became clear towards the end of the game’s development that when working with a small team, having one person who isn’t really honed in on a particular part of the project is closer than not to being a wasted asset.
Another thing I learned was not to underrate the importance of particle effects and other small flares that bring so much life to otherwise static environments. Only towards the very end of development did I think about asking one of my team members to provide any sound or visual effects, and I think the lack of these small flares really showed in the end product.
More broadly, this was my first larger scale project with Unreal Engine and when I look back at each of my blueprints that made up the game’s core I think that inexperience really shows. For example, my methods of bridge construction led to a lot of issues with the player getting stuck in gaps of collision, and instead of attempting to create bridges by spawning frogs meshes with special collision perfectly in sync with one another along a line, it would have been much easier to spawn a mesh with dimensions according to the line between the player and the target. Additionally, this could have opened a much easier door into exploring some of our earlier ideas, such as taking this spawned mesh, grabbing the end of it, and changing its rotation to act as a vine. A few pivots in both leadership and building the base mechanics could have done wonders for bringing Don’t Croak to a higher level.