Day 82: The Calm Before The Storm

Got a bit of work done in capstone today! Mainly working on the zooming in/zooming out function that was suggested during playtesting and reducing the amount that a bridge can extend for more sensible use. Before and After below:

What else? I demonstrated the metrics to my producers, and it seems that might want more... a LOT more. File I/O gets a bit tricky when we have to average out multiple files, but I'll give it my best shot. Weighted averages? You bet! Parsing out an Unreal file structure (FTimespan)? Sounds gross! Dealing with a bunch of averages with possibly the same name? (Not my problem?)

I'm so happy I used the std:: file I/O instead of Unreal's. (phew)

Also, homework's not posted, so I can go home and rest a bit.

Day 81: New (Average) Look

Good news! Seems like the producers are managing some builds of their own. In response to presentation feedback, we also setup an averaging tool for the CSV files. Despite the (odd) complaints about the CSV file, the data remains valid, so I designed another function alongside it that would update and average the data every time a new entry was added. The tricky part was averaging FTimespan objects, as the actual Parse method that was used in the Engine was broken. As a result, I made my own!

As for the neurofeedback, we're getting a lot more visual updates, including the banking of the ship that was requested by one of the artists. Prepare for fancy looks!

Sensory overload? Perhaps, but I'd be darned if it didn't look cool.

Day 80: Locked Out

Ah, the loveliness of being locked out of a file because someone forgot to check it in. Story of my life.

That, thankfully, does not apply to the neurofeedback code! I slipped in a couple of changes to the obstacle generator. Namely, the thing wasn't actually colliding with ANY sense to reward updates. What to do? The plan was for the blocks to home in on the player's location, but only when they hit on a certain area outside of the center. Now, it works!

If only people applied their Perforce changes, I could test some object movement values out. Another day, I supposed.

As for the good news, we finally got an actual build on the capstone project! It seems as though the existence of my editor-only code objects were crashing the build while packaging, as it does not use those pieces of code. Now we can actually playtest without using the editor!

Day 79: Taking Action

Phew! Today's been plenty of a long day, with plenty thanks to finishing off the Action assignment.

The main thing that troubled me today was the existence and use of ActionCreateAction and ActionDestroyAction. By way of their functions (clarified in class today), the actions would add and remove actions from an entity. However, if that entity contained the action which added and destroyed actions during the update loop, that would lead to an invalidation of the iterator. Yikes! I'm going to have to build special cases around it.

However, it is finished! I almost fumbled with calling Orphan incorrectly (orphan the child, not the parent), but pedaled through and made a fully functional set of Actions.

As for GameLab, it's quite peculiar to realize that Unity does not allow a particle system to restart after it has stopped. I had to go so far as to update the emission rate, but it works! Picture time!

I also set the rotation rate on the obstacle trail so it wouldn't fling all over the screen. I'm thankful I get to work with such nifty particle art.

And with that, my work is done for today! (But not tomorrow...)

Day 78: But... The Build Refused To Change

The mysteries just keep piling on. I spent the first half of the day cleaning up content, and unfortunately I had to quarantine the Mystic Move Object until one of my programmers who was currently working on it can fix it.

As for content build, however, I'm still running into the same UAT build critical error involving an Assert::IsValid() going haywire on some SharedPointer.h. I'm not sure whether it's a specific asset or a specific level. In the build I did awhile back, I only had the PrototypeStreaming level and its corresponding sublevels, and when I attempted to do the VerticalSliceTemple, it gave me that same critical error. Perhaps the BossColosseum? It's the last level that the build loads before crashing, so that may be a solution.

As for homework? I have some sort of a parsing system up for actions now, and have tested plenty of the methods. Thank goodness I already got a handle on copy/move constructors and assignment operators for derived Attributed objects, or I'd be toast. We're still waiting out on the ActionParseHelper; it's been a long day and I'm hungry.

On the bright side, I have plenty of time to work through Action and turn it in on time. Thank goodness for weekend work paying off!

Day 77: The Userest Friendliest I Can Be

Phew! Thank goodness the homework got posted on time. It's one heckuva doozy, especially with various actions we have to implement that I may or may not know what to do for them. I'm assuming it takes the entity and destroys the action within, but I could be wrong. I could be really wrong.

But good news? Yes, there's good news! I initiated some dynamic force feedback into our systems, since people are thinking that may be a fun and immersive way to get feedback into the system. There's a small, lengthy buzz on aiming (drawing the arrow back) and a large, short buzz on firing. Each comes from either side of the controller to let the player know what side controls which.

