CS376 Freestyle Devlog

Part of an exercise for CS376: Game Design and Development involves documenting the development process for a game over 2 weeks.

Aesthetic Goals [2022-11-03]

For this project, the driving force will be the aesthetics of the game as defined in the MDA framework. I already know that I want to make some sort of autobattler. If I ask myself why, I get two answers that are clear aesthetic goals.

1: planning

This is the feeling of being rewarded for thinking ahead and considering your options carefully when faced with challenges. The target audience for this aesthetic is Hannibal.

Implementation of this goal will mean giving the player enough information to make good strategic choices, and enough options to feel meaningful but not overwhelming. Additionally, losing should never be a split-second surprise and should help the player avoid that hazard next run.

A player feeling utterly unprepared is not necessarily a design failure, but should be a clear consequence of their choices. I’ll have to make sure to introduce new information/game elements carefully, and give the player time to change tactics before they become dangerous.

2: synergy

This is the feeling of causing a chain reaction, of multiple parts working together as a greater whole. Like planning, this goal rewards careful thought. The main difference is that planning involves thinking about your interactions with the environment, while synergy focuses on interactions within your {loadout | team | etc.}.

Synergy can be a mechanic (if explicit) or dynamic (if implicit) as well as an aesthetic. The main sign of success here is if players actually prioritize synergy over individually-strong components that don’t work together.

Depending on how this translates mechanically, a failure mode might be a lack of an expected interaction. For example, in a game with energy weapons and destructible fire hydrants, it will feel bad if you can’t use the latter to increase the effectiveness of the former.

Core Gameplay [2022-11-07]

The core gameplay loop of an autobattler is improving your {loadout | team | gear}, watching your {character | squad} fight something, then using new resources to further improve your setup.

There’s a genre of flash game, which hasn’t really survived past that era, that can be seen as a predecessor of autobattlers. In these games, two players have bases at either end of a 2D map. They purchase various units which then walk forward and fight the other players’ units. If symmetrical, these games are not very interesting. If they’re perfectly balanced, it becomes rock paper scissors with not much else going on. They are never perfectly balanced, and the dominant strategy is usually just to spam ranged units.

One game that transcends this formula was Bowmaster. Because the player has a means of directly attacking (with an Angry Blocks-style bow), the enemy units can be stronger and more varied. Bowmaster also has a metagame; between levels, the player can upgrade their army. There are different damage types listed for different units, but they’re only used as an RPS mechanic.

These two innovations will be my starting point. Giving the player a weapon satisfies the production requirement of direct player control. Modularly upgradable units and player weapons, probably with an elemental damage system, directly encourage planning and synergy.