After the university’s transition to remote instruction starting the week before, these two weeks were entirely conducted online through Discord communication. In addition to regular pod lead responsibilities, my work focused on implementing previously created VFX as we near the end of our project work time (and the end of the semester).
Week 1 — Pre-Beta 2
On Monday I spent some time creating new Jira tasks for the next two weeks. These were:
- David: A shader to create a mysterious, shadowy effect. This could be applied to all the enemies.
- Zena: A shader and particle effects for the crumbling block hazards.
- Eli: Finish finalizing art assets for the teleport reticle.
Planning upcoming work
The next day I was asked by Nico to draw up a list of “High Impact Effects” to guide thinking for the remainder of VFX in the project. These were:
- A damage effect for when the player gets hurt.
- Particle effects for when the player dies.
- Some trail or motion effect for enemy movement.
- An item pickup effect (scrapped).
- Environment passive effects, such as the sunbeam effect I already was working on.
Finishing sunbeam shader
On Wednesday I completed my work on the sunlight shader, to the point where it is ready to be merged in. The main work I did that day was adding in properties visible in the error to control left and right fade. With fading like this implemented, the concerns I had before about how the sides would look are addressed.
I posted the results of my work in the #art-drafts Discord channel and got very positive feedback from the leads in particular. Everyone seemed to really like how my effect looked and the realism it would add to the game environment.
Conversions from VFX Graph to built-in particles
After it was finally determined the previous week that Unity’s VFX Graph is not compatible with our project and the LWRP, later on Wednesday I got around to taking the remaining effects that were in VFX Graph and converting them to built-in Unity particle systems. None of the VFX pod members had actually created any effects in VFX Graph for better or for worse, so the only effect to convert was the enemy projectile effect, one I had made.
It took some time into Thursday to get the new version of the effect to look close enough to the way the old one did. I had trouble dealing with different conflicting properties of particle systems such as scale vs. size and speed vs. velocity. Eventually I got to the point where I was satisfied with how the effect looked in merged in my changes. At this point I was able to completely remove VFX Graph from the project now that we were not using it anymore.
Teleport sphere animation
Later Thursday I started work to integrate the teleport effects Eli had worked on into the project since he does not have as much Unity experience to feel confident completing the job. This work ended up taking a lot of my time for the remainder of these two weeks.
After initial talks with him I determined the main two effects to be added were an animated version of the magical sphere sprite he created, and a recycling of the dissolve/materialize particle effect that Zena made a few weeks ago.
That day I worked on getting the animated version of his magical sphere sprite (which really looks like a portal). As he only gave me individual PNG files for each frames, I had to do the tedious work of arranging and aligning all 60 of them into an 8x8 grid in Photoshop. With this exported I was able to create a particle system in Unity where I used this grid as a “flipbook” so it would be animated.
The effect looked nice, but since Eli created so many frames for the animation it takes 2-3 seconds to play at an appropriate speed. Unfortunately in the game the teleport action happens so quickly that the animation needs to be much faster than this, more like 0.5 seconds or less. At this speed though the animation goes so fast you can no longer appreciate any of the details that Eli put all of his effort into. As of the April 5th meeting I still have not decided what to do about this, and am afraid that with it being so large and distracting anyway the effect may be scrapped.
Meanwhile for the materialize/dematerialize effect, I started planning on Thursday but realized the same issue from way before still existed. Unity particle systems can only emit from single sprites, but the player sprite is made up of many smaller individual ones for each body part. In addition each of these are animated via a rigged skeleton, and none of these animations seem to transfer to what particle systems pick up on.
I couldn’t come up with an answer this week, but returned the following week and eventually arrived at a solution.
Crunch for Pre-Beta build
Starting on Friday night I got more frantic communication from the other leads and our producer asking for a list of tasks to be completed for a weekend built to be made that night. For my pod I was asked to have both the enemy death VFX Zena made and the sword slash VFX I made implemented in the game, two tasks I was still blocked on. I conversed with each of the relevant pod leads for those tasks, 1) the enemy prefabs were still not made and 2) the final sword sprite was still not in the game, so I could not complete either task.
Finally on Saturday George did completed the sword sprite swap so I was able to push the sword slash animation. I exposed variables for the rotation of the effect for each of the up, netural, and down attacks. Within the code I wrote the script lerps between these angles to match the BlendTree that controls the attack animations.
Posting my work on Discord I got positive feedback from George and others.
Retro meeting 3/28
At the leads retro meeting all of us playtested the build made the previous night and then went into weekly updates and discussion. Nico, our producer, was worried about Jira tasks not being marked as done by the deadline and members not utilizing Jira as much in general, though in my pod I think it has been used well.
Studio meeting 3/29
At the studio meeting all of the members playtested the weekend build, and afterward I conducted a very productive pod meeting. David screen-shared his progress on the enemy shadow effect with very cool results. In the end he opted to create a unique material for each of the enemy types, but since this gave them each a more individual look I think that was a good choice. After that Zena went in depth on her work for the crumbling block shader and the other pod members and gave guidance on potential noise functions to choose, for example. Finally, Eli showed us his finalized reticle and mentioned having created a glowing effect that he thought could be used elsewhere.
Total time breakdown for Week 1:
- 0.5 hours: Creating new Jira tasks
- 0.5 hours: Creating list of “High Impact effects”
- 1.5 hours: Finishing sunbeam shader
- 0.5 hours: Merging stalactite particles
- 2.5 hours: Converting VFX Graph effects to built-in particles
- 2 hours: Animating teleport sphere sprites
- 1 hour: Communicating with leads on blocked tasks for weekend build.
- 1.5 hours: Leads meeting
- 1 hour: Implement sword slash VFX
- 2 hours: Studio meeting
Total this week: 13 hours
Week 2 — Pre-Beta FINAL
The next week I focused heavily on trying to implement the dissolve/materialize effects for the player while teleporting. This ended up being a much more involved task than I expected and required devising a rather nontrivial solution.
After a break on Wednesday I started work again on the teleport VFX. After thinking about it more and talking with Nico, I decided to try using a second camera that would capture the sprites as they appear onscreen since there are so many of them and I needed the exact pose of the player at that frame (including the scarf which isn’t even a sprite). This solution allowed me to do that by having the second camera only render the layer in which these player objects (and nothing else) reside.
I referenced some code online on how to capture an image from a camera like this, which directed me to try saving my output as a PNG which I set as the sprite for emission in the materialize VFX particle system. Surprisingly having a second camera did not seem have any noticeable performance effects, but evidently reloading the PNG to use it in the particle system did. When I shared my work with the other leads they agreed that this wouldn’t work. I wondered if downscaling the image might help but took a break until the next day.
On Thursday, I tried to downscale the image but discovered that
Texture2D.Resize() does not downscale the image content but only changes the texture size itself (the canvas size). Apparently Unity doesn’t have a built-in function to downscale content, and though I found some plugins that use bilinear interpolation I didn’t want to have to add anything to the project so I looked for another solution.
After some experimentation, I discovered that I could just save the image to a pre-existing Texture2D directly instead of exporting out to a PNG. As this Texture2D would already be linked in the particle system everything would be connected. Surprisingly this actually worked for me. The only hitch was that Unity apparently creates particles for the entire captured image (the entire screen) instead of just the visible player sprites like it was with the previous method. This means that in order to get enough particles to appear in that region I have to spawn close to 20,000 of them. This didn’t seem to cause any performance drops for me but I wonder if it might on a less powerful computer.
I posted the results of my work and the others in the studio seemed very excited about the way it turned out.
Crunch for Beta Build
On Friday Nico released another set of tasks that he wanted done quickly for official Beta build that would be sent out to our industry supporters. The two VFX tasks he wanted implemented were the enemy death VFX that didn’t get implemented last time, and the enemy shadow shader David worked on.
David had reservations about declaring his work finished since he was still investigating a flame-like effect that would extend outside of the bounds of the original sprites. Since out-of-bounds effects like this aren’t possible in Shader Graph he was understandably running into trouble. I convinced him though to at least put out the shaders he did have so they could be put into the Beta build and he got this done. David has always been very good about getting his own work done and implemented on his own as he did this time, which makes much less work for me. :)
Meanwhile I worked on implementing the enemy death VFX. Originally I thought I was going to use the same approach as the player teleport dissolve VFX, but this quickly became unreasonable as I would need a separate camera for each enemy. Instead I came up with a much simpler solution that just uses static sprites. This works both because the enemies each contain one large body sprite that I could work with, and because the death VFX creates a large cloud of smoke that hides the fact that the emission shape may not perfectly match the sprite onscreen. The effect was fine in the end but I was a little disappointed since if I had known the quick and simple solution would work I would have let Zena handle the implementation herself.
Both effects were merged in and appeared in the Beta build.
Retro meeting 4/4-4/5
Nico called the leads meeting early on Friday evening to focus work on preparing for the Beta build. Despite this, the focus of the meeting actually turned to long-term discussions on ways to improve for the next semester and be more effective leadership. The next morning Nico reached back out on Discord for a more tailored discussion on the remaining tasks for the VFX pod, which I listed in our ongoing list of remaining tasks for development.
Studio meeting 4/5
At the studio meeting on Sunday, everyone did a playtest of the Beta build and gave their own feedback. Afterwards we had our VFX pod meeting where I shared the list of remaining tasks I had made, but due to disorganization or lack of interest I couldn’t get any pod members to actually commit to any of the tasks. This means I’ll have to go in the next few days and solidify the list of requirements for each of them so the pod members feel more comfortable taking on the work.
The player pod lead also reached out to me since there was feedback that the sword slash VFX now looks like it’s not powerful enough and that it doesn’t match the hitbox. This is another task I’ll have to get done soon in this upcoming week.
Total time breakdown for Week 2:
- 3.5 hours : Initial work on teleport VFX
- 2 hours: Finishing work on teleport VFX
- 2.5 hours: Enemy death VFX
- 1 hour: Leads meeting and consultation with David about enemy shader
- 0.5 hours: Discussion with Nico on tasks for the final two weeks
- 1.5 hours: Studio meeting and VFX pod meeting
Total this week: 11 hours
I felt like I got a good amount of work done these past to weeks and made important contributions such as getting the player teleport dissolve effect to work. However, as was touched upon by Nico at the last leads meeting, focusing too hard on doing the work yourself as a pod lead could distract from your responsibilities as a leader. Our pod may actually be in a better state as far as our work is going than others, but I still feel like I may have slacked a little on providing appropriate guiding and direction. At the last studio meeting yesterday I felt fairly disorganized since I felt I hadn’t prepared enough, and thus I didn’t not have enough information to properly assign tasks to everyone. In these final two weeks I will still have work to do myself, but I’m going to make a more concerted effort to be on top of my administrative work on a pod lead to finish strong.