Kren devlog #3 – basic metroidvania planning

This blog post is older than a year. Keep it in mind when reading it. Content might be outdated or no longer valid.

A well developed metroidvania game should start with a solid planning phase. One of the first things to figure out is the character movement. I’m not talking about physical variables such as speed, friction and acceleration. I’m talking about figuring out what are the movements we want the Player to be able to execute during the game.

Example: crouching.

Can the character crouch? If so, should it crouch only when standing still? Can the character crouch in mid air or does it simply aim downward? Is it possible to walk while being in the crouching position?

These are serious design considerations that should be carefully planned and addressed well in advance as they define the feeling of the game. The player will act and react based on what movements are available. It’s the absolute first response to player’s inputs.

Crouching: Metroid Zero Mission vs Axiom Verge.

In both games, you can crouch. But while in Metroid you stay in that position even if you let go of the down key/button, in Axiom Verge you get up as soon as you let go of the key/button.

Also, while in Axiom Verge you can walk while being in the crouching state, you cannot do so in Metroid Zero Mission. Yet if you press the down key again, you morph into a ball.

The mechanics are different and so is the gameplay. Plan carefully what you intend to create and plan it well in advance. If you can, plan it all out even before any test level you might be tempted to sketch.

It will greatly simplify the overall development cycle (i.e. you won’t be rewriting big chunks of core mechanics code again and again, risking to break previous works).

Kren Devlog #1 – Upgrade System and Level Specific Items

This blog post is older than a year. Keep it in mind when reading it. Content might be outdated or no longer valid.

Player now has data (like energy, starting_x and starting_y positions, starting direction and so on) and a nice inventory of permanent upgrades. I’ve called it inventory for the sake of it. It’s just an array (it really is) of stuff you can get through the whole game. Permanent stuff. Stuff you can get only once per whole game.

In every room (level) there are a number of different objects (like enemies and items). Most of these items will simply respawn once the Player gets back into the same room. Again and again.

This way it doesn’t matter how many times you killed the enemies in the room. As soon as you exit and re-enter the same room, all those enemies are just there. Again.

This is fine. Almost essential in some situation (believe me, there will be times when you’ll need more enemies to refill your energy or ammo levels).

The green stuff will not respawn once you pick it up. The enemy will, as soon as you re-enter the room.

So what’s with the level specific items? If you already acquired the high-jump ability, you won’t find it again in the level. This is where the inventory comes into play. And this is what I’ve coded today.

By the way I’m not using maps. I’m using simple arrays. I just defined a couple of macros so I can use my global array like it’s a key/value map. I get the added benefit of speed and code autocompletion in GameMaker. The only thing I made sure of, was to initialize the size of the whole array.

global.player[MAXARRAY]     = 0
global.inventory[MAXARRAY]  = 0

Obviously MAXARRAY is a macro (value is 255).

Then let’s say that I have another macro like PLAYER_DATA which is an expression referring to global.player. And I happen to have just the right macro for the 0th position of such array; ENERGY.

If I write PLAYER_DATA[ENERGY] = 99, it’d be like writing global.player[0] = 99. But now I have autocompletion in GameMaker and a list of defined, clear, meaningful, macros.

My Game Development setup

This blog post is older than a year. Keep it in mind when reading it. Content might be outdated or no longer valid.

I’ll keep this short and sweet.

Whenever I tell people that I have a notebook, they usually reply with something like “and what about your main computer?”.

I do not have a “main computer”. I have just this notebook. Which is running Linux and has no accelerated graphic card available (to tell the truth it’s an integrated Intel HD Graphics 4000).

Yet I’m using GameMaker Studio. How is that even possible? VirtualBox made it possible. I’m running Windows 7 inside Linux via VirtualBox.

Testing my GameMaker platformer engine.

Even though I cannot take advantage of all the graphic acceleration stuff (e.g. the awesome graphics in Hyper Light Drifter looks like shit on my notebook; Shovel Knight is unplayable and so on…) I’m able to run my platformer engine with a decent 400 FPS (real). A consistent 60 FPS.

I’m quite happy about it but I just hope I can keep developing with this machine. Fingers crossed.

Testing the platformer engine I’ve been working on

This blog post is older than a year. Keep it in mind when reading it. Content might be outdated or no longer valid.
Still in early planning stages. Yet testing the platformer engine I made in GameMaker.

I’ll write a longer post soon. You can watch the video on youtube with some audio effects as well.

I’m still early into the planning stages of the game. I just needed a platformer engine I can work with to build the game. It’s going to be a Metroidvania type of game.

More on that later.