Outside of the boss, each enemy held many similarities. Each enemy had a vision, hearing and sight component that would be able to detect the enemy and engage in agravated behavior. Each enemy had a universal damage component that would take damage inputs from all sources, including from other enemies.

Enemy behaviors were designed using Unreal's Behavior Tree and blackboard system to hold variables that can be evaluated by the behavior tree and tasks. While the behavior tree showcased to the left is to large to break into detail, every enemy behavior tree roughly broke into three parts. The non combat state (where an enemy looks around or patrols), the player spotted and pursuit stage, and the attack phase.

The Madkar Drill was the base grunt of the game, tpyically group with other Madkars. They have two attacks, a swift chop of the pickaxe and a wide up drill that deals more damage. To give them exra flavor, and not to overwhelm the player, there is a separate manager that gives only one Madkar the right to attack at once. Madkars will also premptively maintain their distance and take turns attacking to give the illusion of coordination even though its just self preservation and cowardice.

Thezven Saws control the tempo and force the player to be aware of their charge. They rev up their hard hitting saw and charge at rapid speeds towards the player. Given the biggest area takes place in a poisonous swamp, I wanted to introduce a sense of recklessness in the Thezven Saw. As such, I reworked their attack to use physics propulsion instead of obeying the nav-mesh. If the enemy ends up out bounds, by falling into a dangerous area not covered by the nav-mesh, it will die

The Gulluch Cannon wants to keep its space and fire shots at Seethe from a distance. Between firing shots, it will back pedal away from the player if it gets too close to have a clear shot.

However, if the time calls for it, the Gulluch cannon will charge at the player and self destruct.

Video has audio!

The last enemy waiting is the engine of haste. The final encounter mixes up his physical strikes with a laser barrage. Once it drops health below quarterly intervals, it will fire a special attack like the shockwave that drains the user's focus.

When came to death animations, I noticed that anything we could use to cut down on the animator's work load would be optimal. Especially for something as menial as a small death animation. So I decided that I could come up with a way to save the animators work while getting the players excited about scoring a kill. Using Unreal's Chaos engine, I was able to break apart the enemy model into bits when the player scored a kill. Under the hood, when an enemy is killed, it is added to the enemy pool and then a "killed enemy" model is spawned.At the beginning of developing this feature, I really wanted to go all out on the amount of broken parts and the force in which they would be propelled at.

Obviously overboard; but we wanted to sell the effect first and work backwards.The end product was much more subtle break while still being satisfying to perform.

After I presented the three enemies, and boss to the team, the work got handed off to the concept artist.

Madakar Unit Concept Art

Afterwards the concept art would get back to the rest of the team where we would make sure that it was everything we asked for. Once that was approved, the modelling of the enemy would begin.

Once the modelling was done, it would be passed to the rigger and animator to begin working on the animation hot list while it was being textured.

When a head, body and legs of a dinosaur are put together, it creates a Tinysaur which gains autonomy!

Tyran-Nosaurus-Rex

We had an array of parts to choose from that we made in house. You could create a complete T-Rex or mix it up to create a cute afront to god. The entymology of each Tinysaur is put together by taking the genus from the head and body and the species from the name.

Ptera-Hippus-Mammoth

Getting new parts is as easy as digging up mounds. To not make digging so tedious, and give the Tinysaurs some more purpose, I gave them the functionallity to dig up mounds when assigned.

Each Tinysaur had its own aggression score based on the parts it was made of. Parts from herbivores give a lower score than carnivorous parts. If a Tinysaur has a high enough or low enough score, they will chase prey with a low score. Likewise low aggressors will run from predators. Although, given they don't attack, it looks like carnivorous Tinysaurs just want to make friends and the prey do not want that.

While we did our own thing, we had check ins every two hours to see how progress was going. Everyone but our musician attended these meetings to keep ourselves aligned. This removed confusion on tasks without needing a formal task board. It also allowed for knowledge sharing for technical features that stumped people earlier.

As previously mentioned our team finished in the 70th percentile of all teams despite not wanting to go all out.As a developer, I learned that you can do a lot with a little. I had to fill my hands with a lot of boilerplate outside of gameplay. Keeping my scope small and keeping the joy centered around the little ways Tinysaurs interact with the world.From a producer perspective, the biggest lesson learned here is that an appropriate scope and insuring that everyone is excited to do their part is as good of a motivator as a pressing deadline. It decreased burnout, kept people wanting to improve their work and stuck around long enough to review other games as is Ludum Dare tradition.

Clueless friend who thought the game was only about crinoids

Level designs we built around enemy patrol patterns and general Emunel avoiding their line of fire by timing how they moved and rotated staying out of the on screen line of sight.

Too many Bullets?

We knew we didn't want single shots as it would be too easy for the player to avoid them. Rapid fire gave the players the chance to dodge the shots and keep things from being too unfair. We decided the best balance was a five round burst, inspired by the Short Magazine Lee Enfield Mark III or the SMLE. Doing our research, we discovered that this gun was used in WW1 and was in circulation through the Korean War making them accurate to them time and a good balance of attacking and cool down.

What was created was a hunter that showed no quarter to Emunel or his feathered allies.

While the base AI was complete, a new problem existed. Players noted that the line of sight of the hunters were not accurate, clipped through walls, and didnt properly reflect real line of sight

Previously, I used the blue triangle and a polygon collider to check if the player or other emus were inside. However if we wanted the player to use walls as a cover the vision would have to reflect that. I switch to a raycasting system for this new iteration. It fired a set number of raycasts spaced out over the total angles of an arc.

Afterwards each point on the raycast is fed into a mesh creating a visual for what the hunter sees. Under the hood, I am drawing several triangle over the arc.

Next was figuring out what people were good at. Since we all agreed ahead of time that we wanted a portfolio piece, I knew everyone would want to do something they were already doing in college and wanted to make a career out of. I asked people if they would prefer to be a programmer or a designer on the project or if they could be moved around. Therfeore I could look at the tasks and move people wherever.

As for task management, the majority of the team seemed abrasive to Trello or a formal task management board. Instead of fighting with them to use it, I kept a Trello board for myself to internally track progress, while creating an intermittent write-up for the team on our game design doc. This may be controversially done, but I believe the best task management system for teams is something they will use.

Roadmap write-up for team

Trello board for me

One time saver from this jam was that I was able to repurpose old code I had done previously and make it more generic for future use. I made improvements to my vision mesh script from Emu War, menu boilerplate from Tinysaurs, and the player detection and event handler from Tetherpunk to be more modular and easier to plug and play.

The modular code base allowed for other members of the team to reuse the code without fear of coupling. As such every feature that was designed to go into the game after the planning phase made it in.

One set from the tournament that went longer than an hour and a half in waiting and playing; it wasn't even the last game!

Several members of the team agreed to help out someone run a charity gaming tournament part time, and then work on the game when they are not helping. But the tourney organizer got sick and matches ran on a lot longer then they should have.

The other element is team members that get sick or burned out. While a good portion of the team was occupied by the tournament on Saturday, another handful of people were incapable of working on the project on Sunday. So the team was never at full capacity outside of the initial planning day

When working with a new team, learning what people are good at and want to do is great for managing talents you've never worked before. Additionally, making code modular and the level design pipeline compartmentalized allowed for people to pick up work from others. Additionally, some members on the team admitted they were never on a project that they were able test and gain feedback before the deadline.

If we had more time, I would have appreciated making more assets. Clarity and readability were not optimal and better assets for buttons and objectives would go a long way.