Day 112: Things Got Busy

I would say more, but I've been beseeched to take the entities and actions I made for the programming project and generically include them in a shared library.

Oh joy! I get to do both platforms of work!

Sarcasm aside, I did get to fix plenty of bugs in the playtest. The freeze is still coming up occasionally, but I'm doing all I can to prevent it. The HUD and blueprints also got a little bit of an update so the time meter is an actual meter and the post processing effect doesn't include that annoying static:

Back to work!

Day 111: Playatesting

No, we did not test a beach. Actually, the programmers had to setup a playtest aaaaall by themselves. It actually went fairly smoothly! We noted that the freeze still happens, but in a localized enough area (the gravity area) that we can track it down.

As for project work, I'm running out of things to do when nobody else is really working on it. Calling to arms tomorrow!

I've also noticed something troubling. In the shipping build, plenty of content is not being included that is included in the development build. We really will have to fix these warnings as we find them, as they might be more serious than we thought.

Day 110: Last Night

Phew! Yesterday was a long night, so I unfortunately missed the update.

That's what this morning is for! I fixed up a whole bunch of content in the capstone project, including coordinating slowdown for audio (unfortunately done during Ticks) and fixing up the build. It seems that with the Substance files that the artists are using, if they don't have the proper factory parent inside the project they break the whole project. Yeuch.

Speaking of yeuch, I didn't understand the concept of C++ async too well. Seems like the lock guard can be put inside of an arbitrary scope (who knew) and the future synchronization needs to be outside the lock scope. That, and mutexes are required for subscribing events and queues.

On the bright side, my side of the programming project is going smoothly, with entities testing out all necessary pieces of our project, including text:

Hopefully my other programmers will have the time to contribute with me!

Day 109: Line O' Sight

