Shrines of Elementia

• The game • 
• The process • 
• My work • 
• Obstacles

The game

The game we decided to make was a semi-open world action game. You were supposed to fight some enemies, interact with shrines that were scattered on different parts on the map, gain powers from those shrines and use those powers to get access to the other shrines, as well as using those new powers to have an advantage against enemies of other types. Each shrine consisted of one element, and that element was able to temporarily turn off the powers of one type of enemies. For example, water could put out the fire enemies and therefore make sure they could not shoot fireballs anymore.

After all the powers were obtained, you could head to the middle of the map where a boss areana stood. There you had to fight one boss from each element before you could win the game, and therefore all elements needed to be collected before you could win the game, as there was no way in without using those elements to remove barriers.

The process

Before creating the game, the group sat down together multiple times to lay out a plan. Firstly, the roles would be assigned. After that, we needed a good game idea. One thing I’ve learned from this project is that the game ideas will be changing a lot. Our first idea had more of a rogue-like take than the game we ended up with, and between these endpoints, a lot of the game changed. Everything we changed was with the mindset of making the game fun, and I think that succeeded. The game ended up being fun when we decided on one direction. More of this can be read in the section “obstacles”.

When we came up with a game idea, we created a ten-pager and then started writing a GDD (Game design document). We started having meetings where we laid the foundation of the GDD. When we had a basic concept of the game, everyone got to work. That’s when we started using the agile development framework of Scrum. We started having meetings every monday morning where we presented what everyone did last week, what everyone thought they’d do this week, and if they had any problems that they needed help with. Every week we had a “weekly sprint”, and those sprints was a part of bigger sprints that our supervisors set. Scrum was incredibly valuable to use, as we could steer the direction of the game every week, and make sure as a group that we worked on the most necessary things.

After each sprint, which was linked with different phases of the game (Alpha, Beta, Code Release), we held a playtest. Having those was very valuable, as you get very blind by your own game, so having a playtest makes sure you change the right things. Trello was used to keep track of the tasks and the sprints.

My work

As stated before, my roles in this game was Lead artist and Sound designer / composer. I will divide this section into the roles I had for more transparency of what I did. Because our programmers didn’t have time to do everything they needed, and I am very confident in my programming, I also took on an unofficial role of extra programmer. I did those things the original programmers didn’t have time to do.

 

Lead artist

My first task as the lead artist was to create moodboards for the GDD to give everyone an idea of the feel of the game. I had a vision of the game being a bit cartoonish but still have some depth to the textures. I also wanted the game to feel mystical/magical, because of the lore that was written by the designers. It stated that the world the game took place in was a magic place in something that resembled norse mythology. Therefore I also wanted the world to feel a bit like something out of the norse mythology. Below is the moodboards I created for the world and the characters, as well as some pictures of how it looks in-game.

Most of those assets, like the trees, rocks, grass, fence and so on were downloaded by me. Because of time constraints and that I was the only modeller for half the project, I had to download a lot of the assets. I mainly modelled the more custom things needed, such as the shrines.

Except these, the biggest thing I modelled was the enemies. Those I both modelled, baked, rigged, skinned and textured. When we first started the project I created the first version of the “Elemental” as we called it. It was a very basic design just to give us an enemy to play with.

This was the first enemy. Each enemy belonged to a specific biome, so to give this enemy something to visually indicate what biome it’s from, I opted for using basic particle systems. Such as this one for the fire-enemy.

Basically some fire that indicates fire. After the first playtests we got feedback that these did not feel like enemies. They were too cute. So I started sketching some new variants of the enemy. One sketch looked like this:

I kind of liked that and continued to go with style of the enemy. I created an enemy in Autodesk Maya and used Autodesk Mudbox to sculpt it and make a high poly-version. I used stencils in Mudbox to carve out the veins and then I went around and cleaned up ugly carvings.

After the highpoly was done, I imported it into Maya again and drew a lowpoly version of it with quad-draw. I then assigned one material for the stone “islands”, and one for the veins.

The next thing I did was to import it into Substance Painter, bake it with the highpoly version to create more details and then make the textures. The end result is shown below.

Of course, I still had to rig it so my animator could animate it. Rigging and skinning this character was really easy because of all the separated parts, so I got it done very quickly.

