Cobbling things like a carpenter – or reusing assets

As we are heading into the final sprints I’m sure we all have noticed the need for polish and just the feelings that we don’t have enough time to finish everything we want to do. Well my team definitely noticed this, and after trimming and cutting some content we were left with a list of things that needed to be done until release. Then we took that list and looked at what could be done with the help of old assets.

We choose to reuse art assets that had already been made for a couple of reasons. For one, because of cut content we had some pieces of art that hadn’t been used yet, so we choose to repurpose them. Two, is because it’s more efficient to take something old or unused and repurpose it. Especially if it already fits the game, and we were running out of time. Three, I can’t remember where I heard it, but you should strive to make sure that everything you create can be used more than once.

The biggest thing we had left to finish for the game was the boss. Which we had very little for the start of the week. The things we had was basically a sketch and some ideas for attacks. Now, 2 days later the boss was basically finished in both visual and gameplay design, this largely because I had unused art assets that easily could be repurposed.

The first thing I had was the sketch for the original boss idea. Where the head was the only thing that had really been developed.

Leviathan.png

I really liked the very aggressive look of the head, and it was already set up in individual pieces to help with animating it. So I decided to keep that. However I needed to make it smaller since it made more sense for the attacks our designer and programmer had made – after a bit of back and forth between ideas, the form landed on a shark.

MiniBossBOss - final.png

This, which is the version we’ll use in the game has the base of a white shark, with a slightly larger fin on the back. I’m decently satisfied with the design. It has the feel of an aggressive, slightly otherworldly shark, with a head of a dragon. The colours I choose for the body are mainly based around what the other creatures in the game has, and the armor is made with another shade of the same colour to make it look more like bone. The additional details on the body are mainly to bring a bit more cohesiveness to between the head and the body and also to create some purely visual tells for the boss’ attacks.

For one of the bosses attacks, we decided to repurpose one unused sprite, cut because it was originally part of our narrative, to be used for the projectile. So it went from what was supposed to be an egg

green crystal.png

To this, which is a projectile that will be shot sideways.

Crystal sideways.png

One of our enemies needed to a proper projectile sprite. The projectile also had exploding properties, and we were unsure on the best way to go about it. Would we use the same sprite but smaller or create a new one? Our solution came like a flash of lightning and we decided to use the projectile from the first enemy to create a recognisable threat and to have it be more streamlined visually – aka. less things new things to register in the players mind.

Slime_Gif.gif

 

