Today will be a short post, as I have been quite busy these past couple of days and need some sleep.
Phew! What an assignment this has turned out to be. I've been implementing a hashmap and both learned some interesting things, ran into some issues, and managed partial success.
Partial? Yes, unfortunately, I've managed hash functors for all but one of the specified key values. For some odd reason, the user-defined object classes give compiler errors when I try to make hash functors out of them. Pointers, integers, characters, and strings give no issue, but dare I use a Foo? The compiler sure doesn't think so.
I've also learned that due to allocation costs, it's actually quite permissible to store an iterator inside an iterator's implementation as a data member. Who knew? Especially since it's an iterator to a linked list.
This also leads to some odd implications that I don't get in the other containers but I do in this one. For iteration, the values are unordered and not necessarily next to each other, so I have to quickly look through each and every bucket and iterate through each list to manage it. Sounds like a bit of extra busywork, but it's the only way if the data's not even contiguous, let alone ordered. Luckily enough the hashing's lightning fast by comparison.
What's next? 1200 more lines of test code...
Sunday, January 31, 2016
Friday, January 29, 2016
Day 20: Magical Ball of Targeting +2
Phew! Managed to overhaul the master projectile target design for something that is at the least unique, if not more than suitable to the task. After fixing a bug that imposed too much gravity onto the projectile (the arrow acts as if it has no gravity in the beginning, as to make the shot straighter for the player), the arrow now hits where it needs to go.
However, how does one line it up with the screen space? Can one line it up with the screen space? Instead, I opted for a world space targeting reticle that snaps to the area for firing. This creates a more immersive way to look at targeting:
As for the trailing line, that helps map the exact trajectory of the arrow. Much like a smoke trail, the player can now feasibly trace the arrow to its target.
What's the catch? Well, this arrow targets a lot of things, including unnecessary things like actual arrows and gravity fields. This means a bit of work to do...
However, how does one line it up with the screen space? Can one line it up with the screen space? Instead, I opted for a world space targeting reticle that snaps to the area for firing. This creates a more immersive way to look at targeting:
As for the trailing line, that helps map the exact trajectory of the arrow. Much like a smoke trail, the player can now feasibly trace the arrow to its target.
What's the catch? Well, this arrow targets a lot of things, including unnecessary things like actual arrows and gravity fields. This means a bit of work to do...
Thursday, January 28, 2016
Day 19: Late Night, Come Home
As for work today, the stalactite still eludes me. Such mysteries of physics interaction! It's like I have to disable physics once the stalactite hits the ground. Luckily, the event of being caught under the stalactite successfully constantly pushes the main character out of the way. The tricky part of that one was creating an extra array to remove pieces of an array during iteration. During the process, one can only inspect (not change) parts of a container, so an extra container containing the to-be-removed pieces needed to be taken out.
As for programming work today, the stack cometh! Fortunately, the stack was only an adaptor. In that case, the vector was more than suitable to fit a stack's needs. As for unnecessary implementation, that always comes with a cost for using a complex container to mimic a simple one. Luckily, it's not too much, dealing with the already simple implementation of a vector.
What's next? Hashmaps!
As for programming work today, the stack cometh! Fortunately, the stack was only an adaptor. In that case, the vector was more than suitable to fit a stack's needs. As for unnecessary implementation, that always comes with a cost for using a complex container to mimic a simple one. Luckily, it's not too much, dealing with the already simple implementation of a vector.
What's next? Hashmaps!
Wednesday, January 27, 2016
Day 18: Crushing Defeat? More like Crowning Victory
Thank goodness! After looking in the same particle distribution parameter that solved the Size problem, I managed to find the issue that had been nagging at me since the Ley Blocker!
Turns out the actual Target (the beam particle system has two nodes for the start and end location of the beam, Target being the latter) location was a parameter that I could set. The actor parameter looked as if it overrode the line, but could not work with actors that weren't already in the scene. As for the particle distribution parameter, I used that instead and now have a beam that can be set with location!
As for the size parameter, I could not figure out a decent way to manage size of particles programmatically. As for Size By Life as a particle system node, I could combine that with proper timing of activation and deactivation of nodes to get a nice firing system that can be repeated and attached to actors at will:
As for the stalactites, I managed a quick and dirty implementation before I left work today, in which the stalactite consistently launches characters outside of its vicinity while they are in a set range. A bit of tweaking tomorrow should help finalize the stalactites as a threat.
Turns out the actual Target (the beam particle system has two nodes for the start and end location of the beam, Target being the latter) location was a parameter that I could set. The actor parameter looked as if it overrode the line, but could not work with actors that weren't already in the scene. As for the particle distribution parameter, I used that instead and now have a beam that can be set with location!
As for the size parameter, I could not figure out a decent way to manage size of particles programmatically. As for Size By Life as a particle system node, I could combine that with proper timing of activation and deactivation of nodes to get a nice firing system that can be repeated and attached to actors at will:
As for the stalactites, I managed a quick and dirty implementation before I left work today, in which the stalactite consistently launches characters outside of its vicinity while they are in a set range. A bit of tweaking tomorrow should help finalize the stalactites as a threat.
Tuesday, January 26, 2016
Day 17: Crushing Defeat, Hidden Fix
Today was a day for a bit of a quick fix on the vector implementation. After a bit of clarification, it was necessary to only call constructors on the data that was up to the size, not the capacity. While saving a bit of time on calling constructors with reserve calls, this also meant that Push Back had to call the constructor instead, each time size was increased.
As for capstone work today, I attempted my darndest to get a procedural actor to act as an instance parameter, but no dice. It's quite the peculiar bug in that the Particle System doesn't recognize the instance location of both child actors nor dummy actors created in the scene. Scene-specific actor references will have to do.
On the bright side, the size of the particle system is an applicable instance parameter for laser expansion! The tricky part was figuring out the difference between modules that could be converted to parameters and those who took a "parameter" as a data type. Twas a bit of a jumble when I was searching today.
What next? The size increase is a bit wonky; the leftover particles still remain present after the size change, making a less-than-smooth change.
As for capstone work today, I attempted my darndest to get a procedural actor to act as an instance parameter, but no dice. It's quite the peculiar bug in that the Particle System doesn't recognize the instance location of both child actors nor dummy actors created in the scene. Scene-specific actor references will have to do.
On the bright side, the size of the particle system is an applicable instance parameter for laser expansion! The tricky part was figuring out the difference between modules that could be converted to parameters and those who took a "parameter" as a data type. Twas a bit of a jumble when I was searching today.
What next? The size increase is a bit wonky; the leftover particles still remain present after the size change, making a less-than-smooth change.
Monday, January 25, 2016
Day 16: Black Laser And That Slow Southern Style
Phew! Today marked the end of the vector implementation. The tricky part about this was that our professor required placement new when initializing a set of objects in the vector. This ensures that one can call something other than the default constructor when one allocates a new set of data.
Of course, this means directly calling destructors and calling mallocs and frees like it was C all over again. Ugh. UUUUUGH.
As for capstone progress, I looked into a few bugs surrounding the arrow and the StateChangeCube. The first wasn't anything much, as the arrow only looked as if it was directly hitting the object; a slow ricochet means that the arrow hit the ground first and already wasted its state-changing energy.
The actual bug went to the warp effect; when being pulled across the ground, the object had a chance to sweep into the ground (even though the vector may be fully horizontal), so I had to use the implementation to move the object up before warping it.
As for the next implementation, I'm still trying to figure out a good way to implement the ArmorLaser without having to create a new actor in the scene. The laser implements similarly to the LeyNode, which I couldn't get around but thankfully there are few enough nodes in the scene.
As for an entire league of pieces of armor on the boss...
Of course, this means directly calling destructors and calling mallocs and frees like it was C all over again. Ugh. UUUUUGH.
As for capstone progress, I looked into a few bugs surrounding the arrow and the StateChangeCube. The first wasn't anything much, as the arrow only looked as if it was directly hitting the object; a slow ricochet means that the arrow hit the ground first and already wasted its state-changing energy.
The actual bug went to the warp effect; when being pulled across the ground, the object had a chance to sweep into the ground (even though the vector may be fully horizontal), so I had to use the implementation to move the object up before warping it.
As for the next implementation, I'm still trying to figure out a good way to implement the ArmorLaser without having to create a new actor in the scene. The laser implements similarly to the LeyNode, which I couldn't get around but thankfully there are few enough nodes in the scene.
As for an entire league of pieces of armor on the boss...
Sunday, January 24, 2016
Day 15: Stronger Than a Stalactite
Good news! Nearly finished up with the Vector implementation; after (1100 lines of testing code), the class is sure to work for all branches of code.
Problem is, I'm not sure what the required implementation of a certain method are. The At method, which originally throws an exception in the STL version if it's above max size, is now required by assignment to only throw if above max capacity. Does this mean we have to initialize all values past size with a default empty value? Hm.
As for capstone, the simplest thing is giving me a helluva time. The Stalactites that are just supposed to drop down and hit the player actually cannot push the character out of the way.
The way physics bodies work for the main character (any character, really) push all physics bodies out of the way with extreme force if the body lands on top of the character.
If there were any tips on depenetrating the character from this mess, I'm all ears.
Problem is, I'm not sure what the required implementation of a certain method are. The At method, which originally throws an exception in the STL version if it's above max size, is now required by assignment to only throw if above max capacity. Does this mean we have to initialize all values past size with a default empty value? Hm.
As for capstone, the simplest thing is giving me a helluva time. The Stalactites that are just supposed to drop down and hit the player actually cannot push the character out of the way.
The way physics bodies work for the main character (any character, really) push all physics bodies out of the way with extreme force if the body lands on top of the character.
If there were any tips on depenetrating the character from this mess, I'm all ears.
Saturday, January 23, 2016
Day 14: Time Warp
Phew! I keep on losing track of the blog at the amount of work I've been doing.
Currently implementing a vector; the dynamic array actually holds a raw pointer to an array, but the juggling implementation with abstraction allows the user to treat it as a dynamically allocated array.
How does a dynamically resized array work? Think of an array with a set capacity but not a set size. To predetermine the amount that is pushed in, one creates an array with a default size as capacity and fills up to a set size. Whenever the size pushes over capacity, the actual array is replaced with larger one (element-by-element copy and new/delete), so it's actually quite an expensive process. Luckily it takes a lot of implementation out of the user's hands.
As for capstone? The boss is afoot! Slightly. The behavior tree has been modified so that the insects are always aware of the player when the boss is present. Think of a hive mind.
Currently implementing a vector; the dynamic array actually holds a raw pointer to an array, but the juggling implementation with abstraction allows the user to treat it as a dynamically allocated array.
How does a dynamically resized array work? Think of an array with a set capacity but not a set size. To predetermine the amount that is pushed in, one creates an array with a default size as capacity and fills up to a set size. Whenever the size pushes over capacity, the actual array is replaced with larger one (element-by-element copy and new/delete), so it's actually quite an expensive process. Luckily it takes a lot of implementation out of the user's hands.
As for capstone? The boss is afoot! Slightly. The behavior tree has been modified so that the insects are always aware of the player when the boss is present. Think of a hive mind.
Thursday, January 21, 2016
Day 12: It's What's On the Inside That Counts
Today'll make for a short post, as I have work to do.
The name of the game is testing if warping is safe. How? The warp has a special effect that conserves height. That said, you don't particularly go back to the warp point, but the same x/y coordinates (Unreal coordinates) at the same z as when you teleported back.
This means being stuck inside an object. Why not just sweep? Stops way too far back. Why not test for overlapping at the site of collision? It is possible to be completely inside an object.
Cure? Multi Line Trace By Channel! Such a magical thing allows line tracing while collecting all the block hits along the way, instead of just stopping at one on a sweep. By tracing the to/from collisions, one can find out if the eventual trip is going to be inside an object.
The name of the game is testing if warping is safe. How? The warp has a special effect that conserves height. That said, you don't particularly go back to the warp point, but the same x/y coordinates (Unreal coordinates) at the same z as when you teleported back.
This means being stuck inside an object. Why not just sweep? Stops way too far back. Why not test for overlapping at the site of collision? It is possible to be completely inside an object.
Cure? Multi Line Trace By Channel! Such a magical thing allows line tracing while collecting all the block hits along the way, instead of just stopping at one on a sweep. By tracing the to/from collisions, one can find out if the eventual trip is going to be inside an object.
Wednesday, January 20, 2016
Day 11: Time Flies When You're Under The Weather
Blargh, being sick again is no good! Thankfully I got my iterator assignment all finished up for today.
The main kicker for today was the iterator; the Find function had to be a constant one (despite returning a non-const iterator) so the members and functions called inside it had to also be constant. This applied back to begin() and end() (which, for range-based for loops had to be lowercase) that also had to be const. That said, the iterators also needed a reference to the owner (list) of the iterator, a const value when one calls this.
Heck, there were pitfalls at every turn. Even on my previous assignment, I completely had no idea namespaces were a requirement (Thanks assignment) so I had to whip that up quickly, along with fixing and refactoring the Node class since it had an extra and unnecessary template <typename T> statement above its header.
As for capstone? The warp function's going fairly well! Just got a mark object (fairy circle? Particle effect? Both?) that appears during each mark and the corrupted effect that maintains height. Just gotta not teleport if it's going to run into anything along the way...
The main kicker for today was the iterator; the Find function had to be a constant one (despite returning a non-const iterator) so the members and functions called inside it had to also be constant. This applied back to begin() and end() (which, for range-based for loops had to be lowercase) that also had to be const. That said, the iterators also needed a reference to the owner (list) of the iterator, a const value when one calls this.
Heck, there were pitfalls at every turn. Even on my previous assignment, I completely had no idea namespaces were a requirement (Thanks assignment) so I had to whip that up quickly, along with fixing and refactoring the Node class since it had an extra and unnecessary template <typename T> statement above its header.
As for capstone? The warp function's going fairly well! Just got a mark object (fairy circle? Particle effect? Both?) that appears during each mark and the corrupted effect that maintains height. Just gotta not teleport if it's going to run into anything along the way...
Tuesday, January 19, 2016
Day 10: Time Flies When You're Iterating
Phew! Today just never stopped being busy. Been implementing an iterator for that singly-linked list I've been working on.
Thankfully the equality operators (==, !=) only apply to the implied node that the iterator holds and not the data itself; user-defined types like the one I had to put in today don't have that functionality.
Heck, I also didn't know "user-defined types" does not refer to typenamed things like int32_t (see <cstdint>) but to classes we make ourselves. I swear, these assignments get shiftier and less clear every day...
As for the current thingamabob I'm stuck on, it refers to the Remove method I've been trying to implement for the singly linked list. If I'm looking to remove an item, where would I stop when checking?
...just got an idea for checking it.node->next! That could work!
Thankfully the equality operators (==, !=) only apply to the implied node that the iterator holds and not the data itself; user-defined types like the one I had to put in today don't have that functionality.
Heck, I also didn't know "user-defined types" does not refer to typenamed things like int32_t (see <cstdint>) but to classes we make ourselves. I swear, these assignments get shiftier and less clear every day...
As for the current thingamabob I'm stuck on, it refers to the Remove method I've been trying to implement for the singly linked list. If I'm looking to remove an item, where would I stop when checking?
...just got an idea for checking it.node->next! That could work!
Monday, January 18, 2016
Day 8: The New And Improved Test Object
Phew! Today marks the end of the Blueprints translation! (For now...)
The main thing today was to ensure the Force that our main character (now named Ines) worked in C++ as well as Blueprints. What I learned the hard way was that CreateDefaultSubobject, which works just fine in the constructor, does not work so well with constructing and calling AddComponent during runtime. Actually, not at all. Oddly enough, just by referencing the handle and constructing it in the constructor, one does not have to actually worry about the actual location of the handle. Grabbing and releasing components only relies on outside parameters. All good and all organized!
As for the TestObject, I also organized a quick C++ object to impose generic state changes on Physics Body objects. There is a bit of an issue on the collision, which I'll have to fix up:
What's next? Actual design: I'm going to build a crumbling bridge...
The main thing today was to ensure the Force that our main character (now named Ines) worked in C++ as well as Blueprints. What I learned the hard way was that CreateDefaultSubobject, which works just fine in the constructor, does not work so well with constructing and calling AddComponent during runtime. Actually, not at all. Oddly enough, just by referencing the handle and constructing it in the constructor, one does not have to actually worry about the actual location of the handle. Grabbing and releasing components only relies on outside parameters. All good and all organized!
As for the TestObject, I also organized a quick C++ object to impose generic state changes on Physics Body objects. There is a bit of an issue on the collision, which I'll have to fix up:
What's next? Actual design: I'm going to build a crumbling bridge...
Sunday, January 17, 2016
Day 7: C++ 1-2-3-4-5...
Yeah, I re-learned today that even the simplest introduction to C++ would be a difficult thing to teach properly. Today was a workshop where I helped introduce people to the wonders (and pitfalls) of Unreal C++, ranging from "don't put anything between the generated header and UCLASS) to spawning Blueprint classes in C++ and forward declarations.
As for actual work, the MasterProjectile is in a workable form! Now I just have to go back and re-do the Shoot Projectile blueprint and the Force wielding that the main character does every now and then. Judging from my progress so far, this Blueprints translation task may finally be coming to a close. That said, we've got a couple of design specifics to finally go off of afterwards! Nothing too large, but they're there!
As for actual work, the MasterProjectile is in a workable form! Now I just have to go back and re-do the Shoot Projectile blueprint and the Force wielding that the main character does every now and then. Judging from my progress so far, this Blueprints translation task may finally be coming to a close. That said, we've got a couple of design specifics to finally go off of afterwards! Nothing too large, but they're there!
Saturday, January 16, 2016
Day 6: All Coming Together
Today was a thankfully focused day to work specifically on capstone work. The notable thing was the furthering progress of the Master Projectile, which once again attaches its effects. The insects and beacon also got their effects repolished. Originally, the insects had a different material to switch to, but to save on expensive material switching, the color could be changed (much like the main character).
The thing is, the insects had a very dark shade by grabbing the original line color. Solution? The material itself! By multiplying by a scalar parameter, one could get the glow back into the insects without compromising the ley line color itself. I also had no idea the beacons themselves still changed color, but it seems there's always a broken thing to be fixed.
Also, another odd thing; looks as if the ActorHit override in C++ gave me issues and not the OnComponentHit, as it were reversed from the Overlap problem I had earlier. The things Unreal Engine 4 does...
The thing is, the insects had a very dark shade by grabbing the original line color. Solution? The material itself! By multiplying by a scalar parameter, one could get the glow back into the insects without compromising the ley line color itself. I also had no idea the beacons themselves still changed color, but it seems there's always a broken thing to be fixed.
Also, another odd thing; looks as if the ActorHit override in C++ gave me issues and not the OnComponentHit, as it were reversed from the Overlap problem I had earlier. The things Unreal Engine 4 does...
Friday, January 15, 2016
Day 5: Being Tired is Tiring
Yeesh, this weekend is just not giving me a break.
1. Finally got the templatized singly linked list working. The only tricky part was determining what to do with PopFront; I was focused on const correctness, but one can't return a reference to something that's about to be deleted, so I had to return by value. I got a good recommendation to actually make the function void to avoid an unnecessary exception when the list was empty.
And...60 tests worked! Woo! Noted that functions that return const values should only have one const in the prototype (const func const durr) and managed to get the assignment finished.
2. The MasterProjectile has gotten more work in its C++ version! Like a nasty recursive function, however, I see more things rely on the Blueprint State Change Interface than I thought. The LeyBeacon, in particular, got the necessary changes since the original MasterProjectile code used it. Yeesh. Yeeeeesh.
Phew, I'm tired. Maybe naptime will fix it.
1. Finally got the templatized singly linked list working. The only tricky part was determining what to do with PopFront; I was focused on const correctness, but one can't return a reference to something that's about to be deleted, so I had to return by value. I got a good recommendation to actually make the function void to avoid an unnecessary exception when the list was empty.
And...60 tests worked! Woo! Noted that functions that return const values should only have one const in the prototype (const func const durr) and managed to get the assignment finished.
2. The MasterProjectile has gotten more work in its C++ version! Like a nasty recursive function, however, I see more things rely on the Blueprint State Change Interface than I thought. The LeyBeacon, in particular, got the necessary changes since the original MasterProjectile code used it. Yeesh. Yeeeeesh.
Phew, I'm tired. Maybe naptime will fix it.
Thursday, January 14, 2016
Day 4: In Which Time Is Short
My apologies! Time is short and so is my ability to blog post!
1. The cross platform project went along almost smoothly, save for a test case I had to take out for now due to C++ native tests not playing nicely with user-defined types.
2. The templated singly linked list is on! Other than some vague feelings I have about functions and return values, I have a fairly good implementation I can start testing (with native C++ and user-defined types...) every possible condition for public methods.
3. I attempted to get some time in for capstone, but today's turn of events unfortunately conspired against anything that results in actual screenshots. C++ MasterProjectile class preview, hopefully!
What's next? I definitely know what I will do to improve time management in the future. (Know when to leave early from talks when work calls)
1. The cross platform project went along almost smoothly, save for a test case I had to take out for now due to C++ native tests not playing nicely with user-defined types.
2. The templated singly linked list is on! Other than some vague feelings I have about functions and return values, I have a fairly good implementation I can start testing (with native C++ and user-defined types...) every possible condition for public methods.
3. I attempted to get some time in for capstone, but today's turn of events unfortunately conspired against anything that results in actual screenshots. C++ MasterProjectile class preview, hopefully!
What's next? I definitely know what I will do to improve time management in the future. (Know when to leave early from talks when work calls)
Tuesday, January 12, 2016
Day 2: OpenGL is a Problem Child
Today was infinitely more stressful due to the issues provided to me by attempting to setup an OpenGL project. Not only was the example limited to x86 processor builds, but CMake does not work for getting the GLFW, a necessary utility library, to make any libraries I need. I'll have to come in tomorrow and beg for a solution.
As for main work today, I found out why the Tracking Crystal was not working for my character for the longest time in capstone: the programming had been snipped in Blueprints! (Gasp) The real reason was that the material that controlled state changes in the character had changed vector parameters, so I had to switch to changing the "Emissive" property instead of the "Color" property. There's still one thing that has me stumped, though; the color doesn't seem to be checking correctly when testing the tracking crystal's color versus the currently colliding ley node color. I tested out the vectors and the colors themselves seem to be completely different. It's quite odd. Unfortunately, I won't have too much time to resolve the issue until I get this OpenGL problem child fixed up.
On the bright side, Game Lab started today! It's a class for promoting non-entertainment, "serious" game design. The EEG work I've been doing applies perfectly to the group project, but I also finished up a proposal to explore games that promote nonviolence and peace, and I know just the games to reflect this teaching.
As for main work today, I found out why the Tracking Crystal was not working for my character for the longest time in capstone: the programming had been snipped in Blueprints! (Gasp) The real reason was that the material that controlled state changes in the character had changed vector parameters, so I had to switch to changing the "Emissive" property instead of the "Color" property. There's still one thing that has me stumped, though; the color doesn't seem to be checking correctly when testing the tracking crystal's color versus the currently colliding ley node color. I tested out the vectors and the colors themselves seem to be completely different. It's quite odd. Unfortunately, I won't have too much time to resolve the issue until I get this OpenGL problem child fixed up.
On the bright side, Game Lab started today! It's a class for promoting non-entertainment, "serious" game design. The EEG work I've been doing applies perfectly to the group project, but I also finished up a proposal to explore games that promote nonviolence and peace, and I know just the games to reflect this teaching.
Monday, January 11, 2016
Day 1: Tabula Rasa, and Bugs Can Be Fun Sometimes
Phew! Today marked the first day of the new semester, and we've already been throttled into a new assignment. This one is a skeleton project that relies on a cross-platform and multi-configuration build of DirectX and OpenGL on x86/x64 for both Debug and Release configurations. Yeesh. Luckily they only required a blank window to be shown, so I flexed my previous know-how from studying DX11 and DX12 and got ahead of the game. Behold! A blank screen:
As for the capstone work, I've been working as much as I can to translate as much of the code I can. A lot of it is taking mildly incomprehensible variables and making sense of them in optimal programming contexts. Let's say that it took a bit too long to figure where the UPhysicsHandleComponent header (PhysicsEngine for you future lookers!) was located. That said, I also found another bug that was actually rather humorous: when someone picked an object up, they could pick up "unmovable" objects like the Mystic or Endless Move Object:
Fortunately I actually have a team I can use to fix this!
As for the capstone work, I've been working as much as I can to translate as much of the code I can. A lot of it is taking mildly incomprehensible variables and making sense of them in optimal programming contexts. Let's say that it took a bit too long to figure where the UPhysicsHandleComponent header (PhysicsEngine for you future lookers!) was located. That said, I also found another bug that was actually rather humorous: when someone picked an object up, they could pick up "unmovable" objects like the Mystic or Endless Move Object:
Fortunately I actually have a team I can use to fix this!
Sunday, January 10, 2016
Lost In Translation
Good news! Today was a difficult task, but I managed it. The InsectCharacter originally used the Blueprints State Interface, but with the successful use of the C++ State Interface, one can inherit methods like in the previous interface. Unfortunately, I remembered that data members cannot be inherited via an interface, so those have to be placed in each class that inherits them. Ugh.
So far, the functionality works smoothly and the InsectCharacter has no more Blueprints coding inside of it. Problem? Translating the rest of it to work nicely with the InsectCharacter. Green arrows turn insects blue until the enumerations match:
Everything is very tightly wound around each other (Coupling? YOU BET) and will require a careful step-by-step process to fully remove the Blueprints from everything. And I mean everything:
It might be a bit longer than previously expected.
So far, the functionality works smoothly and the InsectCharacter has no more Blueprints coding inside of it. Problem? Translating the rest of it to work nicely with the InsectCharacter. Green arrows turn insects blue until the enumerations match:
Everything is very tightly wound around each other (Coupling? YOU BET) and will require a careful step-by-step process to fully remove the Blueprints from everything. And I mean everything:
It might be a bit longer than previously expected.
Saturday, January 9, 2016
State Change Interface
Today juggled a couple of things: assistance, failure, and mild success!
Assistance: I helped my classmate get ahold of some proper source control so he could clone the repository he and I were working on. Unfortunately, the HTTP access to repositories is extremely slow and results in a slew of timeout errors, so I made the jump to SSH for a lengthy, but successful clone. Success!
Failure: Looks as if I'll have to hold off C++-translating the AI blueprints for now. In the main service (aggravation checks), basic functions like clearing blackboard values and actual tick events are too much for C++ service classes. Baffling.
Success! Again: I did, however, manage to figure out how C++ interfaces worked with Unreal, and managed to create a spitting image of the StateChangeInterface. With that step, I'll have to figure out how the functions derive from that interface...
Assistance: I helped my classmate get ahold of some proper source control so he could clone the repository he and I were working on. Unfortunately, the HTTP access to repositories is extremely slow and results in a slew of timeout errors, so I made the jump to SSH for a lengthy, but successful clone. Success!
Failure: Looks as if I'll have to hold off C++-translating the AI blueprints for now. In the main service (aggravation checks), basic functions like clearing blackboard values and actual tick events are too much for C++ service classes. Baffling.
Success! Again: I did, however, manage to figure out how C++ interfaces worked with Unreal, and managed to create a spitting image of the StateChangeInterface. With that step, I'll have to figure out how the functions derive from that interface...
Friday, January 8, 2016
Getting Back in the Action
It's been a couple of days, and due to transitioning from job to school and no server access with Forticlient I've been unable to really work on anything the past few days. The horror!
Luckily I got the client setup just fine and found out some interesting news involving the transition from Blueprints to C++ with the InsectCharacter AI. The first part is that the C++ AIController works! It's a suitable vessel from which to hold the blackboard and behavior tree components separately from the C++ code.
As for the services, it was a bit tricky to figure out. Technically services derive from UBTService_BlueprintBase, which is heavily not recommended (not allowed, no-go) for native C++ class making. Problem is, the "Event Receive Tick" node that the entire service relies on each tick is not implemented in the other UBTServices. Luckily, the UBTService has a method that can be treated as a Tick, the OnSearchStart method. Each time the tree is searched through (Tick-tick-tick), the insects treat this as the service as necessary. By logging the data, I was able to see the action without translating everything to C++, so I'll get to translating it soon.
Luckily I got the client setup just fine and found out some interesting news involving the transition from Blueprints to C++ with the InsectCharacter AI. The first part is that the C++ AIController works! It's a suitable vessel from which to hold the blackboard and behavior tree components separately from the C++ code.
As for the services, it was a bit tricky to figure out. Technically services derive from UBTService_BlueprintBase, which is heavily not recommended (not allowed, no-go) for native C++ class making. Problem is, the "Event Receive Tick" node that the entire service relies on each tick is not implemented in the other UBTServices. Luckily, the UBTService has a method that can be treated as a Tick, the OnSearchStart method. Each time the tree is searched through (Tick-tick-tick), the insects treat this as the service as necessary. By logging the data, I was able to see the action without translating everything to C++, so I'll get to translating it soon.
Tuesday, January 5, 2016
Spiral Twister
Today was the chance to implement a neat little feature to TrailConverge, along with fixing a few bugs. Remember! Always have a subscriber attached to a button and focus on curbing velocity on the floating objects to keep them from escaping Earth's atmosphere.
As for the feature, it's an extension of the circular pathways on the trailing objects. When enough rewards are accumulated, I triggered a set of two coroutines to move the objects back and forth along the Z axis. Usually there's nothing too interesting about it, but combined with the circular movement it produces a neat spiral effect:
To truly illustrate the effect, I also whipped up a quick script that allows the camera to follow a sequence of dynamic positions and rotations to see the spiral in better view as it converged. The interpolations were linear for both, as this specific linearly interpolates camera angles without Gimbal Lock. If need be, I can always update with a Slerp if things get crazy.
Also, the previous skybox was a bit gloomy, so I felt the stars in the sky (especially with the revolving planet look) would have been more suitable.
As for the feature, it's an extension of the circular pathways on the trailing objects. When enough rewards are accumulated, I triggered a set of two coroutines to move the objects back and forth along the Z axis. Usually there's nothing too interesting about it, but combined with the circular movement it produces a neat spiral effect:
To truly illustrate the effect, I also whipped up a quick script that allows the camera to follow a sequence of dynamic positions and rotations to see the spiral in better view as it converged. The interpolations were linear for both, as this specific linearly interpolates camera angles without Gimbal Lock. If need be, I can always update with a Slerp if things get crazy.
Also, the previous skybox was a bit gloomy, so I felt the stars in the sky (especially with the revolving planet look) would have been more suitable.
Monday, January 4, 2016
Trailing Through
Yeargh! Our connection via Forticlient is somehow denying me access to my work on the Perforce server, so I can't get back to capstone working just yet.
As for work today, my supervisor is currently catching up with suggestions and feedback, so I only found enough work to make a different application, the Trail Converge application.
The original idea was to create a set of objects that utilize a line or trail as they moved across. This was ideal for the Trail Renderer, which draws a set of particles that trail behind the object as it moves. There's also the problem with the possibility of infinite traveling, so I decided to implement a more mesmerizing circular movement to keep track of the objects.
The main reward of the application was to converge the paths of the objects. By setting the cosine and sine of the objects, one could follow a circular path that could converge to a set target radius. Since the application looks a little better with smoother transitions, I also setup an interpolation for those objects to reach that smoothness.
The same thing applied to the line width, in which the line width of the objects would smoothly interpolate over set values over time. Unfortunately today was a bit straightforward, so I can only show pretty things moving to the beat of a reward event:
What next? Hopefully I get some more feedback and suggestions so I can continue further before FIEA starts. I get antsy when there's no huge undertakings and I have to enjoy a winter break.
As for work today, my supervisor is currently catching up with suggestions and feedback, so I only found enough work to make a different application, the Trail Converge application.
The original idea was to create a set of objects that utilize a line or trail as they moved across. This was ideal for the Trail Renderer, which draws a set of particles that trail behind the object as it moves. There's also the problem with the possibility of infinite traveling, so I decided to implement a more mesmerizing circular movement to keep track of the objects.
The main reward of the application was to converge the paths of the objects. By setting the cosine and sine of the objects, one could follow a circular path that could converge to a set target radius. Since the application looks a little better with smoother transitions, I also setup an interpolation for those objects to reach that smoothness.
The same thing applied to the line width, in which the line width of the objects would smoothly interpolate over set values over time. Unfortunately today was a bit straightforward, so I can only show pretty things moving to the beat of a reward event:
What next? Hopefully I get some more feedback and suggestions so I can continue further before FIEA starts. I get antsy when there's no huge undertakings and I have to enjoy a winter break.
Sunday, January 3, 2016
Raindrops Also Keep Falling On My Head
Today was a bit of a shaky day, as I had to pave a lot of my tasks due to not getting any feedback on my previous work from the 1st.
To go with the idea of gradually adding effects, or special effects that came in turn with a certain set of rewards (or lack there of), I came up with a rain effect. The rain effect relies specifically on the amount of clouds covering the sky and how dark the clouds are, utilizing stretched blue billboards for a neat little rain effect to really drive it home when somebody doesn't get it right:
I also dabbled in some more user-friendly portions with a tooltip, a single image that takes on a specific text saved by all of the buttons whenever a Pointer Enter (hover event occurs). Luckily Unity has a cross fade alpha method instead of me having to build it from scratch, but I learned some tricky restrictions with UI events, including functions taking a single, non-class, non-struct parameter. No Vector2 was allowed, but strings and ints are just fine.
As for my next step? It'll involve a magical trail renderer and getting it to extend all the way to the ball that produces it:
To go with the idea of gradually adding effects, or special effects that came in turn with a certain set of rewards (or lack there of), I came up with a rain effect. The rain effect relies specifically on the amount of clouds covering the sky and how dark the clouds are, utilizing stretched blue billboards for a neat little rain effect to really drive it home when somebody doesn't get it right:
I also dabbled in some more user-friendly portions with a tooltip, a single image that takes on a specific text saved by all of the buttons whenever a Pointer Enter (hover event occurs). Luckily Unity has a cross fade alpha method instead of me having to build it from scratch, but I learned some tricky restrictions with UI events, including functions taking a single, non-class, non-struct parameter. No Vector2 was allowed, but strings and ints are just fine.
As for my next step? It'll involve a magical trail renderer and getting it to extend all the way to the ball that produces it:
Friday, January 1, 2016
Clouds Keep Falling on My Head
Today was a day to tackle another possible application - The Weather Changer! (Or just Weather; still thinking of a good title). The most difficult part of this (which I also tackled last night) was the cloud covering; I'm still not quite used to a cloud system in Unity (50 bucks for volumetric clouds? naaah) so I worked on a horizontal particle system of stretched billboards to get a general feeling of weather:
I also worked on varying both the emission rate (cloud cover) and the colors of the clouds over time. The tricky part of this one was determining how the emission rate is changed in the latest version of Unity; the emissionRate variable is now obsolete, forcing the access of emission (read-only) with a writable rate value. That rate value is actually a MinMaxCurve struct that required instantiation and assigning of a completely new struct. Hacky, but it works.
Combining it with accessing the exposure of the skybox (in a similar script to the SkyChanger) allowed a separation between dark and stormy:
To light and sunny:
The "Thunder" and "Sunny Day Sound" modules also got a chance to counteract each other's sounds with an optional list on the sound cue scripts that allow stopping of opposing sounds when events start.
What next? Rain, perhaps! And I'll also see how to integrate tooltips to make the system easier to navigate.
I also worked on varying both the emission rate (cloud cover) and the colors of the clouds over time. The tricky part of this one was determining how the emission rate is changed in the latest version of Unity; the emissionRate variable is now obsolete, forcing the access of emission (read-only) with a writable rate value. That rate value is actually a MinMaxCurve struct that required instantiation and assigning of a completely new struct. Hacky, but it works.
Combining it with accessing the exposure of the skybox (in a similar script to the SkyChanger) allowed a separation between dark and stormy:
To light and sunny:
The "Thunder" and "Sunny Day Sound" modules also got a chance to counteract each other's sounds with an optional list on the sound cue scripts that allow stopping of opposing sounds when events start.
What next? Rain, perhaps! And I'll also see how to integrate tooltips to make the system easier to navigate.
Subscribe to:
Posts (Atom)