Team A5

Progress

This week I have continued my work in making adjustments to the balancing of the game, including testing reasonable timings for how long it would take to cast the various spells.  In addition to the nitty-gritty numbers work involved in this, I have been working out the program flow of how we should process incoming spells and the expected cases we will encounter with regards to spell interactions on the software side.

I have contributed to the Design Review document, along with my teammates, and helped reconstruct and smooth out our Finite State Machine, as well as the general software structure / how it relates to the embedded elements.

Scheduling

So far, we are still on track with our schedule, which is heartening as we will no doubt run into bugs that we’ll need to dig into our slack time to fix. Next up is to build the staff prototype and build / attach our circuit.  This will allow us to test our code and ensure that our data is being processed correctly.

This week was the design review presentation, and as the presenter I have received a lot of valuable feedback. The team sitting next to us (sorry I forgot to ask your name!) suggested that instead of using Bluetooth communication, we should look into using a dedicated chip like the nRF24L01 transceiver for communication. Some preliminary research shows that people have already integrated it with both Raspberry Pi (which we are using) and Arduino. It’s about $12 for 10 modules, so while it would be nice if we can scrounge around or borrow it, purchasing it is also within our budget. Of course, I also received feedback about my presentation skills. My posture, small volume, and using my phone for speaker notes was pointed out, so I will work on incorporating the feedback before the next time I present.

Having been responsible for the IMU coding, I’m still working on it and should be able to complete it some time next week. Given the performance benefit we ultimately decided against using languages like Python over C.

Progress

I have been creating the structure of our Input/Output handler code that will be uploaded to the Raspberry Pi this week and tested with the circuit that Dan will be making. The I/O handler code will be relying on a sort of Object-Oriented coding structure that we’ve made in C. We chose C over Python because C code was measured to be about 110x faster than python code (http://www.spazztech.net/python-vs-c-on-rpi.html).

I’ve also been working to complete the Design Review Report in parallel with my teammates. We have gotten all the rough content down and now are going to bring it all together with correct formatting. The process of writing out explicitly what we want to do seemed tedious at first, but now I can confidently say that I’ve thought through a decent number of design issues we may run into that I wouldn’t have considered before. I am optimistic about this coming week and I look forward to using the Raspberry Pi more extensively.

Scheduling

So far our schedule is on track, we may need to revise our code once we start uploading to the raspberry pi, but we’ve allocated time to do that in the following weeks.

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.

Welcome to Carnegie Mellon University: ECE Capstone Projects. This is your first post. Edit or delete it, then start blogging!