A2LOA}S9JO0]@6%`3VF{G43.png

 

My project manager who helps me with the art has also repurposed a lot of the art in the GUI to help further our visual identity and to create a good base for it.

GUI_2.pngHere she took the front of our ship and used it for the health/aether bar.

Ship sketch actual colour-updated.png

 

A lot more has also been used in our various menus.

Main Menu 1.png

Reusing old assets sometimes feels a little cheap since you’re not creating it from scratch so it doesn’t feel as though you’re working as hard. It is however more efficient as I’ve said and it really reduces a lot of stress when you don’t have to create something new for everything that you’re doing. And I mean, hey, even Disney are doing it.

Advertisements

The Scrumptious parts of Scrum

As you all know, this week we are supposed to write about our life and times with the agile development method, Scrum.

Scrum and me: Even though I’ve worked with scrum in the past 5 weeks, I still can’t really say anything about it at all. Might this because I don’t have anything to compare it to and that the only place I worked at was in the service industry? Probably.  I can however say how scrum affects my workflow.

  •  First of all it gives me a clear list of priorities of things that needs to be done during any given period, that is tailored to the tasks at hand, what the other team members are working on and my skill level. This makes it simple to structure what I’m going to do during a sprint – and since code and asset is worked on at the same time and often together in the same room, it simplifies the cycles of iteration since we can communicate effectively.
  • Clear deadlines. As a person who has a habit of not finishing things or space out, the clear and often very tight deadlines are a great help in ensuring that I finish all the assets on time since it affects the whole group. On the flipside, since tasks can be switched around to suit both the team and the individual, the amount of work often times don’t surpases what’s actually doable in one week.
  • The freedom of leaving things. Technically we are aiming to work 20 hours a week, and sometime that won’t happen due to disease, unexpected events or other forms of mismanagement so you might be forced to leave an asset as “It works” or the like. However since the plan is updated every week, often with a focus on testing and improving, it alleviates some of the pressure of needing to make sure everything looks perfect before it can be considered “Done”, since you always has the option to go back to it and you’re probably gonna iterate upon it either way.

These are the thinks I can think of when it comes to how Scrum has affected me since I don’t have anything to compare it to and bottom line, I’m still not very familiar with it.

A big problem with how we’ve been working, is that since it’s built upon previous cycles, is that if something doesn’t get done during a sprint – there’s no way to continue working on it until the stage before is completed. As an artist this can be really frustrating when I have to wait for design, and I can imagine it being frustrating for our programmer when I’m slow with an art asset. It also means that there’s a higher chance of me being forced to redo an asset if the design changes part way through the project. This is probably a symptom of our inexperience in game production and our misunderstanding of Scrum. As well as how it feels like we are sort of pushed into something that’s in between scrum and the classical waterfall model.

In Team Devourer we usually structure our days like this.

Monday: We usually start a meeting by having an actual meeting where we discuss different parts of our game with feedback and just general thoughts as a base. When we’ve reached a conclusion (read. When everyone is dead from the lack of oxygen) we move on and do our sprint plan. During the planning we usually look at what we decided, where we are and where we are going and then tasks are given based on what needs to be done to the next milestone, based on the order of importance. We usually don’t have a stand-up meeting since we end very late.

Tuesday: We have a stand-up meeting where we present what we have done and what we are going to do.

Wednesday: On wednesday we usually have another meeting followed by us working together in the same room.

Thursday: The same as Tuesdays. Sometimes we have an extra meeting if there’s something urgent that needs to be taken in person

Friday: We do our sprint review where we briefly discuss how things have gone throughout the week, followed by, you guessed it, another meeting where we prepare ourselves for the coming week.

You might notice an overabundance of meetings, but they surprisingly really helps us to keep on the right track and also makes sure that everyone is up to speed. This is about I don’t have much more to say.

See ya~

The background as tool for narrative and suspense

When tailoring a game to make the player feel like a champion, you can’t just do it through a finely tuned challenged – you also need to create build-up. In Team Devourer we decided to convey feelings and mood through the use of mainly the background.
I our version we have different scenes that we use to build our narrative. These are: A sunny afternoon – used for the tutorial level.
A twilight dusk – used during the easier of our two levels. A night sky – used during the harder of our levels as well as a modified version for the bossfight.

A nice, sunny day is often associated with tranquility and the feeling of safety. That’s why it will be the brightest and with a more vibrant and lushous background. As I said earlier, this is where the player will learn the ropes of our game. There’s no real threat here and it’s also here where we introduce the narrative parts of the game – like the treasure hunting pirates and the Leviathian.
The colours and background objects also serves as contrast to later stages.

Dusk is often representing and associated with uncertainty and mystery, whilst also being a blurred line between the safety of the day and the dangers of the night. Seeing this is where you are first faced with both the Leviathan and forced to use the skills you was just thaught – beginning the ride up to the climactic finish (boss fight).
In the last stage you only saw a brief glimpse of the enemy so a new player won’t know what to face until the end of the stage and since the challenge of the waves rapdily increase, the players will also be more on edge and feel a bit threathend and stressed – two important factors in creating the feeling of challenge.

The night is commonly attributed to danger and makes a lot of people tense up. Since you’ve seen the Leviathan now, what it can do and now it’s out there hunting for you, keeping the player a little on the edge. The night sky adds to the atmopsheric doom and gloom. Another reason I wanted a night sky in the game is because it allows graphics to
stand out more, creating a more grandeour experience. The vegetation on the island is aslo a lot less visible and aren’t as lush as previous scenes.

Lastly we have a dawn. Emerging from the darkness into light. Granting the player as sigh of relief after the boss fight. The colours
are probably gonna conflict with the player avatar, which is why it will probably only be used in a cutscene at the end.
All of these scene shifts help to build a narrative with small intermissions between them as well as adding rising tension.

The iterative process for the background looked like this. From the second version forward, everything is made in 3840×1080 to help a little with the future parallex scrolling.
Background one

This is my favourite version of the background. It doesn’t work with our game however since the colours themselves are way to vibrant obscuring important info, like the player avatar, as well as having radical shifts between each field.
It also has a lot of texture wich would just be distracting for the player in the long run.

Background 2 wip
The second iteration of the background was remade from scratch. A big part of this one was trying to capture more of what an actual sunset looked like. With the shiftng colour hues of pale colours and warm colours of orange and blue. It has a little bit of rendering work put into it, but as you can see the brushstrokes are still way too visible, which doesn’t fit the artistic style that I was going for and it’s a detail that once again would distract the players.

Background 2 wip smudged
Based on the second iteration this version was created by heavy use of the smudge- and blur tool in an attempt to render most of the brushstrokes invisible. Which it does. It’s not even half-bad I’m still not that happy with it and I’m gonna probably redo it sometime before beta. Going for a better gradient between the colours. However during the playtesting we got a comment on the background being a bit hard to distinguish from what’s important.

The future backgrounds will have a better colour gradient picked out from the start as well as some more research put into them so that I, as an artist need to spend less time fixing the ineviatble mistakes that will occur.

The animation cycle of a wing span

Aka. H***.

 

Enemy-1-SkySlug-anim--backup-2

The though process behind this stale monstrosity was quite simple – effiency and modability. To explain further: Being the sole artist for the team I need to create a lot of assets and templates for said assets at a relativly high speed so that I won’t lag behind our programmer. Doing the animation properly, frame by frame, would almost be a week in itself. In an attempt to save my sanity I decided to create a semi-smooth wing cycle, which I added onto the body of the creature itself. I also decided to animate the tail seperatly from it to give it a bit more life. Effectivly cutting the workload from around 15 hours to 6 hours.

It still looks a bit stale however – servicable and not nearly as noticiable from a distance. However when I animated it I left myself some ways to modify it without needing to redo all of the work already done. The two easier ones is to add more colours, shading and texture to make it look less flat and adjust parts of the wing in each frame individually since the groundwork is already done. I know I’m not totally finished with it so colour will definitly be added later on.

The more difficult ways to make it more lively is to cut off the tail and reattach it at different angles and drawing to fill in the gaps. Since there’s a large space between the main body and the tail, this can be done without affecting the rest of the slug all too much. Another way to make it alive is too animate the mouth. Since one of the most jarring things for me personally when I look at it is how different the levels of movement is between the right and the left side. Again however, since the face (mouth + eyes) is about 1/5 or 1/6 of the actual creature, it’s once again easier to change without affecting all of it. And as I said, the body should preferebly be held in this position to save myself a huge head-ache, but who knows. This might also blow up terribly in my face down the line.

The workprocess is a mix between laziness, efficiency and “expirimenting” with photohop. It involved swearing, copy/pastying the wings and body between multiple frames on seperate videolayers. A lot of it became an automated work cycle between the wings and body in both “animating” and colouring it where I did the same thing over and over again. The tail part was animated seperatly between each frame and it was a nice way of trying to get used to following form and being consistent. Both of which I failed really.

The things I could improve upon, if I’m still using the same mindset, is the texturing and colouring of the Sky Slug, letting the tail be a bit more exaggerated so that it can really show the movement of the slug and not look as awkward. I should also have planned everything a bit better beforehand. Something I feel like I need to work on a lot.