Day 30: Spinarama

Today continues the saga of the Datum. I couldn't avoid switch statements (more to lack of time than anything else), so I've managed to create a full interface and am in the middle of testing.

A neat thing I discovered about testing that I didn't know before was that I can actually assign data and create a consistently used memory state (with consistently used pointers) on the Initialize and Cleanup test methods instead of during every method. Such productivity!

On the capstone end, the laser is finally integrated with the charger and I've started work on the quick step. The tricky part is making sure I manage the camera input and only disable specific inputs in the midst of the quick step.

On the other hand? A legion of chargers!

Day 29: Frustrating Rabbit Hole

Today's work on the assignment led me on a wild goose chase, which I must warn ye about in the future!

IF you make an object, say an array of data types, whose "type" was defined by a strongly typed enum instead of polymorphism, there is no way to avoid switch statements, save for a large array of function pointers. I thought that templated functions could work out, but they only work for constant expressions.

That is, if one wanted to make a templated function and use the enumerated type, one would have to code it so that the enumeration would be known at runtime.

Unless we're specifically supposed to use function pointers, I think I'll stick with the switch statements for now. The Open-Closed Principle may be violated, but there's not much one can do, save for besmirching the assignment and making a set of Datum classes (IntDatum, PointerDatum, etc) which was not part of the assignment. This has felt like a messy assignment, but it may shed some light somewhere down the road.

Day 28: How Many Datas Could a Datum Data?

Today marks the first big leap I've made in the current Datum assignment. In figuring out the template function issues, I've declared (not defined) the generic Get function, but declared and later defined in the implementation all the template specializations.

What's the fun stuff? Smooth rotation! Seems like by disabling Controller Rotation as Yaw in the character editor and setting Orient Rotation to Movement, the character now rotates smoothly while moving!

What's the problem? How to rotate without moving? Use RInterpTo! Problem is, using ticks inside the actual behavior tree..snap rotation? It's peculiar, and I've had to keep the rotation outside of the AI tree. There's still a bit of a bug with going straight from movement oriented rotation to non-moving rotation.

Next up? A laser! This spinning was meant for its purpose.

Day 27: Overloaded

Today was going to be a day where I could get a fair amount of work done. Today definitely turned out to be a lot more work than I'm used to handling.

The main portion wasn't the capstone work (the charger implementation is going smoothly, but otherwise nothing too much of note) or the upcoming datum assignment (a dynamic array with runtime overloads? Egads!), but code coverage.

Code coverage is a necessary part of code testing, and something that anything below Visual Studio Enterprise does not offer for native C++ testing. Does that stop me? Nay! By using an open source plugin, I effectively used the vstest.console.exe as a vessel for a "managed" test and got code coverage for my libraries. Success! Unfortunately, it cost me quite a bit of time and sanity.

Do I have time to rest? After this post...

Day 25: Caught Red-Bridged

Today was an interesting balance of tasks. The main capstone task for the day was to utilize the bridges I created from the past couple of days; this was a bit tricky on damaging the player, but using overlapping events did the trick. Combining it with rotating the direction of the bridge around the z-axis resulted in quite the amazing effect:

As for programming work, I'm almost free of the hashmap assignment! We just had to use the crt debug library to test for memory leaks in our class.

The most interesting part? Game Lab work is in progress! We're mainly working on an environment before receiving the data, unfortunately. Muse is too persnickety when it comes to bluetooth connections and we've still no word on improvements in sending JSON data

Day 24: Silent Bridge, Deadly Bridge

Another long day, but actual progress on Game Lab has been brought! Unfortunately, progress on integrating EEG data from EEGer to Unity is as (predictably following the same path and as difficult) as I thought, but I have pulled in my own work on possible gameplay aspects to incur neurofeedback with. Look out for a green seagull-shaped set of cubes!

As for the bridges today, I've been working on getting the dissolve phase material a classmate of mine used and programatically integrated it with the actual expanding bridge. Next up? Corrupt, evil bridges! They hurt the player pretty badly and are an important facet of the boss when the boss script is checked in.

Day 23: Building a Bridge Through My Skull

Phew! The HashMap is completed. It seems as though the issue was averted (not fixed, averted) by a fortunate requirement to shift the user-defined class implementation to a class-based implementation. That way, the test class is not an actual class used by other programs (it's quite hypothetical), but it and its special hash functor implementation is slipped right into a set of headers only accessed by the test class. I will miss testing it in non-test programs though. In all honesty, debugging tests is slower than debugging actual code.

As for the actual work on neurofeedback (once again!) it's definitely as I've feared; the program provided barely provides data (definitely not to a Unity interface) and is not set with clear instructions. I've setup the .exe as a gamedef file but the damn thing doesn't work.

More good news? Thankfully! The bridge power is fully setup as a C++ power. Now one can shoot an arrow from one spot to another and create a bridge that later self-destructs itself to prevent object bloat. Unfortunately, nobody on the Internet's been able to properly figure out timeline objects (updating a value over time), so I included a Blueprints timeline that calls a C++ function. Really though, I'm unsure whether we actually need the things...