It was also requested from the team doing game design that there would be another enemy that was stronger than the one I recently made. So I created a more “king”-like enemy to serve as the “Greater elemental”.

I am very proud of these enemies as they were simple and time efficient, but still feel like they fit in the world. They are no longer cute and very easy to see which area they belong to thanks to the colored veins and particles around them. Some in-game screenshots are here down below:

 

Particles.

Much of my job was also to create or find particles. As with the modeling, I did not have time to create all particles myself, so those I could download and tweak, I did.

I also did the particles that show up when you attack the enemy.

The waterfall i tried to create but had to be content with how it looked after a while because of time constraints.

I also added some particles for when you interact with the shrine. Those where not completely hand made, instead I did tweaks on particles from a particle pack I found. But it looked good, and sometimes you have to prioritize your work. If there is valid options out there, it’s better to save time for the things that have no options.

The attacks also needed particles. The water attack would summon a geyser, for example. I created that particle system. It was quite hard to get the colors right because of all the small transparent textures I used, but I think what I ended up with looks good.

The wind ability would shoot a “wind blade”. It is essentially a texture sequence I looped.

The earth ability, “Earth Spikes”, I co-created with another group member. The model for the stalagmites were created by me.

I created, added and tweaked other particles too, but these where some of the ones I thought was the most interesting.

 

Lead artist

Not only did I create a lot of things for the game, as the lead artist I hade to make sure that the other artists in the group were doing their jobs, made things of quality that suited the game, had something to do, and make sure I was there to help if it was needed. So that was things I did often too. I gave feedback to everything they wanted feedback on and made sure our Trello was updated with things to do. For example, I sat a lot with another modeller who was responsible for modeling the new player character and the bosses. He wanted a lot of feedback, and when it was time to import the characters into the game a lot of problems arose. So we tried to solve that together, and after a lot of trial and error (which can be seen on the images below), we did.

I also did the trailer.

Sound designer / composer

As a Sound designer / composer, I was tasked with making sure the game had sound effects, music and that you could control the sound in-game. Because we had 6 different biomes, I thought it would be fun to give each area its own theme music, as it would make the areas even distinct and induce more urge to explore the world. Another thing to mention is that I’ve become very interested in making music the last couple of years, so I wanted to try and do the soundtracks myself. If there was no time I would just download music, but I wanted to give it a go.

Creating a soundtrack is hard, because you have to create a lot of them in order to ensure that the music isn’t annoying because of repetitiveness. And to ensure that, I would have to create a lot of different songs for each area. Fortunately, the university made a deal which let us use the software “Elias Studio”. Elias studio worked in such way that you could divide your music into different categories and it would both randomize which parts of the song that were playing, and take care of smoothing out the transitions when switching music.

As you can see in the picture above, I divided the instruments into different categories, and then put the different possibilities of combination as rows. I also added some variation to some of the tracks, which makes it even more randomized. The soundtrack above is the water soundtrack, and as you can see, some variations has all instruments and kick-drums, while some have an orchestral taiko-drum instead. One version is even really silent with some instruments silenced. This made sure I could create the soundtracks in Logic Pro X as a normal song, and then export all categories of instruments as stems for each specific bar. I often used 8 bar loops, or sometimes 16.

When creating the songs, I had a recording of me running around and playing in those different areas, which I then added to the project in Logic Pro X, and simply making the music as I was scoring a movie. Keep in mind, before this, I have never scored a movie or anything, and I’ve only created a few electronic dance music songs before. So it was all new to me. But it was interesting to try and fun to challenge myself!

Down below is the finished videos from when I created the music.

The boss music I wanted to be hectic, and I wanted to resemble the theme song from Pirate’s of the Caribbean for this one. I think I succeeded with some Hans Zimmer vibes in this one.

The spawn area was supposed to be your main home on the map, your safe space. Because of this, the music has to be reasonably calm to induce that feeling. It was also the first place you came to after clicking “New Game” in the menu, so I wanted it to represent the whole game. It was meant to be like intro music, sort of. Everything about the game is magical, so of course this soundtrack was supposed to feel magical. This song has a Hammond piano (a synthesized one) as its prominent instrument, as I found the sound of that pretty magical. A lot of other synths has also been used.

The fire area should feel fast-phased and heavy, so I added lots of drums in this one.

