GUI elements and progress

Here we are with the first 2016 dev report. We practically spend the entire month fixing issues and working on new designs. In gameplay terms, some things were slightly changed -now that we can play with fully-implemented mechanics-, balancing skills, movement sets and behaviors of both Subject W and the enemies.

Besides the tech issues, we wanted to share some designs choices for the GUI, seeing that some of you are curious about the kind of graphics that we use to represent key elements such as the HUD, the skill tree, prompts, etc. Let’s take a look at them.

Defining an art style

As some of you might recall, we stated from the beginning that User Interface graphics were going to be vector based instead of Pixel Art. We took this decision to have a particular style and create a visual contrast between the game world and the player “tools”.

Our original idea was to conceive a minimalistic design scheme, based on the use of lines and curved forms that resemble organic paths from the nature such as roots, midribs and plant veins.

HUD design

Show Health Points (HP), Energy Points (EP) and the currently selected skill. The HP and EP are represented by the upper and lower leafs respectively. This elements have been changed over time as we experienced different playable situations, trying to find one that was both simple and intuitive.

In the first concepts you can see that the HUD was based on the use of bars. The problem of this kind of HUD is that you need to make a bigger/intrusive design in order to see your status. We wanted to have a simple yet functional game element so we decided that a point system will fit better and give players the possibility to identify the damage inflicted by different enemies/situations and create their own strategies in advance.

For example, if I know that a certain enemy’s attack take away 2 HP, I can put the SHELL skill, exchange HP for EP and avoid being killed.

New skill selection

We showed you in earlier updates the skills wheel that allows Subject W to freeze time and select a certain ability to use. Unfortunately we experienced some functionality problems with this GUI element:

As you can see, the wheel gets cut at the ends of the stages and overlaps with the HUD when the character is inside vents or high grounds.

We came up with this solution, integrating the selection panel into the main HUD and showing the skills available right below the current ability (avoiding overlapping problems with other gameplay elements). Also, when the player is in this mode, the enemies are highlighted so you know their position in advance and determine which ability is better for each situation. It’s still a work in progress, but it will probably remain like this in the final version. Anyway your ideas are welcome too :)

Skill tree

Players will be able to enhance their abilities thanks to the skill points collected along the getaway. For this feature we designed a tree that reflects the evolution of each skill.

The original concept shows how we visualized the different ramifications emanating from Subject W’s roots. In further versions we’ve simplified the skill tree, coming up with a clearer/understandable version.

In the center of the tree will appear the skill points collected to spend on an already acquired ability. Around the central seed you can see the skills with their ramifications and the leafs that represent the LVL of each ability. The skill points used are shown under the leafs. An info box is displayed at the bottom of the tree, where players can see the action assigned to that level and decide whether to spend points on it or not.

Interaction markers

Some of you are concerned about the inclusion of pop ups and pointers to show interactive areas. First of all, for those that want to have a more hardcore experience, we’re going to add an option asking (at the beginning the game) if the player wants visual helpers along the game -If you regret this decision you can change it again inside the game options menu-.
With that said, we designed markers to show interactive objects when Subject W is near them. A button marker has been added above the plant’s idle position even if the object is below the plant height, avoiding graphic overlapping of the character with the button. Here are some examples:

I hope that you liked the result :)
Now I’ll leave you with Carlos that will get into detail about gameplay-programming issues.

Demo aftermath

After finishing an stable demo a lot of features were added but were left unpolished, so our priority was to fix all these things before start making progress on other areas. Since then we’ve fixed a lot of problems and I’m going to talk about a few of these, which I think are the most interesting ones.

Fixing broken things

Falling

While building the demo we noticed that SubjectW falling from big heights looked really jerky. To fix this we tried changing the animation first, but it didn’t work. Anyway we left the new animation in there because it looked way better.

After this I changed a little bit the camera, thinking that maybe its movement produced the effect, but that didn’t work either.

After wasting a lot of time I finally found the solution, apparently we needed to tweak an option in the Rigidbody2D component called Interpolate, this option when set to Interpolate calculates the next position of the entity based on the current position, making the motion smoother. When we started the game we set this option to None because it interfered with walking and running, so now the option sets itself to Interpolate when jumping or falling.

Passing through doors

In order to detect the ground and other accidents in the scenery we attached a bunch of GameObjects as children to SubjectW, those GameObjects act as key points for those calculations.

While passing through doors these GameObjects ended up in wrong positions, which caused several problems, like clipping through the floor, and eventually made the game unplayable.

Turns out the problem originated from moving these GameObjects in different animations, a method we avoid as much as we can because it’s a pain to maintain. Deactivating SubjectW mid-animation, to reset parameters and set him on the next room, caused the movement in these animations to stop working and retain the last position they had before deactivating the entity.

Now every time a room is loaded SubjectW is moved to a limbo platform where all the proper parameters are reset and then it’s placed in the new room. This may change in the future if I find a better solution.

Recovering

When SubjectW fell into the ground it used to run an animation for recovering, while this animation was running you couldn’t move at all. After the demo it was clear that, while it was a nice touch, stopping the player completely for such a long time wasn’t a good idea.

Stopping recovery

Recovery while moving

So now we allow the player to move through the recovering, though movement is still halted for a few frames at the beginning to give some weight to the falling and make it more realistic. We also changed the animation, to reflect the ability to move when landing.

The amazing world of cameras in 2D

When talking about side-scrolling 2D games you don’t hear much about cameras and how are they built, at first it seems simple enough, you smooth out the movement of the camera as much as you can and make it follow every single move of the main character until you need the camera to change its location for a cutscene or something similar.

But, like a lot of aspects in game development, the camera is much more complicated than I thought, “smooth and follow” certainly didn’t work for us at the beginning.

To give you a basic idea, these were the obstacles we faced:

SubjectW seems to be moving or static for a lot of animations, but in reality it’s the other way around, which caused the camera to be static or moving when you don’t want it.

Moving platforms messed with the camera if playing one of the previous animations as well, causing some movements that felt weird and could cause motion sickness.

Moving the camera every single pixel that SubjectW has moved caused small jumps and made the camera stutter too much.

For the problematic animations I had to do two things. For most of these animations I made the camera follow a secondary collider attached to SubjectW, which is a box collider that fits itself to the shape of the sprite, not counting completely transparent pixels. The rest of these animations needed a helper to take the place of SubjectW when I wanted the camera to stay in one position.

For the stuttering of the camera I made a window of movement, SubjectW must be a predetermined number of pixels away from the center of the camera for the camera to start moving, this way if SubjectW has moved only one or two pixels the camera won’t follow.

As for the moving platforms, they seemed to solve themselves after the previous solutions, so that’s nice for once.

___

Well, those were some of the things that we’ve been working on since the last update. Keep tuned for more. Bye!