Also! Thanks to rounding up a quick glow effect with some material editing and C++ control of emissive strength shader parameters, we now have a much easier way to figure out if something can be levitated! That was one of the much bigger things we needed on feedback:

Next up: should the sprint be a toggle? The playtester tells me I should but I should run it by the producer first.

Day 76: More User-Friendly

Today was quite the productive day! (Without homework)

We had one of our very first big playtesting sessions today; a lot of ugly things came to light, which worked really well for our to-do list in terms of bug-tracking. Falling through spline meshes? Check. Gravity wells expanding to infinity? Check. Crashes upon loading the boss colosseum? Check.

Crashes upon activating the slow down ability? Not today! I fixed those.

I also helped make the Ley Node Generator a bit more usable, including the addition of rotating points around a vector and applying relative rotations to pedestals:

As for Game Lab, I also managed to slip in a coroutine that destroyed an object instead of automatically destroying it upon passing the target point. I'll need the technical artist for more specifications on what her particle effects are supposed to do, though.

Day 75: User-Friendly

Today's also been quite the long day, so I'll be as terse as I can before my head hits the couch.

The assignment is finished! I was actually quite surprised at the amount of code coverage. I just had to make sure Entity's Update method was virtual; other Entities will be using it in the future. The Action assignment was announced but not posted yet; I'm assuming it won't be till Monday.

As for capstone, a couple of new things! The EndlessMoveObject is being used again, so it needed setup with the new interface. As for the Ley Nodes, a couple of the new producers found it difficult to setup the parts and pieces of the system properly, so we setup a LeyNodeGenerator that only requires a set of transforms and ley node classes and handles all the rest without nasty exceptions and crashes. Behold!

Up next? We need visualization for the levitation power! Stat!

Day 74: Everything You Know is a Lie

Boy, was I mistaken today. Seems like the Attributed objects AREN'T for making classes from scratch. With that mistaken idea in mind, my parsing for the XML parsing was incorrect.

How will I survive? Luckily those methods were easily swapped out for Appends, but it still incredibly disappoints me how limited and (useless for now, pain in my neck) the Attributed class actually is. Not to mention the amount of rework that went into it.

With that in mind, the Entity/Sector/World classes all required special moving of external storage based on their classes, which fixed the problem I had when testing AttributedFoo. Hoorah! What's the catch? Well, I'm a bit tired for tonight, but the MoveConstructor/MoveAssignment tests are still giving me a few issues.

Parsing works, thankfully! I'm convinced that throwing exceptions anywhere during parsing is not the answer, and that returning false is a portion I've had to change a lot of my functions to reflect. Will the professor approve? His previous notions on what constitutes an exception vs failed helper handling seem to match.

What next? Completing this doozy of an assignment; they said that the Datum/Scope portion was the cliff, but this sure comes close in terms of shaky logic combined with a gigantic amount of (Attributed, thus painful) code to manage and test properly.

Day 73: Sudden Workload

A bit busy now, since the homework (posted five days late) was posted, but it's a combination of world/sector/entity objects (mainly for game/source control reasons). It's a bunch of Attributed class copies that will definitely have the baggage stored along with them. Ugh.

As for actual progress today, the people on the neurofeedback project actually did something! I'll be joining along with one of the artists to help attach technical art such as particle systems to the game:

Back to work though. This late posting makes the homework crunch time.

Day 72: Big Things in Small Packages

Phew! Fantastic news! I finally managed a packaged build of a couple of levels of our project! Whew!

It seems that by cooking content for Windows, I noted that there were a few more errors past the Automation Test tool. Some of the assets have names that are too long; some just passed the test without being noticed.

Speaking of noticed...Jeez; sometimes these levels load in Automation, sometimes they don't. I've noted that errors sometimes rise, but the real errors are replaced by a "none is not a standard filename" filler statement on the output log. Helpful? Quite the opposite!

As for neurofeedback, none has been done by any of the other programmers. As a result, I was forced to do their work. Luckily it was fairly simple; visualizing a score that I already implemented and making a loading screen UI to fill in while the neurofeedback software is synchronizing with the Unity game client.

What next? Resting while the others toil to catch up...

Day 71: Sacrifices Were Made

Phew! Finally getting somewhere with all this cleanup work! Seems like one of the main problems (See: The only problem) in our vertical slice level was the spline blueprints. One of our producers found a neat way to use splines to create structures (walkways, super-crystals) in the level, but unfortunately left the thing. Broken. Supah-broke.

Until we can get that producer to look into it and fix it, I had to take the once majestic monolith and reduce it to components that actually existed and worked in the project. The central ley structure is now:

But hey. The level works now! I also fixed the importing error in the blackboard, so we may actually get a full build out of this! And a level that doesn't have 2000 unused meshes!

What's next? I'm going to try packaging one more time. If the automation tool doesn't have something to complain at, we may get a full build from the editor.

Day 70: Top Score For Cleaning

I feel that, like the past days and for a few (weeks) days onward, most of these will start with cleaning.

However! After coming to terms with the fact that the UDP server/client for BrainMaxx may be a bust, I've decided to move forward. By taking the score system I already secretly implemented and the simple persistent data loading of PlayerPrefs, we now have a score and a saved high score from previous sessions:

As for the cleaning? I'm almost there with level loading. After deleting an entire useless folder of 600+ goodies and setting the global game mode to prevent some odd packaging errors while loading, I'm only running into one level's loading error. The mystery continues! I also have to look into why the game fails to import the Blackboard Component for the enemies...

Day 69: The Cleaning Continues

Phew! Cleaning this project is tricky business. I found out what one of the issues of one of my level loading problems was, however!

Actually, I'm not quite sure. When we started level streaming, the level kept failing to import certain components like blackboards and UBoxComponents. Remaking the blueprint component worked like a charm, but it's still an odd fix.

I also found out that I can delete things when they're checked out. Take that, source control! I still need my coworkers to keep up, though. Actually checking in things is going to be a must for this upcoming next semester.

Until then, deleting away!

Day 68: Things Are Pretty Broken Under The Surface

Oh my. Upon cleaning a bit more and figuring out how to package the project, it seems there's a loooot more broken stuff in our project than realized. Thankfully, I have the Automation tool to tell me what needs to be fixed (when it isn't checked out).

I know that by Spring Cleaning a bit, I'm bound to break a couple of things here and there, but there's excess content imported from projects and assets never used and broken blueprints galore! Someone's gotta get down to it, I guess.

But behold! The Automation tool that keeps us from making a package!

The beginning of one of many errors. Things are about to get messy.

Day 67: Binary Nodage and Cleaning House

Before shuffling work into profiling, today started off with a simple bug/design decision thing. With our ley node system, there is no clean way to resolve the thing that happens when there are only two nodes... until now! 

Really, we just settled on one of the colors showing dominance, but I'll have to wait on my designers to get back from GDC until they reach a full decision.

As for non-visuals? Good news! We're requiring very little optimization at that point on our vertical slice level, so much to the point that there's no point in exposing even our heaviest tick functions, as they don't nearly take up as much of the frame. 

Bad news? Not much else to do at that point. I can experiment in loading parts of a level, instead of a whole level, as to completely limit the jarring freeze that happens a split second before entering a new level.

Also! In my quest to package the project properly, I see a boatload of trash packed in our project. Assets, levels, and blueprints that are never used and only make it more difficult to sift it out and make a packaged build. Time to clean house!

Day 66: Shutting That Factory Down

Wow! It seems like the assignment wasn't as bad as expected for the Factory assignment. It was a bit tricky figuring out what pieces I was missing for properly compiling the code (static template member, storing pointers instead of members due to lack of abstract instantiation), not to mention the fact that whitespaces never come after macro backslashes for multi-line macros. Yegh. However! Due to the helpfulness of the professor and the overall simplicity of the assignment and testing, the factory is ready to roll!

As for capstone work, feast your eyes on this glorious imagery:

What is that? Profiler use for the first time in Ley Lines! Yes, it's ugly and for in-engine functions quite unintelligible for most uses, but it led me to realize an important CPU bottleneck for our game thread while running the vertical slice level.

It seems that leaving the Overlap Events tick box on actually does a lot of CPU harm, especially when the objects are constantly overlapping due to something like duplicate Procedural Floors. Fixing that up, it reduced the tick time by a large enough margin to take it out of the equation.

However! How does one profile C++ code? The Visual Studio profiler doesn't work; it definitely crashes the system. What can we do? Expose stats to the in-engine profiler! I can set the stat in a C++ function and it will be identified by a specified name while in-engine profiling. We shall see tomorrow!

Day 65: A Factory of Pain

Curses! It seems that the UDP server eludes me once more, even moreso mysteriously than I previously expected. After actually using a test UDP client/server, I see that the test can receive messages from EEGer and that the test can send messages to Unity, but EEGer STILL cannot give messages to Unity. I may be at a loss here.

As for the good/ok/I guess we had it coming news, the next assignment has been posted! Quite a few mysteries juggling in my head. For the assignment, we'll be doing a factory pattern, which is a templated abstract factory. This allows the macro creation of a concrete factory, but I'm not sure how just yet. The implementation also calls for a list of concrete factories, along with many methods that seem to be static methods calling a static list. The list, since it calls for constant time lookup, seems to be a HashMap. However, why does it call begin and end? This, along with the static HashMap, exposes the implementation of HashMap. I must ask about it tomorrow. 

