Week 4 – Big Game Project – Placeholders

Hello and welcome to yet another week of game development for the game Amenti. This week we tried to set up our server and source share of our UE 4 level. It unfortunately did not end up as planned and a lot of time was spent on making it work. Even though we all had same brand of computer and on the same network, it only worked inconsistently on some computers. In the end, we got it to work, but it took up the whole week to fix. This also made it impossible for the artists to re-create the level design with our placeholders as planned.

Speaking of placeholders, after fixing our main character and preparing it for animation for our Tech artist Kevin, I spent the rest of the week to block out our environment assets which we had listed on our Asset list. All the decorative pieces were based on concept art by our Concept artist Gustav Larsson which was supplied during the previous and the current week. The modular pieces were thought out by me and our Producer/Artist Thea Falkenmark. Down below you can see some of the pieces made this week.

Layer 0
Placeholders created this week. Pillar and firepit by Thea.

In preparation of making the assets, I went through a lot of tutorials and documentations to learn how to make modular pieces. So, when making all the parts I made sure to keep their boundaries inside the grid (changing the settings to meter and fitting to unreal), so to make it tillable and not having lots of tiny gaps when tiling them. Another big important part was the placement of the pivot points. To make sure that things like walls have the pivot in the exact same position. Things like small decorative things have the pivot point in the middle of the mesh. But things like modular pieces have their pivot points at their extremities and points of contact with other parts. Down below is a reference of one of my asset’s pivot point.Layer 1.png

