Month: October 2019

This week, Dong Hun presented our Design Review Presentation and got feedback from the class that we will use in our Design Review Report. We have been mainly working on the Design Review Report, and making sure it will be as verbose and clean as possible. We want to save ourselves time at the end of the project when we need to craft our Final Review Report.

We now have code flow diagrams outlining the high-level logic of our code, so this next week, we will begin implementing that logic with our I/O handler code we’ve written, onto the Raspberry Pi. We will then be building the circuit for code testing and revision. So far we’ve been hashing out the preliminary design for this project, but now that we have a direction to head towards and a path for that goal, we have high hopes for our project.

With a solid plan and approval by the design board, we hope to make lots of progress in the next two weeks while we create our preliminary prototype for basic testing!

Design constraints

Now that we’re going into the nitty-gritty of the code and are getting used to individual components, we have discovered that our design constraints must be changed according to the realities of code. Dan has designed a system of elements, runes, and spells and gone over balancing various numbers in the game, including spell cooldown times, attack values, healing values, effect durations, and difficulty of casting.

 

The Design Ethos

In order to encourage the player to cast a wide variety of spells and feel like a wizard with an expansive knowledge of spells, the cooldowns on each spell are considerable. Additionally, while spells do have some effect in their base forms, they scale heavily with additional stacks to encourage the players to try to extract the maximum amount of value from each cast. Because a damaging spell cast interrupts the other player’s current spell (forcing them to start casting again from scratch), there is pressure to release spells early — possibly suboptimally. Playtesting will follow to ensure that this is a compelling balance of pressures, and to change cooldown and effectiveness values as necessary. The values of the following spells assume that each player has 100 HP at the start of a play session.

One-Element Spells:

These spells provide a basic toolset for the player.

    

 

Two-Element Spells:

These spells tend to pack more of a punch, and can prove effective tools for breaking through an opponent’s defensive options or recovering from a bad position.

Three-Element Spells:

These spells scale greatly with stacks, and a fully stacked spell from this category can put you in a position to end the fight.

Currently, the player chooses from one of five magical elements: water, lightning, fire, earth, and wind. Each element has a corresponding rune: a vertical circle facing the player stands for water, jagged straight lines stand for lightning, an equilateral triangle stands for fire, a square for earth, and a horizontal circle above the user’s head for wind.

The staff has an Adafruit BNO055 internal measurement unit (IMU), which can sense both absolute (i.e. relative to earth gravity) and relative (to an initial direction) changes in movement direction, depending on which combination of input pins are on. When the user moves the staff in the shape of these runes, the BNO055 IMU (internal measurement unit) sensor in the staff will keep sending movement data to our Raspberry Pi, which will draw vectors in the direction of movement. The user will signal the end of the cast by smashing their staff down onto the ground (which triggers the pressure sensor). If there is a close match to the predefined runes, the corresponding spell will be queued.

Of course, images speak louder than words, so here’s a flow chart of the process.

 

We discovered that there are design parameters we have not thought about previously. One of them is the minimum size of the runes that players draw. If there is no minimum, it would be extremely difficult to balance the game, not to mention differentiate between the different shapes. As we are currently using the spell cooldown times, damage healed, damage blocked, and damaged dealt as balancing factors, we have decided to ensure that each rune (with the exception of the lightning rune, which is just straight line in its basic form) has the same total draw length in order to eliminate additional complexities in balancing. Given that the typical human arm length is roughly 3 feet and our fooling around with rulers, we believe six feet of total length to draw should be a good factor. The lightning rune is the exception, because it is balanced around being a weak but very quick spell that can be charged up, so having it only require one foot per line will allow balancing.

 

In a similar fashion, we had previously stated that a minimum draw angle would be 30 degrees, since that would give us a 200% safety factor given that the tightest shape is an equilateral triangle with 60 degree angles. Concordantly, any leeway we give to the players when drawing must be less than 100% error, so we believe a 25% leeway will allow for sufficient playability while retaining game balance.

 

If our hand calculations do not provide satisfying conclusions to balancing, we plan on programming a simple testing tool to balance factors such as the damage numbers, draw lengths, and cooldown times using our slack time.