Such mystery! I will have to resolve it before our professor leaves.

Day 64: Hot New Website

Since today doesn't carry too much for things to do, I've gone and created a website for myself.

If you're interested in downloading, seeing, or otherwise learning more about me pre-blog and post-blog, go to this link!

If you've been keeping up, Congratulations! Not much was done today otherwise.

I will, however, be trying another update on the UDP client. A suggestion from the third-party software developer is that firewalls may be negatively affecting communication between them. We'll see!

Day 63: Things Fall Apart

Today was a fight once again against the Game Lab UDP challenge. It seems as if the UDP client, while working, does not want to receive messages from UGame. I tried the binary port, 5510, and it "works", at least to provide garbage text.

As for capstone? Eh, not much. I've been waiting for my people to catch up, so I found out why the Chargers are throwing errors; it seems there has to be a PendingKill (IsActorBeingDestroyed?) check before using a casted charger's components. I also found a neat bug in which a bug falls apart when weightless powers are enacted on it!

Thank goodness there are things to fix!

Day 62: 1-2-3-4-5-6-Step

Today was a short day, but some important bugs were fixed, including some which affected our presentation!

First was infinite dive rolling; if the character was above a surface, no matter what the slant to the Z axis, they could do a dive roll infinitely.

Not today! Not with easy access to the character's walkable floor Z value.

The bigger fix, however, was with physics sub-stepping. What is sub-stepping? By dividing the frame of time into several physics simulations per tick, one can get far better physics simulation! By using these substeps, we've improved the arrow collision to a substantial amount where there is no matter troubling clipping.

What's next?

...Seriously. What's next?

Day 61: You're Measuring it Wrong

Indeed, I was measuring it wrong. The bugs were few and slight in metrics measurement today when I was polishing up the room-based metrics, but they were there.

Mainly, I was confused as to why the time for state durations were longer than the duration spent in the actual room itself. Solution? I actually forgot to reset the start state time marker when changing state. Ugh.

Why does dying happen (according to metrics) when the player doesn't die during a session? Checkpoint warps use respawning, so I decided to put an option to not record respawning as dying for future need.

Why does the time resemble the master metrics manager, instead of the room-based one? Definitely needed to actually decouple the master-based system from the local system.

The player can actually fire a gravity well on themselves? That... was not metrics related but came up anyway. Actually, I'm surprised no one ran into that bug yet.

The next thing I discovered as I was wrapping up the metrics tool was that dive rolls tend to allow infinite movement on slanted surfaces. I should probably fix that if the player can't walk on it.

Day 60: Super Day Off

Almost had a full day off! Almost! I found it more important to work on UDP clients first.

I mainly had the issue with the sample code that I found being a synchronous blocking call instead of the asynchronous behavior I seek. Luckily enough, there's this thing called an AsyncCallback that allows me to send in a function (even if it's not static! Hooray!) to be called asynchronously. That way, it will block the thread but not the whole data.

In that case, whenever I send a message, it receives it on spot! The problem is, the system I'm working with uses a python file to send data. Oddly enough, it does not get received. Am I doing something wrong? Does the UDisplay.exe file hog the data? I'll have to investigate. Perhaps I can recompile the python files?

Day 59: The Room (A Room)

Today's another day of the relaxation of Spring Break! That, and working to make sure I don't feel too guilty about Spring Break.

Today was mainly about metrics measurement. As a revision to the "master" metrics manager, which would measure across an entire session but not for specific areas, the manager got some options for more localized measurement.

For the rooms, one could use a overlap volume to detect when to measure things such as environment interaction and player death. However, the main issue that I've been running into is measuring state time duration. The player would no longer be able to detect these localized reactions; the volume would have to be responsible with these durations, even going so far as to force the player to call itself.

Is this working? Not quite yet. The actual time duration for gameplay is 3 minutes, but for some reason state time clocks over 5 minutes. Problem? Yes.

Day 58: Am I Allowed a Day Off?

Almost! I still did a tad bit of work. Looking into the awful bugs we experience during our vertical slice preparation and presentation, I discovered a couple of things.

1. Lighting was very haphazard in the build. I had trouble with lighting builds due to a god awful amount of overlapping point lights. Never overlap point lights.

2. I tried recreating the bug where button inputs on the controller would crash the game, but it seems quite odd. I ran into the crash by pressing the T key and also saw that input for a right shoulder was a Right Shoulder Axis input, not the Right Shoulder input proper. I switched it back and saw no problems.