I created all the modular parts in the same file so I could reference their sizes and make sure that all pieces didn’t just look good whenScreenshot (3).png viewed individually but good when tiled. When modelling I also made sure to name all the parts correctly, for example my modular piece Wall Alcove is named Module_Wall_Alcove_Placeholder. This is not only to keep it more organized (you should always name your parts so it’s not full of Box1, Box2, Cylinder1) but for also being exported with the script I’m using (download link to the Maya python script https://gumroad.com/l/AAtzf#). This script moves all the parts to the middle of the world (based on their pivot point) and exports every part separately as a FBX named after the named parts in the program. When modelling I also used the power of two and exact measurements, so that all pieces could fit together in different ways. Below is a video where I showcase one of the modular pieces, the gutter, and show you the many ways you can put together the parts (rotating them, flipping, duplicating).


Aaaand that’s everything for this week! I hope you have a nice day and that you pop by again another time.

Week 3 – Big Game Project – A Short Week

Yet another week have gone by, and so I welcome you all back to read my rambles. This week have been a short one for me, since I missed both Monday, Thursday and Friday. This, because I went home for a wedding last week and then the Easter holiday occurred. Even though I were not there, I still worked on my own and when I got back we got a lot of work done.

Untitled-2Last time, I completed the Base mesh for our character Sofia and so I could begin my work of Rigging her (creating a sort of skeleton) and later Skinning (telling the skeleton which parts of the models will move for each bone). This work was spread out a bit over the whole working period of the week, since the whole day of Tuesday was reserved for a Motion Caption Shoot. For the shoot, I received the job of motion capture controller, which entailed calibrating the cameras and recording the actor in the Studio. The process of calibrating the cameras was a lengthy but fun task to carry out. It starts with booting up the cameras and then the capturing program Motive. Of course, this is the easy part, but you cannot start recording right away. First the performance of so called Masking needs to be done, removing in the program reflective objects from the cameras’ view like other cameras or chairs. This tells the program not to include this information in the recording. After this a technique called Wanding is used, where you spin a wand with reflective marker, to show the cameras the area of recording. Later a Ground Plane is placed out to create the virtual studio in the right angle in the program. When this is done, you can start recording! Well, you’ll need an actor first, and they need to be in a skintight suit covered in small markers, which is not fun to apply and is a very tedious process.

Of course this recording was not done alone, but together with my colleague Kevin Alonso, who had the role of director, the job to explain each movement the actor had to perform and give orders to start or stop recording. Also, our wonderful actor Victoria, who did a great job on set! Here is a video a classmate took of Kevin instructing the actor

and some data from the motion capture recordings supplied by Kevin! Enjoy

Week 2 – Big Game Project – The last pre-production work

Hello yet again and welcome to a new week of Game development! Today, the second week of development ends and a lot of things have happened. This week I continued the work on the game Style Guide and developed it even further. I added an environment part, which went through the scale, style and colour palette for each room in the game. Giving a more in-depth view of how the end-product should look like. Added, were also a Font page, an Animation tree example (supplied by our Tech Artist) and later a Character Sheet. The most important adage to the document though, were the Texture and Model Budget pages. Which went through technical specifications and budgets for file sizes, resolution, and tris count. Another nice addition was the Naming Convention page, helping the artist to keep things tidy and name things correctly for the programmers’ benefit.

Week 1 – Big Game Project – The start of the big game project

Hello and welcome back to my blog. I’ll yet again start to update this and fill it with posts of my journey during the Big Game Project Course. All posts will revolve around the making of the game Amenti, a mystical puzzle game set in an ancient Egyptian pyramid.

A concept have already been written since earlier, but a lot of design choices still needed to be ironed out and mechanics needed to be set. So, this week we set out to finish the idea of Amenti and start writing a Design Document. The game’s theme revolves around three gods in the pyramid, Horus the god of the sun (fire), Sobek the god of the Nile (water) and lastly Anubis the god of the afterlife (life and death). Every room, a new set of skills will be learned, by evolving the already set mechanics. For example, the first set of skills would be used to set something on fire or extinguish a fire, the second, to fill something with water or to water grass to make plants grow. The third set of powers, gained from Anubis, allows for the same abilities to be performed from a distance and taking and giving life. All of this would just be a vertical slice of the “full” game, which would take the player through the whole pyramid and display different gods. We decided to go with just three gods for the vertical slice, but later in the process we decided to scratch the Sobek/water part to save on time. Still in the designing process we kept the vague idea of the room, to get the big picture of the gameplay.

Tartget Audience triangle created by Kevin Alonso

Since I was the Lead artist for the last project we had, and I had the most technical expertise in the original group, I received the role of Lead Art/Art Director for this new project. Making me responsible for the overall look of the game and directing the production of all visual material throughout the game’s development. I had to set creative and technical standards and determining the best tools and techniques to use. With the help of the Producer, Game Designer and Lead Programmer, I also devised the game’s visual style.

I sat down, and in conjunction with the Producer, I decided the roles for the groups Artists. All in all, we are four graphical artists on this team, one of them being the producer and me the Lead Art. When delegating the roles, we had to analyse people’s areas of expertise and their availability of time. I gave the role of Concept Artist to Gustav Larsson, since he has shown great skills in drawing and concept in earlier projects. Seeing as he also held the role of Lead Designer, he could work with design at the same time he concept the different rooms and puzzles. For our new member, Kevin Alonso, I gave the, very new for us, role of Technical Artist and Animator. In the group, he was easily the most technically inclined and had worked previously with Motion capture together with me. So, I was very confident in leaving him the task of working with materials, admin work and creating the Animation tree/list, leaving me more time for other visual and technical details. The last group member, our Producer Thea Falkenmark, received no major role, seeing as she already had the massive undertaking of leading the group and taking care of admin work, such as creating the Scrum document.

After this, I helped define the art portion of the design doc, identifying the requirements for producing the art assets and the risks associated with any unknown areas. For this part, I also started on creating an Art Specifications (style guide) document, that should include estimates for texture budgets, polygonal budgets, animation requirements, art style, character design, descriptions of construction, methods for models, naming conventions, tools and programs list. This document exists to help all artist to keep the same style and quality and to give outsiders an overlook on how the game might look. In creating this document, I had to research and test out different modelling, texturing, animation, rendering and lighting techniques and tools appropriate to the games technology. I had to learn modular design and modelling techniques, as this was an important part in being able to create the environments for the game. At the same time, I also had to teach and help the other group members. Since none of us had learned or worked with modularity previously.

This whole week was used mostly for pre-production. For research, documentation and guidelines. I have not yet finished the Style Guide, but since it’s also an iterative process I probably never will be until the end of the project. Here is a link to the current version later, for others to study and perhaps use themselves.

Have a nice day and thank you for reading!

Week 6 of Game Development, Pruning the twigs

Well, well. Here we are, the last week of game development and the day before the big presentation. The team have been working hard (still working, and probably will until there is only one minute left to the deadline), and we have now something pretty playable. At least much better then the last milestone, the Beta. There is a lot left to do though, and a lot that we can’t ever in a million years finish. But for us graphical artist there have been nothing new to do really. All the graphical artifacts are done, and almost all the sound ones too. So all the artifacts this week have just been about making some small fixes and touch-ups to our previous assets. Overall though, the biggest and most important artifact this week for me, and the one I’ll write about, have been the making of mock-ups for our Game Design Document.

So you might ask why I’m making mock-ups for our document, or you might even ask, weren’t you already finished with it? Well yes, we had “finished” it and turned it in. But unfortunately it was pretty lacking and we received a lot of feedback on what we could improve on. So this week and last week we have been working on the document. We have all been editing and adding new texts. But I’ve also taken on one of the bigger artifacts, of making mock-ups. As the biggest complaint on our document was the lack of pictures explaining movements and the likes. This is something we all agreed on lacked last time. But it was something we didn’t prioritized doing or implementing last time around. It wasn’t until later we realized its actual importance. As pictures often more easily convey information and it can make it more bearable reading a wall of text. And like the saying goes, a picture says more then a thousand words.

So, in the making of these mock-ups, I decided to go with a pretty simplistic style. So I outlined the walls instead of using the actual background pictures, and also added outlines to the enemies and the ship to make them stand out more. I used the actual sprites from the game, to make it easier to see what’s what. Instead of having shapes like squares representing them. I think this was a good choice. But hindsight, I think it would have been better if I made the sprites in solid color. Since all the details on the ship might make it a bit cluttery, and harder to read. It also might clash a bit with the more clean comic style. But I think in the end it does its job well enough.

Here you can see some of the mock-ups I made for the document.


Thanks for reading my reflections, and I hope you had a fun read! This is the last one for this course too! S o nobody will be unnecessarily tortured again, well unless you chose to read it 😉

Bye bye, have a nice day!

Week 5 of Game development reflections, Say Hello to my little Friend

We are now done with our Beta, and have begun with our first week of Final. It’s now only two weeks left of Game Development. We had a Beta presentation in the beginning of this week, and let’s just say in the nicest of possible way that… it really didn’t go well. Unfortunately a lot of our stuff wasn’t finished and a lot of our sound and graphical assets wasn’t implemented. This is mostly due to this project being too much for a newbie team to take on. And to even remotely finish all the things in the nine weeks given to us was impossible. We just took on too much. But even if it didn’t go well, at least we have learned some valuable lessons, and we have become much better as working individuals.

So, this is often the part where you start writing all the good things that happened, to even out the bad. But that is a bit impossible, since I personally have had a really tough start to the week. I’ve been terribly ill all week and haven’t been able to help my group with any meaningful work. So I have no assets for this week to write about. BUT, luckily for you (?) I worked with some assets over the weekend and so I’ll write about one of them instead (thought you could get away huh, mehehe).

If you already hadn’t guessed what asset I was going to talk about from the really “secret” reference to The Godfather in the title. So lets make it crystal clear, its about WEAPONS of course, yaaaay! So this week’s asset is the making of the secondary weapons, an important artifact to show the different power ups, aka weapons, the player can use. Here comes the working process for the secondary weapons for the Aquila!

First I had to decided how the ship’s weapons should look like. All I knew was that they were supposed to be 1. a missile launcher, 2. a laser gun and 3. a time-bomb. So I started with making the missile launcher. I googled ship missiles and saw that the shape was often a rectangle, big enough to house a couple of missiles. So after looking around for a while, I blocked out the shape in Photoshop and then started adding some details, I also used a few brushes to make it look a bit dirtied. When finished I had to add it to the weapon wheel. Since it was supposed to be a big and heavy object I placed it under the wheel and connected them together with a thick bolted iron belt.

Done with the missile launcher, I started with laser gun. As it didn’t have any real ammunition, but is shooting laser, I wanted it to be really thin. But I also wanted it to be long, to look a bit like a sniper rifle. Once again I just drew our the shape and then added yet again some details. I used a lot of the techniques that I already went over in my older posts. Now done, I think I might have overdone it with the details. Not because it looked bad, but because they actually weren’t that visible later in the smaller sprite. But as it was done, I added it to the top of the wheel.

And now that all the other weapons was done, all that was left was the time bomb. I decided to go with an EMP grenade design, since the bomb would have a similar effect. I went about making it the same way I did the others. Only I added small lights to it that could blink when used. I also added the bomb to the side of the ship instead of the wheel, since it’s activated with another key then the others. It also wont shoot anything from the ship. But just emit a wave that would knock out the enemies on the ship. So in my opinion, not adding it to the weapon wheel, would probably make it easier for the player to realize that it’s used differently from the others.

Here you can see the wheel how it looked like from the beginning,


here it is with the new weapons on,

Missle Launcher2

here is the time-bomb

Layer 7 copy 2

and finally, here they all are on the ship.

Ship SmartObjects 3

Thanks for reading, have a nice day and I hope you had a fun read!

Dum dum dum dduuuuuu, Week 4 of Game development reflections, le Music edition

Heeeyyoooo!! Well, well, back here yet again are we? Yep, that’s right, you guessed it! It’s time for the next post of GAME DEVELOPMENT!! So, we are now six weeks into the course and the Beta is coming to it’s end. I’m starting to sweat bullets, as we still got some things to work out and finish and the deadline is just coming closer and closer. Most of the things left is programming assets and the programmers are staying up day and night to finish it. So because there wasn’t many graphical assets left (at least not already taken ones) I chose to work mostly on the game’s music and sound. And that’s why this week’s chosen artifact is the creation of Colossus Core’s music. For the menu, the in game music and also for the battles.
So, music. Why?, you might ask yourself. Is this really important? Why yes it is!
Music is often used to set the mood to a movie or a game, and is a great tool to show what kind of genre it will be in. Like for example, using a lot of quick strokes on a string instrument will often induce the feeling of fear (horror genre) and/or give the player an indication of danger and there being little time left. So, as this game being set in a futuristic, cybersteampunkesque world, I wanted the music to reflect this in some kind of way. Like perhaps with a futuristic electronic feel to it, but with still some mystery to it, as the player controls a ship in a dark and foreign cave system.

Background picture made by my teammate Oscar<3
Background picture made by my teammate Oscar, edited by me<3

As soon as I had decide on how I wanted it to sound like, I opened up the music program on my computer called Fruity Loops. I chose to work in this programs, as I had used it a bit before a long time ago when I was in upper secondary school. Not being a musical genius, I looked up a lot of tutorials on the internet, to figure out just what I had to do to achieve my goals. After I had watched some tutorials, I started with picking out the instruments I wanted. I decided to go with very electronic sounding instruments, like a deep bass, funky synthesizers and random electronic sounds, basically just sounds that sounded like they could actually come from a real spaceship. I then set it to a pretty low BPM (short for beats per minute, unit to measure the tempo in music) of 60.
When I had all the instruments set, I just wrote in a couple of notes that sounded OK in the piano roll, and then just duplicated these beats over and over again. I did this for all the instruments and then added random effects to it. Mostly everything I did was just random in the end, I just clicked on things until it sounded at least bearable to listen to. This instrumental arrangement later became the game’s menu music. (Of course I also made it to be loopable, as this is important when in a game. As it saves space and so it doesn’t sound strange when it restarts.
All well and done, I then started on the idle and battle music. I copied the menu arrangement, and then slowed down the BPM to 40, so the music would fit atmospherically for the actual in game music. I removed some instruments as the music had to be pretty minimalistic and a lot more silent, so the ambient sounds of the cave could be heard. For the idle music I just removed some more instruments and changed the bass to be long notes instead of short fast ones.
So, here are the finished arrangements for the game so you could listen to them. I also made a bit more sped up version of the menu version. Still don’t know which of them I should go with. You tell me perhaps? 😉 I hope you’ve enjoyed reading my ramblings, and that you also have a nice day!!

Week 3 of Game Development reflections, Mayhem and Destruction!

We are now done with our Alpha, and we will now start our first week of Beta. This mean that we are one step closer to a finished product guys! Yaaay!! Five weeks into the course, things are going pretty well, at least here on the graphical art side of things. So now I’m once again writing my weekly reflection for a chosen artifact, third in a row. This week’s chosen artifact is destruction and mayhem (more precisely the death/destruction animation for the ship), an important artifact to give a real good indication for the player that they’ve lost. And really it would just look terrible if the game just ended with a Game Over screen.

So this time I’ve decided to go more into the creation process of this artifact. To perhaps help others to create, or use similar effects themselves. Here is the semi finished results so you know how the finished results might look like. I might fix some things later though and there will be different effects added in-engine.
Just a heads up, I work in Photoshop CC. So all the things I’ll describe might not make sense for earlier versions, or work in a completely different program. But here comes the working process for the destruction of Aquila!

First I had to decided how the ship would get destroyed and how it would start out. I decided that I wanted the ship to crack and then explode in a white blinding light. So I started with drawing out cracks with a red brush. Making some zigzag lines over the ship, but always making sure that it looked like the cracks was moving over a 3D shape (following the shape of the ship). When this was finished I drew in a yellow line inside of it, creating an effect of heat. And then I gave the red line an outline of black and white, creating an illusion of depth. This is the same procedure I used when I created the holes in the ship from last weeks artifact. So now the cracking effect was done.


Now I wanted the effect of light seeping through the cracks of the ship, making it look like the ship was exploding from within. Making this was pretty easy in the end, but it was really hard to realize how to make it possible in the first place. But after messing around in filters, I finally found the perfect way to create it. What I did was duplicating the cracks layer, recolor it to a solid orange color and then I used the filter, Radial Blur *100 amount, method Zoom. I then gave the new layer a layer style of Outside Glow, here is the settings I used.


When exploding, there needs to be some small kind of debris. I created this by duplicating the light layer, erasing a bit and recoloring it white. I then applied a new Outer Glow effect in gray to the layer, which created small dots that looked a lot like debris. Here yet again is the settings I used.


Now I had all the layers I needed for the animation, well I also made an extra light layer and two layers of solid color in white and orange (I used these layers to create the effect of the ship exploding in a bright light). Then I just used these layers and faded the different layers in and out in the animation timeline in Photoshop, and messed around until it looked OK. Here is the animation. OBS! The file looks a bit weird here on WP, click on it to see how the animation really looks like.


Thanks for reading, and I hope this post might have helped you in some way!

Week 2 of Game development reflections, fancy visuaaals

So now we are four weeks into the course, this being my second post, and I’m slowly losing my mind. This week we have our Alpha presentation, and these four weeks of work will be shown in front of the class. Hopefully everything goes well, and hopefully this artifact I’ll be talking about this week will help completing the things we need for this phase in production.
This week’s chosen artifact is the creation of mechanic indications on the ship. The reason why this is important, is because we are trying to go for a really minimalistic HUD for the game. This to immerse the player more in the game-play, and create the atmosphere we want. So the indicator, for example, life, will be shown in some way on the ship. And the selection of the different weapons and how much overcharge (a game mechanic) you have currently. So let’s go through the ones I’ve made and what they are for.

As I said before, we will not be showing a life counter on the screen. But your life will be shown in some way shown on the ship. We decided that this should, of course, be shown by visual damage on the ship. The ship would have three different stages of damage.

Ship SmartObjects

After taking 1/4th damage of it’s health the ship would be slightly damaged. I made this visually so that the ship would look roughed up, scratched and dusty. I created this by making a new layer and just going nuts with brushes in different tones.

After receiving more blows and when the ship’s health is about 2/4th gone, the ship will receive more visual damage and start to smoke and throw sparks. The effects of smoke and sparks was made by my fellow graphical artist Oscar. But the ship damage I designed. So I showed this visually by making large holes and cracks in the hull and making the front window of the ship cracked. Ship SmartObjects2The cracks was created by first making a shape out of black color. I then outlined this with a gray color and then a really light gray. This made it look like it had depth.

The last visual indicator on the ship and when it’s in critical condition, is that the lamp (the one I created last week) will start to flash red. At this point, if the ship receives more damage, it will crash and blow up. This blinking of the lamp will be added in as an effect in the engine, so I didn’t have to make an animation for it.
More then damage indicators, I’ve also made a bar for overcharge and an indication for weapon selection. The overcharge bar would show how much overcharge the player currently have.


To show the power increasing, the bars would go up and also change color from red to green, to really show when it’s ready for use. This was later changed though so the bars would start at the bottom and the top to later meet in the middle. I did this so the player could read the power bar even if the ship was upside-down.

The weapon selector was also needed as the ship would later have multiple of different weapons they could switch between. Lineart1So to be able to track which weapon is selected, it would need an indicator. So I made a small bar next to the weapon, that would fill up and glow every time you would select it.

And so these are some of the indicator that are now finished for the alpha. Hope you’ve enjoyed reading my ramblings, and have a nice day!!