As stated in my proposal, I wanted to create an itch.io page for my outcome as another means of presenting my work. I wanted to do this specifically because I think itch.io is a really good way to easily put my work out to the public and create interest on my skills and outcomes.
Even though my outcome isn't exactly a full game like I originally thought it would be, the experience I've created still effectively showcases what I've been able to create and highlights my programming and design skills. This is important to me because I'm interested in pursuing work in the games industry, and by creating this page I'm creating something I can put into a portfolio or show someone to who may be interested in what I'm able to create.
Mass Collection Prototype
I've created multiple itch.io pages in the past so this wasn't a new experience, but I did have noticeably less to put onto this page in terms of banners, backgrounds and profiles. This makes sense though because what I've created doesn't have anything like that- it was a pure focus on programming and design.
As of today, all my development goals are completed to the minimum quality I'm happy with. This perfectly aligns with my plan for this week, and I'm really happy I was able to include things like Niagara effects despite seeing them as such a challenge while still getting everything else done.
Comparing my final outcome to my research and inspiration, I think I definitely matched the vibe that the Insomniac Museum had, of intruige the reading about cut and behind-the-scenes content gives to a player. It's defintely far from the quality of something like Assassin's Creed's Discovery Tour, but I obviously have to consider the difference in production time/team between my outcome and theirs.
With that all in mind, I am happy to put a pause on development and spend the next and final week getting everything ready for submission.
Because my presentation is partly about the collectables having customizability, I knew that I needed at least more than one Niagara effect to properly present them within my system. Alternatively, or even adjacently, I wanted to be able to change the color of the Niagara system to also give the player customization.
Luckily, there is another default template Niagara system, ConfettiBurst, which I added to the array:
Note how there's also a "None" option here, which does exactly what it says. I wanted to keep the option to have no particle system because having that actually gives the player more customization versus forcing them to use a Niagara system.
However, and I didn't know this at the time, but having this directly conflicted with adding color customization. I was working with a peer who showed me that I could create user exposed variables in a Niagara system and use the Set Color Parameter node to change said variable:
And this worked for the Omnidirectional Burst, but there was a problem. The confetti burst doesn't use a color, and instead uses a material:
And even more annoyingly, I can't seem to create my own materials to be used in here either.
The limited time I have left makes me believe it's not worth it to try and find a solution, and I should just take what I have and is working instead of trying to find solutions that may break what I have. In any case, what I have here currently is working in game so I'm content with that.
Unreal Engine: adding a Niagara effect to my collectable
After being told that Niagara was a possibility in the time I had left, I wanted to venture into the system and see if I could add it in a customizable way to my collectables. This is in response to direct and indirect feedback suggesting the use of Niagara in my project:
Based on this feedback I want to create a small particle explosion, some kind of small burst coming from the collectable because that's what some testers had suggested.
To start, I just added a Niagara effect into my project and was presented with multiple presets for options. Some were tutorials, and others were presets. With time being such a large concern I went with a preset- omnidirectional burst:
And in the editor it looked like this at it's apex:
I wasn't really a fan of this. The gravity was unappealing and it was way too massive to be spawning on each collectable, so i looked for settings related to gravity and size.
Gravity was easy enough- it was just a toggle in the main node of the Particle System. I also disabled drag to stop any unwanted outside forces:
For the sprite size I had to click on the Particle Spawn column and from there I could adjust the minimum and maximum lifetimes of each particle:
Now I had a result I was more happy with:
Now I just needed to spawn it in.
After talking again with the peer that suggested I used Niagara, I found two potential nodes to spawn them in on collection:
I wanted a fire-and-forget approach to this, and the system needed to remain after the collectable was destroyed, so Spawn System at Location was the clear winner here. This is because by using the Add Niagara Particle System Component node, I'm binding that particle system's existance to the collectable actor. If it gets destroyed, so does the particle. Then I just attached that onto the end of the collection code:
And of course by making it an instance editable variable I was easily able to turn this into a customizable button:
This was the result, Both before and after I had changed the particle system's appearance:
Before:
After:
And this was good, but I wasn't immediately happy with the look of it. Some of the collectables were spawning a bit disjointed from the player. I knew I wanted them to spawn on the player, but I also knew that having them spawn in the exact same place every time would look both repetitive and static, so I combined both the player and collectable coordinates:
Adding another debug command to the optimization level
Based off of playtest feedback, one respondant wanted to see just how optimized my end result really was:
I thought this was both a valid and interesting route to take to improve my outcome, so I looked into all the debug commands I had used so far in this project to see if any were relevant enough to place in my optization world. I eventually landed on Stat GAME, which is a breakdown of the game thread:
So I added this into a new button:
You'll notice how this is different to how I was doing it before, and this is because I changed these debug buttons have a parent class which executes the actual Execute Console Command node, and the children simply set which one they wish to set:
And since these were technically string inputs, so I wanted to make them in line with my other buttons and make them pink in color:
I did then follow up with the playtester that requested this kind of addition, and they did appreciate the inclusion of the game thread, even if it was a bit confusing to understand. With that and the changed visuals, I'm actually really happy with what I've done here and think I've made a positive change.
This the last addition to my spawner system based on feedback - a new material. Going with the coin theme, I decided to go for something shiny and yellow, which was easy enough as this just required me to alter 2 variables in the material graph:
I then realised I didn't have an actual yellow shader, so I also went and quickly created one:
This was the result:
All together, my additions created another cohesive kind of collectable which I'm really happy to see. I'm hoping that this is sufficient enough to create a more interesting experience, although I don't think I'll have time to playtest it.
Building off of my last audio addition and playtester feedback, I thought it was fitting for my new model to be a kind of coin.
Looking back into model libraries again, I first found this basic low-poly model of a coin which looked great for what I needed:
Coins Animation | OpenGameArt.org
But after importing it into Unreal engine, I noticed how the model was incorrectly centered:
This makes it completely unusable, because the origin of the model is used for location and physics calculations and they wouldn't work with the location of this coin's origin.
With that in mind, I kept looking for another similar model and found this one:
Low poly coin 3d | OpenGameArt.org
This one looked similar and it's origin was centered:
Now that I was happy with this, I easily added it into the static mesh list:
And this is the result:
There's not a lot to say here, but they work and they do look good, so I'm happy with the result.
To improve my customization system, I want to add new sounds to the customization system. I am making this addition in direct response to playtester feedback:
It is worth noting now that because my end outcome has changed from an expandable linear level to a pure showcase, I don't really have a desire to take the project any further once the showcase is in it's best state.
This contradicts with my previous ethical concerns about using copyrighted assets because I am now not using them for anything that could ever be for-profit. As such, I felt it right to actually add the Ratchet & Clank bolt sounds and meshes into the customization options.
I still didn't think that was enough sounds though. Knowing that I didn't have time to create my own sounds, I again went to looking for sound effects online.
I decided to search for simple plingy sounds, as I felt that met my standards for what I previously decided would be an acceptable sound. After some looking I came across this:
Plingy Coin | OpenGameArt.org
And this sounded ok, but there's only one sound effect. I've mentioned previously how I want a variety of similar sounding sounds in each set to further make each collectable sound unique along with pitch shifting.
I did like the coin sound though, so my next search was into similar sounding coin noises, where I then found this pack of noises:
10 8bit coin sounds | OpenGameArt.org
And this was exactly what I needed. Obviously ten sounds was a bit much- my system only uses three- but the three I did choose were similar enough sounding to where I hoped they would be cohesive when picking up lots of collectables.
This was the result:
Of course the bolts sound really good, given how they were from another collectable. The coin noises also work well here, but I did go back and lower their volume slightly to reduce that unsatisfying amalgamation of sounds when I picked up a lot of them at once.
Today is all about putting in changes based on my playtesting feedback, and then using my remaining time for polish and quality of life (QOL) additions.
My specfic goals for today are as follows, in order of importance / ease of implementation:
at least 1 new customizable option for each category at the end of the museum
Look for more debug settings I can give to the player in game
Compared to the goals I set today- I have done everything except the iteration on my playtesting. That should be really easy though- I've already said what most of the changes should be in the blog itself. I'm feeling pretty confident that I'll be able to keep with this plan so I don't need to make any changes to it.
One concern I had with my idea of a largely text-based museum was including typos, so I included this question to help me get rid of them all. One responder mentioned how the playtest text was outdated, so I need to make sure to go back and fix that.
What concerned me here though was response #5, which after following up with the playtester tells me that they believed the spelling of collectable was actually collectible. I immediately needed to double check this because I had never been corrected on this in the past, and found a few conflicting sources:
Collectable and collectible are easy to confuse. What is the difference between collectable and collectible? Collectible is something a coll
When should you use collectable vs. collectible? Examine their meanings and learn when to use collectable or collectible in a sentence.
Both of them mention the exact opposite definition of both spellings, and both claim them as valid spellings, so I don't see a reason to change my spelling.
This sounds like a stupid question, but I needed to make sure that player's knew what I was presenting them with and that they weren't just cluelessly experiencing something. Fortunately the things that I've already included seem to be enough to get my points across, so I don't see any needed changes here.
I definitely could have worded this question better to split up my questioning of the player's general understanding and my questioning of the development of the collectables, but the overwhelmingly positive response here (even to a playtester that's not familiar with programming terminology) is really good to see. This tells me there's potentially some room for some better wording / more clarification, but it's not anything essential.
there's definitely an overall theme with these responses: the use of text is a good way to present my work & make the experience understandable, but it can be a bit dull. My biggest takeaway here is that it would be beneficial to work on making the text more interactive or adding more things for a player to do.
This question I was equally shocked and happy to see the response to- I honestly thought my museum would be a lot less appealing to most people. However it's important to note that these responses conflict with the previous question's responses, so I think making my experience more engaging is still a priority.
I think these responses show the same thing as the last two questions- my museum is definitely passable, but there's a tiny bit of room for improvements to the interest and engagement it gives a player.
This question actually gives me some actionable feedback, and I want to look through each one to see how feasible they are in my little development time.
Response #1 & #6- These are similar responses, and they are by far the easiest and quickest things to add, I just need to find/create more sounds and add them to a new sound array.
Response #3: this mentions more ways of testing the limit of the collectables performance. I'm not really sure how I could do this safely (i.e. not freezing the game), unless I perhaps added a hard cap to the amount of collectables allowed to exist, but I think that would much more boring and actually prevent this kind of limit testing. What I could do though is look for a few more debug settings - even if I didn't specifically use them - and allow the player to play with those.
Response #4: This would involve adding Niagara to my collectable destruction, which I previously thought to be too time consuming of an addition. However, after speaking to a peer of mine and seeing the use of Niagara in their own project it is a lot easier than I had assumed, so there might still be time to implement this.
Response #5: This didn't make a lot of sense to me initially, so I tried to follow it up with the playtester and they admitted it was an unnecessary response with no meaning, so I can safely ignore this.
Response #7: This does sound like a cool idea on paper, and a boundary-breaking camera would feed into the idea of a behind-the-scenes kind of presentation, but truthfully I know that there really isn't a lot to see with that kind of camera. While this would be cool, the engagement payoff for the amount of time it would take to get that kind of system working well is not worth it.
Making sure the Execute Console Command node works
Something I hadn't considered when implementing the debug buttons in my optimization world, is whether or not they would actually work in a built version of the game, as they are development commands after all.
I knew there were different kinds of building options, one for development and one for shipping, but I didn't really know what made them different:
So I did some research into the Execute Console Command node itself, and the packaging types:
While implementing some more text into the museum, I had a really interesting idea- what if I let my player explore my testing levels? I thought this might be a cool idea because the Insomniac Museum in Ratchet and Clank 3 actually does a similar thing where it let's you drive around in an unfinished racing level (10:10 in the video):
And I already had the functionality to do this implemented from my own testing processes- I just needed to let the player know they existed. I did this in the form of a text box at the end of the museum:
And this would have been fine, but I thought I could make it even better by treating each level like it's own "exhibit" and giving them some contextual text:
And as another really easy addition, I created some more buttons that gives the player access to some debug commands I used like the framerate and framerate breakdown, using the Execute Console Command node:
And then placed them in the optimization world:
I'm really happy with the outcome of this. In such a small amount of time, I added 3 more bits of interesting content for a viewer of the museum and they all help to expand the context in which I created my collectables in. To really see if that's true though, I still need to get playtesting feedback.
My goals for today still remain the same as yesterday:
add the rest of the text boxes
add the update-on-change collectable (DONE)
playtest the museum
iterate on the feedback
I'm hoping that I can get the text boxes and playtesting done today, giving me as much time as possible to refine this museum into an interesting and engaging experience.
I managed to complete my collectable updating system today to a degree that I'm happy with after comparing it to my references. And while I did add a few more bits of text the the museum, I think it's still missing a few more details into the creation of my collectable system. I think that I'm still on track to add those and get playtesting done with time for feedback consideration, so I'm happy with where I'm at.
I wanted to implement this system because it mimics the way the particle editor in the Insomniac museum worked- every change was applied immediately.
Of course my system is slightly different- instead of a constant effect I have instances of my collectable which are harder to update. I could get every collectable instance and then update them:
But not only does this look awful in the blueprint graph, it doesn't let the player see what the collectables looks like in motion without picking them up and then respawning them manually. I really wasn't a fan of this approach. I instead wanted a system that would respawn the collectables with each change.
So again, after some thinking, I decided that I could iterate through all the collectables in the level and just destroy them before spawning them anew. All I needed to do was add this code to the parent button:
And it seemed to work fine, however a peer of mine had overseen me using this code solution and strongly suggested that I use a Reverse For Loop node instead- as they had encountered issues with deleting actors in a list using my above method.
They explained that by destroying the actor at the most recent index, every index in the list would move up by one and cause pointer issues.
Both solutions worked and I had no reason to not trust my peer- their logic was sound - so I implemented the change and this is the result:
And I'm really happy with how it looks. Compared to the Insomniac Museum, I think I've taken what made that cool and interesting and applied in a way that works with my collectables. I don't think any changes are needed here- I can finally call this system done.
Using the same logic from my last post, I made the crates respawning to solve the same problem the demo collectables posed:
And this had a fine result, but while testing I realized that the crates were having a crazy impact on my performance, in terms of framerate:
After looking into the crate's code, I realised it was because I had them spawning 100 collectables *each*:
This was far out of my performance goal of 75 collectables at the maximum (stated here), so I massively decreased this to keep them in line:
These crates now gave me much better performance, and I'm still happy with the feel of them:
Obviously less collectables doesn't feel as good to collect, but I think the satisfaction is still there. And this is totally something I can get feedback on with my playtesting, too.