3. I may also look into the Charger Character and spawners; it's likely that they should not interact with their behavior trees nor spawn extras when the KillZFog gets to them. I may put in a fix where spawners are also destroyed on interaction with the KillZFog.

4. Other than that? We got a new programmer! Woo! Now I must send them to fix my problems.

Day 57: Even Less Work

But it's a good thing! I can actually enjoy my Spring Break!

It's enough work that I knocked my homework out of the ballpark as well. I'm concerned as to whether my parse helpers should throw exceptions or just fail the actual reading, but I'll have to wait on an official statement for that one.

This mainly comes from the use of a pushdown automaton; the finite state automaton, previously only usable with specific states, uses a structure like a stack to save data from previous encounters. In the case of parsing out scopes, one would use the tree-like hierarchy of scopes to focus on the currently used scope as a reference (pointer, mainly). Any problems? Had to rewrite plenty of code, but it's all done!

What's next? Jeez, never thought too much about it with break on the horizon. Going back to metrics, I suppose.

Day 56: Less Slice, More Work

Phew! Our project made the cut, after plenty of ambitious work. Now to move on and enjoy Spring Break...

Ha! Just kidding. More homework is abound, mainly parsing a scope from an XML file.

How does one parse a scope, pray tell? With the XML parser and an Attributed class! I had to publicize the AddInternalSignature method and Populate method, but it works out fairly well. My main worry was parsing based on signature, but it seems I can make a Hashmap out of strings from XML tags and member function pointers, which have some of the most disgusting syntax in the world of C++14.

As for any issues? Well, the helper now needs access to shared data, so that means forward declarations. What? Can't forward a nested class? The parameter needs to be the master, then. It's quite bothersome, but the only way.

Day 54: The Land Before Slice

Today was a horrific bug! Procedural waypoints were spawning everywhere and... was fixed. Turns out by putting an unnecessary boolean and BeginPlay spawning, the points were spawning every time one would enter the level. No more, though!

Now I'm on wait until the vertical slice presentation tomorrow. I did do some work for programming and neurofeedback! The specifics were to bend the grids to resemble a tunnel, so I managed to get an equation to fold them into half circles. If one imagines the height being the diameter, one could place the integers from 0 to the height as angles for constructing a semicircle. Voila! A tube!

As for programming, the parser is about to get its chops tested with scope production. Seems like the professor really wants us to use an automaton, so we'll be using the stack we made for a pushdown automaton to keep track of the current scope we're populating.

Day 53: Bugs? What Bugs?

An exam was today! It went alright.

But the bugs? My goodness! With vertical slice coming to a close, we must we swamped with bugs and terrible functionality!

Not really. We really are struggling to find bugs. There was one that almost stumped me, but it seemed to be a collision issue where arrows moving fast enough may clip through blocks that are small enough.

What else? Hm. Well, the Gravity Well disabling needed to be set to the Gravity Well power only, a quick little graphic in the menu was used to distinguish between colors, the arrow should not darken objects (i.e. return their original color, not a black one!).

Ah! I remember. One of my producers was tinkering with post-processing shaders and came with a really neat, lined effect. The problem? It took the color out of the emissive objects! What's a girl to do?

Thankfully enough, it was only the lack of bloom. In UE4, the bloom post-processing effect was responsible for the lit effect that would come from materials with strong enough emissive qualities. Crank it up just a tad and reduce the emissiveness of the color and voila:

What's next? At this rate, that may be an existential question.

Day 52: 24 Hours

Until the exam! Just kidding. I finished up my capstone hours for this week, and it's the highest yet at 24 hours and 4 minutes. Hot diggity!

Seriously, I'm concerned there aren't more bugs sooner, but I'll chalk that up to constant bug fixing for now. The main bug today was making sure that the central-focused nodes indeed did point toward the crystal, but not the middle. This led one of my coworkers to originally have them pointing straight ahead, but I instead ditched that and went for a 3D widget style endpoint that one could drag around.

I put some more metrics in as well! They unfortunately won't be used as much for vertical slice in the next couple of days, but heck if I know what else needs fixed. I managed to get the time that the player has been attuned to each power, but the rest will be a research project for me over Spring Break. I know a screenshot of a csv file is riveting stuff for progress, but one can do without.

My assignment grades for programming actually went well! I was advised to take my struct with a union in it and turn it into a whole union, but it's fairly (impossible) difficult to determine how to build the constructor/destructor/assignment in that way, as the non-primitive types in the union forced deletion of basic methods (???)

What next? Make the broke thing fixed!