Today was a relatively productive day! Fixed a Game Lab bug at the last second (where'd that proper collision go)?

I also got some more work done on the programming project. There aren't too many visuals associated with this update, but I finally setup a handler that uses a hashmap of function pointers to effectively assign key handlers, along with the framework for a movable object.

As for exciting, complex things? Line of sight! We were looking for a line of sight on our enemy character, so I setup a calculation that used the dot product of the cone direction with the direction of the cone origin to the player. It's a little more separate from the pawn sensing component built into the AI, as we're no longer using the Unreal AI.

What's next? Fixing things! Lots of things.

Day 108: The Deed is Done

Phew! After a few long days of working nonstop on the assignment, I finally got the Messaging assignment working! I just had to make sure to put the try/catch block inside the lock statement and ensure that I wasn't adding async methods to a list of tasks; rather I had to give a Task.Run and encapsulate the method inside the task.

What's left? I got to do some content fixes on the capstone project; surprisingly we're using a new plugin for special files.

As for the programming project...that will take top priority! Last time we've finally got loading for tiled entities on the screen:

I also started making actions for sprite updates and drawing calls. Next up... input events, maybe?

Day 107: But Wait, It Gets Longer

Ugh, ugh and uuuugh again. I made some steps forward with the messaging assignment in realizing that locking a connection stops both reading and writing (thus causing deadly deadlock), so I finally got messages sent back and forth! Success!

Or not. Apparently I also have to start/stop connections using the UI and proper setting of IP/ports. It works alright until the Stop is called on the server (which sends a message to stop the clients) and the client stops, in which a thread hangs and the UI cannot wait before setting up new tasks.

I'm just flat out tired of this assignment, but I shall persist. And produce documentation for tonight...

Day 106: The Longest Day

6 hours. 6 hours and I'm still not out of the woods with this messaging assignment. The mix of accessing cross-thread applications in the UI, exception handling, introducing the Windows Forms and many other things has made this the most difficult assignment of the semester. I'm getting somewhere, but not quickly enough.

As for capstone, there reeeally wasn't much to do, so I made sure the random streams spawned crystal growths all over the vine:

Too busy to blog more. Must work on homework.

Day 105: Ornaments On a Tree

Today was a relatively productive day compared to beating my head against the wall with the Messaging assignment; the messages are successfully being sent back and forth now, but I have trouble determining when is the proper time to raise the ClientDisconnected event.

As for capstone, I helped with an artist assignment by using a spline mesh to create a vine. However, they were looking to populate the spline mesh with crystal growths, so I attempted to follow that location along the spline. Unfortunately, that is only possible with a regular spline, not a spline mesh component. As a result, I created a spline to closely align with the mesh and spaced out some growths equally:

What's next? Random growth placement for more natural looks.

As for the programming project, I've finally been getting my hands dirty with creating Entities and Actions, this time for the sprite. No chance to test yet, but soon I shall!

Day 104: Messaging is a Cruel Mistress

Ugh. The Messaging assignment took up most of my day, but I'm still struggling to make decent progress. I've gotten clients to connect to the server, but no messages are being sent...or the event's not firing properly. I'm still managing exceptions left and right, but I've yet to reach a stable point to where I can start working with MainForm.

I also learned, after plenty of futile searching, that instead of settling for a special Async method that doesn't exist, to just create one by using Task.Run and a lambda! D'oh!

As for capstone, I've hit the limit of tasks and there's no playtesting today, so I'll probably be looking into some possible procedural foliage when I have the time.

Until then...it's time to dispatch a message.

Day 103: Making Waves

Ugh. This Messaging assignment in our programming class is quite a bit more complex than I give it credit for; I feel like I'm being led along from class to class. I think I've got some progress, but I'm not sure where to put the server in the client...

As for programming? I pulled in a simple blur kernel and a sine wave effect to vary over time, but I'm at the point where I'll definitely need to combine my graphics work with the others' code...wherever it is.

As for capstone, I managed a few fixes here and there, but I'll have to wait out for another playtest. Our character model is finally in the game, though! More to come later on.

Day 102: Sharpening Up

Whew! Thought I'd have to ask the faculty for advice, but I managed it through all the same. After setting up the postprocessor in the programming project with another run through with the multisampled framebuffer (anti-aliasing ahoy!), the problem I had with extremely slow running in the window fixed right up. I even got to test a quirky edge sharpening effect!

As for capstone, things aren't as lucky on our end. Seems like the animation pipeline is (nonexistent) slow, so we're going to have to poke, prod, and get as much priority as we can on getting proxy assets in game. I did fix a bevy of bugs though, including an odd one with the targeting reticle. In my stupidity, I made the parameter for picking up an object via levitation the same one for arrow firing distance. If the arrow firing distance is too far, the accuracy goes off, but that was much closer with an adjusted levitation pickup distance.

There were also timer slowdowns when warping during slow time, more freeze fixing, and all sorts of fun stuff. Fun stuff I'll be handling tomorrow!

We also learned about async and await (similar to std::async and calling a future.get within an async call), but hey. No clue yet on how to do a C# messaging program.

Day 101: Never Update the SDK

Ugh. Due to one of our programmers on the programming project wanting to use some updated libraries, he's having all of us update the Windows SDK. Progress tonight? Not tonight.

Good news? We started on the messaging assignment in class; we're finally using LINQ! For those unfamiliar, it's a way to select members of a container in C# much like SQL. The syntax is a bit difficult for people unfamiliar with it to wrap their head around, but it's oddly intuitive.

As for other news? We had another external playtest! We got plenty of data on this one, which means we won't have too much to ask for next week in terms of tasks.

I've also been tasked to assist on tessellation displacement, but in managing the material displacement, I realized that not only does the object point its vertices, it actually moves up. Pointing crystals up isn't as simple now:

What's next? Waiting forever for an SDK to download.

Day 100: A Day of Slow Windows

Ugh, the programming project hit a very strange snag. It only just showed up today, but whenever I try to effectively run the game in a small window, the game slows down exponentially. Maximizing the window fixes it.

That said, I successfully got text rendering in! Now one can load a ttf file and get 128 ASCII characters of their choosing.

As for capstone work, I worked on getting a level-blueprint-less matinee system in. It was tricky at first, as I inadvertently set up a system where input was always going to be enabled, preventing it to be disabled for a matinee. Then I realized that the simple calling of a DisableInput function was useless, as I figured one would want to pause and skip the matinee. Two and a half condition variables later, we got the condition we sought.

What's next? I may require another pair of eyes on the slow rendering matter.

Day 99: EEENNNN

The reason for the harsh onomatopoeia? Just some bug fixes in capstone today. The levitation power has a close-up fail safe, so the object won't go through the person's body and will immediately turn off. However, players had difficult knowing that, so I put in a placeholder audio for now.

The warps also had some problems; when the player debug-warped to a checkpoint, the Kill fog would move down and kill them. That was fixed by doing an automatic warp of the fog to the location if it was ever above the player. The circles themselves could also be used to warp below the fog, so the fog now kills them too. The state change objects also needed to respawn, but without any local respawn boxes, I figured the fog could do some of that by overriding their FellOutOfWorld function.

As for programming project work? We got the code uplinked with the rest of the project! I had to scramble a bit, though, as the sprites had problems with transparency. Turns out that blending wasn't enabled, so I enabled it to get some sprite-work going on the screen:

Pray tell, who is that figure that looks as if it's from VVVVVV but not quite?

As for capstone work, I'm currently working on an actor that will play matinee objects without the use of the level blueprint. Freakin' level blueprints...

Day 98: Dead Air

Ugh. Today was yet another day that the Perforce servers were down, so I had to be careful in what I was working with.

Luckily the capstone work consisted of adding a component instead of changing one. The producers wanted to salvage the rotating node component that was lost in fixing up errors, so I whipped up one that is compatible with the Ley Node Generators.

As for programming project work? The sprites indeed have their own translation speed, rotation speed, and time to animate that varies based on a deltaSeconds value.

And now the servers are back up, so I can start integrating material into the project for tomorrow! Looks as if text rendering from TTF files will take top priority.

Day 97: Late Night Code Is a Dangerous Thing

You bet! I couldn't help but get some work done today, though. We had an alright playtesting session today and the bugs spoke to me that they needed to be done! There was a nasty freeze caused by overflowing the PhysX overlap events, though the fix for that has yet to be programmed.

As for bugs? Bridges within objects? Things still glowing if they're too close? Music that ends when it shouldn't? The terror!

As for the OpenGL work today, I decided to make a Sprite object separate from the SpriteRenderer, as there were so many things that were run into a shader. Frame positions for tiled sprite sheets? Texture translation for scrolling backgrounds? Size? Rotation? Parameter overload!

Still, this is all just building a framework to work with. Making a messy-but-quick framework is easy, but heck if I'd let that slip past some fine work I can offer the group.

What's next? Other than bug fixing? I'll test delta time movement calculations and see if I can Frankenstein the code to the current project that we're using.

Day 96: 1000 Useless Things

Phew. It seems there was plenty of clutter in our project this week; I mostly spent the day cleaning it up. Someone's got a bad habit of copying and disorganizing assets, unfortunately.

However! There was hope! I am now the "build master" as they say, so I'll be responsible for ensuring that the project can be built on a regular basis.

As for the programming project? We finally have sprites drawn to the screen! One sprite for now, but the global static ResourceManager loads shaders and textures fairly well, and the indexed drawing with the element buffer object works nicely:

What's next? Proper scaling and sprite-sheet rendering; those textures will probably come in a variety of frames.

As for neurofeedback? Not much was needed, but they did need a back-door entrance to the level, as they had forgotten to setup their menu with the proper sync channels.

Day 95: Lopsided

Today was another day for metering out tasks, but I got some fairly good progress on some high-priority requests from the producers. The first was to setup a color-fading for objects; I thought that I would have to use one of those janky Timeline objects, but I actually found out that using the elapsed time on the timer handles can do exactly the same thing (in a lerping perspective).

As for the big bug of the day?

Setting proper rotation for the player towards their levitating object was tricky and hilarious. Apparently when setting the actor rotation, the Y value of the rotator (pitch) translates to the Z rotation (yaw) of the character. Who knew?

And I also got more work done with the OpenGL sprite shading. Seems like I need to library link the SOIL modules next... for all builds and configurations...

Day 94: Sprite Renderer

Whew! Another long day. We had our big presentation today; the faculty seemed to enjoy our progress on the metrics so-far, and I fixed up a few bugs involving the fog not killing after loading the BossColosseum. After having to deal with child actors, I just attached it manually and used one instance. I also fixed the levitation shot time-out issue; it appears that when I restarted timeouts on weightless and time dilation cancellations, it also cancelled the levitation shot destroy timeout. Looks like cancelling specific timers is key.

As for Gamelab, I didn't have too much in the way of work (thankfully), just reorganizing the placement of the particle systems properly.

The big thing was beginning the OpenGL portion of the programming project. For the end of the semester, eight programmers are getting together to produce a simple game. Due to my previous knowledge with graphics APIs and my reintroduction to OpenGL, I feel most suited to the job. Stay tuned for 2D sprite rendering!

Day 93: Deadlock

Phew! Today was a tough coming back with a homework assignment that I didn't know was still going to be assigned.

Looks like asynchronous event handling was still on the schedule, though. I've already had experience with asynchronous programming with std::async and futures, but actually coming up with a solution for testing certain conditions was tougher than ever, mainly due to the fact that I'm not sure what the professor considers an applicable solution.

I decided to just go with a timeout on the event to stop thread deadlock and/or starvation. The idea is to do a try_lock_for, then continue onward with optional completion. I first went with timed_mutex objects, but a lock_guard was recommended, or an object that treats mutex locking/unlocking like a shared_ptr handles memory allocation and deletion. THEN I had to handle multiple locks of the same thread, as usual timed_mutex objects would not allow it.

The key? recursive_timed_mutex objects! They're actually a thing.

That mainly took up my time for today, but I think I get back to working on other more important things.

Day 92: Incoming Death Cube

Today wraps up capstone work for the week! Managed to fit the levitation shot cube with the enemy to fire at and damage the player. The only tricky part was that while the object was attached to the enemy, it didn't move as if it was attached to it. I had to constrain the location until the thing was ready to fire.

So far, the object keeps its state change properties and goes toward a player location until something is hit. That requires a slight vertical offset to make sure it doesn't skid the floor:

As for neurofeedback, I implemented the pause function that resolves with EEGer's pause function fairly well! I'm just discovering that yet another script doesn't obey the laws of deltaTime - the camera shake script.

And with that... I also got to brush up on some OpenGL again in preparation for advanced light shading lessons! Today was just a review on texture binding and mapping, including the use of element buffer objects for indexed vertices and texture mixing:

If you look closely, the symbols are eerily placed over the moon symbol texture.

Day 91: Levitation Shot

The title for today is fairly normal, as today was a fairly normal day.

Apart from some problems with source control today, I started working on the levitation shot for the flier. The shot is a generic state change object, but hurts the player on first contact and scales in and out of existence, much like the gravity well. The shot is ready to attach and use, so I may use it in a similar way to the scattershot that is currently implemented.

Oh yeah! The flier now has an actual art body, which I ensured a smooth transition in terms of materials for shader programming:

So far the new mesh doesn't affect the programming in any way. Fantastic!

I also did a bit of neurofeedback work today, as we'll need a similar pause functionality like I had in the original HGame demo. The tricky part was the vector grid; it doesn't update with a scale with delta time, so I had to actually not enter the loop if the time scale was 0.

Day 90: Now Loading

Phew! Today went by so quickly that it's late!

Nonetheless, I made quite the good impression with my action assignment. Seems like the only thing that I was missing was caching the actual Actions datum, so I made sure to do the same for Reactions since I was storing them in a similar manner.

As for capstone? The loading screen was definitely tricky, but I finally figured out how to disable character input and gravity (so they wouldn't fall to their doom) until the preloader Level Loader objects were finished loading. The trickiest part was to not disable these functions if there were only non-preloading Level Loaders or no Level Loaders at all.

Behold! A loading screen placeholder!

We also have some good feedback from our playtesting session that we can work on tomorrow! Like something that's broken and fixable!

Day 89: Attack of the Flarwmer

A Flarwmer? Well, the first step in combining our enemies was the movement, and as a result, the flier now has capable, perpendicular-to-player scurrying that is split with flying into the air. A couple of the code pieces in the enemy kept it stuck in place, like being stuck in the ground and the scattershot not being set to null as a reference. The latter is easily fixed, but the former required a slight vertical jolt to get it out of the ground.

Now we just need to give the enemy the attacks (and model, and animation) it deserves.

As for the homework, I had to go back on my action's weakness (a parsed action without any data should not be updated, but is a problem run into MUCH more frequently than an exception), so it's a simple skip for now. The Reaction tests well, and I can relax.

Well, until the neurofeedback presentation. The main complaint was the frame rate, which I could say is my fault but... nah. It's the vector grid we're borrowing, so I reduced the amount of vector edges being created on the fly and we've already got a massive improvement in frame rate:

What's next? Relaxation? Someday?

Day 88: Too Little Time

I'm short on time, so I'll be fairly quick.

Capstone! The combination of enemy designs into a single whole has begun, so I've begun establishing ground movement for the flier. Unfortunately, the AI behavior trees in Unreal are now...wonky. It's establishing a strange zig-zag movement ever since I replaced the blackboard, with no explanation to its behavior after restarting the components. So, I defaulted to the original flier movement, which fit more of its style.

As for the homework, I think I've gotten a fair enough implementation in of Reaction objects to start testing, including an extra data storage for Reactions (since there was no specification on where to attach the ReactionAttributed object). We've got much less time to finish this one (due Friday), especially with the showcasing of the neurofeedback project tomorrow. Time to test!

Day 87: For Every Action There is A...

Reaction. Yup. Seems as if the Event system we were working on is definitely going to be followed up with an action to be utilized through an event interface. Multiple inheritance? You bet! Still in the function prototype phase, though.

As for showable work? I made a decent attempt on the loading screen for our game (since it takes awhile to load assets, pre-multi-section loading and all) but detecting streaming level loading is a bit tricky. I've set it so far so that the LevelLoader checks the streaming level loading, but it reinstates the load screen (forever) somehow, so I've let go for now.

As for Game Lab? The explosion works! And rotation! Woop! The problem came from the singular cubes in the main obstacle structure having their own rigidbodies, meaning that they did not spin with the main structure. Voila!

I'm also starting to get back into graphics programming (Thank the lawd) since some advanced lighting topics in OpenGL were updated. That does mean I have to learn everything from the ground up though. I wish things like VAO, VBO, and EBO were communicable across multiple graphics APIs, but these things are so specific.

Day 86: Too Late For Pictures

Today was a little day in terms of capstone and other such work, but I did get a big thing done!

Said big thing was the resume; it had been something that I hoped I would save until I was ready (i.e. done with this semester), but there's already plenty that I could put on my resume before then.

That said, there is MUCH I have to catch up with regarding advanced lighting and shading that would benefit me in the long run. The previous site that I used to learn OpenGL shading (here) got a lot of updates, primarily in the advanced lighting category. Shadow mapping, point shadows, HDR, bloom, screen-space ambient occlusion, and deferred lighting. So many goodies that I had to pass up on because they weren't available yet now are! It's quite exciting.

As for capstone work, I used smooth interpolation to fix a bug where the time dilation ability would produce a time skip as things that ignored the time skip had to lose a few frames to accommodate the change.

But I'm still excited for the extra shading stuff!

Day 85: Special Event

Today was a particularly well-done Sunday afternoon in terms of workload! As for capstone, I helped with the necessary changes to the central-focused nodes, in which their activation was an automatic, timed powerup from calcified to decalcified:

As for content fixing, I found out I can test loading for materials and textures. Time to delete!

I also finished up with the event homework. Thank goodness we were allowed to use shared pointers! Those structures really help with preventing memory leaks. I just had to be sure to maintain the memory state before and after test methods, with the static event subscription methods and all.

Day 84: The Most Average Thing Possible

Woo! Seems like the WeightedAverager tool is ready to go! What this tool does is that it operates in taking the averages from each local computer's playtesting session and weights their averages into a full average if the files are in the same folder.

This requires that the csv averages are renamed before adding to the folder (have to be different names), but fully reads all .csv files and performs the proper parsing and averaging. I did have to rewrite a lot of the parsing for Timespan structures since that doesn't exist outside of UE4's FTimespan, but I managed it! We should be good for managing averages statistics of an entire play session.

As for homework? I found out that during our run-time type identification scripts that we attach to derived objects, templated objects may have the improper (i.e. too generic) typename. For example, Event<Bar> may have the type name of "Event", but the ID remains the same. Scandalous! Luckily I got the ok from the professor that that (design issue) caveat is acknowledged and permissible.

What's next? That was the big thing keeping me from understanding Event, but I'll be able to start testing as soon as tomorrow! Good news indeed!

Day 83: Weighing my Average Chances

Today was both a day where it felt like work was getting done and was yet to come! In the neurofeedback project, we finally got collision from one of my coworkers! Which meant we can now attach a particle effect and emit the required amount of particles per collision.

As for the capstone project today, we had another session of internal playtesting. Looks as if the game crashes if anything persistent (see: the main character) has a reference to an actor that is being unloaded. Solution? Use the unloader and reset references to null when loading another level. I have also been working on a weighting average tool outside of Unreal; it's much harder when reading all the files in a folder and managing between TCHAR and regular char.

Bomb drop? You bet. Unfortunately, the project assignment was announced waaaay too late in the day, so I've got to work on it soon!