During the production of Spite Absolution, I took on the responsibility to create the system for the particles in the game. I soon realised that the best way to allow the technical artists to play around and see what their effects will look like in the game, was to allow them to work immediately towards the engine using some sort of editor. This system has now grown into a well-established part of our pipeline. All the particle systems displayed were created by technical artist Kim Johnsson using the particle editor.
Going into the second year at The Game Assembly was both exciting but also really scary. It felt like I had to know what kind of programmer I wanted to be, and I was nervous heading straight into the first game project of the semester, not really having a plan of what I would want to do. Therefore, I went into the meeting with my new configuration of programmers and picked out something that had to do with systems and engine and ended up with level exporting from Unity, level importing into the engine and particles. By this time, I could only feel excited for the new challenges and soon enough I started working on a particle edito.
I worked closely with the technical artists in my group and after a thorough discussion, I retrieved back to my workstation with some main features that they had requested for the editor. One of the first things that they requested was to be able to change the velocity, size, color and other attributes over time. I studied Unity's system for creating particle systems and took some inspiration from the rate over time alternatives. Normally, you would want to visualise the rate of the attribute via a graph and perhaps change the graph directly through a graph editor using the appending of new nodes to the function. Even though I took a lot of inspiration from this, I realised that it was not possible for me to create a graph editor during the time frame of Spite Absolution considering the other tasks I had assigned to myself.
I ended up choosing five functions of rate over time that I believed would allow the TAs to have enough room to play around with. The functions I chose were
I exposed up to three coefficients that could be played with. What these variables corresponded to is dependent on the chosen function. In the images, I display what the coefficients represent calling them "A", "B" and "C".
Some problems with this solution were that the TAs needed to do a bit more research than with a graph editor. In the future, it would definitely be cool to try to create a graph editor where nodes can be edited and added live.
A more recent feature, which was added during the beta-stages of our game Fungal, was sprite sheets. It was suggested by the TAs already during Spite Absolution, but it had to be deprioritised back then, making it a perfect feature to add during the second project of year two. The sprite sheets introduce not only fun opportunities, such as animated particles, but also optimization. Instead of loading multiple textures onto the heap, the designer can use the same texture to display different frames of the sprite sheet.
To use the sprite sheet feature, you will have to tell the engine what the sprite sheet looks like (how many rows, columns and frames). Then you have the option to animate the particles or not. If you choose not to, you have the choice of rendering a specific frame or randomise a frame for every new particle. If you animate the particle, you have the choices of letting the animation loop or not and letting the animation start at a random frame for each new particle.
Here is an example of animated particles as the bomb is exploding. This animation has only four frames and is played in slow-motion, but I still think it looks quite neat.
Other features in the particle editor includes:
It has been a fun challenge to get the features to work in sync. It gave me the opportunity to touch parts of our rendering pipeline, programme the rotation in the geometry shader, perform multiple matrix transformations going between different coordinate systems, design a user-friendly interface using ImGui and become both enemy and friends with RapidJSON.
When working closely with other disciplines, I have learned that knowing my boundaries and trusting my gut is important when discussing expectations. I am only one person on this task, and I have also other responsibilities outside of this specific one, so I soon realised that I had to say "no" quite alot, even when the requests sounded very exciting. By doing this, we were forced to prioritise and explore alternative solutions which often turned out to save a lot of work.