The wind biome I wanted to feel pretty light, almost like you’re soaring. I also wanted to make it feel a bit Celtic, as the area was designed with Celtic landscape in mind. To add to that feeling, I actually made the song in 12/8 time signature. Somehow that made it feel even more light. And of course, bagpipes were included.

I wanted to make the earth biome’s theme song pretty fast and energic, but I also wanted to make it feel magical. I used a lot of synthesized sounds to get that feeling.

Unfortunately I do not have a video of the water theme, so just imagine a Caribbean island when you hear this song. For this song I went for something tropical and uplifting, and drew some inspiration from the song “Under the Sea” from Disney’s Little Mermaid.

 

Of course, I added sound effects as well. Here are some examples:

Sounds: Enemy Windup:

Sounds: Player sword slash, water, geyser, enemy cast:

Sounds: UI:

 

Extra programmer

As mentioned before, our programmers were overrun with things to do – especially in the end. As I didn’t have that much things left to do, I helped a bit with the programming.

I did all the audio programming. I made the game objects and scripts that would trigger the music, and I connected all the sound related components to the scripts other people had made. I also created the audio manager for the game which controlled all audio.

I also did all the code for the options menu and the in-game menu. I created a keybinding-system and made sure all the audial sliders and graphical dropdown-lists worked.

I also created a “journal” you could toggle with a keypress and then interact with. You could change pages to read more and click on different sections to read about other topics.

 

Obstacles:

GDD very important, not wait with details. The game took many shapes, not everyone was on same page.

Getting everyone on the same page, sorting out the details.

The first lesson I and my team learned during this project was that it is important to make sure everyone is on the same page exactly with how the game is, looks and how it should function. The first weeks of development it seemed like not everyone had the same idea of what the game was supposed to be like. Someone was stuck in the mindset that it was still going to be a roguelite, someone wanted slow and heavy combat like in Dark Souls, while some others wanted fast combat like in the end product. This took a while for us to realize, and when we did, some of the work that was already done had to be remade. In hindsight we should have made sure everyone was on the same page at each meeting and if not, focus on making sure every one is before starting to create everything.

Details, like what abilities you get when interacting with a shrine, was decided upon a few weeks into the project. A lot of our meetings had this as a discussion, but we never came to a conclusion of what they would be. Not until we really sat down and ironed it out by everyone submitting ideas and then voting on it. We should have done that beforehand, because a lot of valuable time went into discussing those abilities with no success.

People who doesn’t work.

We had three programmers in our team. After the Alpha-version, one of those programmers stopped coming to meetings and never pushed anything to GitHub. We asked over and over again for him to push what he said he had done, but he never did. And we made the mistake of trusting him. We let it go 50% of the beta-version until finally we convinced him to push what he did. He had done nothing. His job was to program all the bosses, so halftime into beta, we had no bosses. Time was running out. We talked to the supervisors who said that we should continue without him, one of the two remaining programmers worked overtime to get the bosses into a usable state, and I took on some programming-work too. Unfortunately, this made us work more than the 40 hours a week that was required, and when deadline arrived, we had to do the thing you shouldn’t have to do. Crunch. But our hard work paid off, and we succeeded with the game!

Time.

As always, there is always too little time. As stated above, we had to crunch at the day of the deadline in order to get the game into a usable shape. There was nothing new added that day, it was only about fixing errors in the game and making sure you were able to play it the way it was meant to be played. We should have fixed that the days before in order to not crunch, but with one programmer short, sometimes there just wasn’t time. Our game was build with three programmers in mind, we had two and one third. But if there’s something I’ve learned from this experience, is that you should start fixing the game into something playable a few days before deadline.

Art style with downloaded assets.

Keeping a consistent art style when working with downloaded assets were not that simple. You really had to scour the internet to find assets that roughly fit your art style. Then it was the art of re-texturing, which I did on several occasions. It is hard keeping an art style, especially with downloaded assets!

The character walked like she were man-spreading.

We had a problem with the new main character and her rigging. Whatever we did, she straddled a lot when she walked. We managed to fix it a little bit, but something in Unity was off after we imported the first character, because in the videos on this page you can clearly see that she’s still straddling quite a lot. Unfortunately, this one we didn’t have time or knowledge to fix.