next »

[Ishi]

As for the shell penalty on death... Perfect opportunity for communication by having the shells fly out of little Leilany upon death.. Kinda like rings flying out of Sonic when he get's hit.

This crossed my mind too, would be a nice effect to add to the death animation! Wario Land also showed Wario losing his coins when dying.

[empika]

I've been following the maps progress on Twitter, they are looking really great!

[Ishi]

World map progress - Week 4!

Some more world map features added this week.

Leilani Power Sprites

Leilani's sprite now represents which powerup she currently has. Powerups are carried over between levels.



Enemy Reinforcements!

This is the biggest thing I worked on this week. In my head I was planning on adding enemies that would wander around the world map and give the player encounters, like the Hammer Bros in SMB3. I wasn't really sure how to approach the movement logic for the enemies though, for example when they should move, when they should appear, and how to constrain them to a limited area of the world map. Then I hit upon a different idea that would be a bit less work to implement.

The intro that's currently in the game's first level shows supply/transport crates being dropped onto the island:



So I have replicated this on the world map:



Every few levels, one of these crates will drop! They're in fixed locations, and each one is a single screen combat challenge. If Leilani dies during the challenge, the crate disappears but will come back again later. If Leilani beats the challenge, the crate is destroyed for good.

I think this is a pretty economical way for me to add some variety to the game's pacing. I can potentially have a lot of fun with the level design for these little challenges since they don't need to fit nicely into the flow of a normal level.

It's also another way to link the world map's mechanics directly into the theme/story of the game. Eventually seeing the island littered with crates that Leilani has destroyed should be pretty satisfying.

Powerup Plants

Another way to spend shells, plants can appear on the map which Leilani can buy powerups from.



Rope Paths

This one is just visual, paths can now be drawn as ropes that Leilani rolls along, similar to the ropes that can be found in the main gameplay.



Thanks for reading

[Photon]

Powerup Plants

Another way to spend shells, plants can appear on the map which Leilani can buy powerups from.

How are you going to handle this mechanic in-between worlds? It would seem that you don't need more than one of each tree since the player could just keep revisiting it regardless of how far they've gotten... unless I'm missing something about world-to-world travel.

My point is, this looks like something you only need one of ever.

[Ishi]

How are you going to handle this mechanic in-between worlds? It would seem that you don't need more than one of each tree since the player could just keep revisiting it regardless of how far they've gotten... unless I'm missing something about world-to-world travel.

My point is, this looks like something you only need one of ever.

Good question! The game won't have clearly defined worlds, it'll be more like Super Mario World with one big connected island to explore. But yes, technically you could revisit any of these plants if you were willing to walk back to it. My thoughts are:

- The plants will be more spread out than in the gif, for example I imagine the starting beach area will just have one of them.
- Travelling back takes time, which not everyone wants to invest! The Top Secret Area in SMW has free items but you have to be really patient to walk all the way back to it from the other side of the world map.
- By the time you want to go back, the route may have crate challenges on it which you don't want to play right now.
- Possibly there will be points in the game where you are stranded on a section of the map and temporarily don't have freedom to return to earlier areas. I loved it when Wario Land did this.

So there is definitely some value in the player finding a second one of these plants, I think.

[EJlol]

One thing that bothers me is that the crates comes out of thin air. Where is the (shadow of the) mothership? I also think you should give the crates a shadow, it will give it a little bit more depth to it.

[Ishi]

One thing that bothers me is that the crates comes out of thin air. Where is the (shadow of the) mothership? I also think you should give the crates a shadow, it will give it a little bit more depth to it.

A shadow is a good idea. I also have potential ideas for giving some context to why the crate appears but that will depend on how the future of the world map goes!

End of world map month!

It's the end of august so I'm done working on the world map for now. I have a couple more bits to show.

Locking Camera to Areas



The world map will be split into different areas. The camera generally stays locked to the centre of the current area, and then scrolls over to the next area when Leilani moves over to it. I thought this would give a better sense of progression as players work their way through the world map, rather than just scrolling the camera around the entire world without restrictions. It also keeps the player focused on the upcoming levels, and allows them to glimpse the neighbouring parts of the map in a fun way.

In the gif, when I turn on the debug graphics, the grey box shows the current area. Also just to clarify, this is totally placeholder world map layout, and not final graphics. I'm mostly focused on getting things working nicely, rather than looking nice!

I also plan on using these areas to change the music as the player moves around the map.

Foliage system



The normal level gameplay has a simple system for handling animated foliage; I have transplanted it into the world map so I can use it there.

I haven't done any specific world map foliage graphics yet - this is just using one of the plants from the normal gameplay, so it's way too big. But it works well enough to test the functionality. The plants sway a little in the breeze (sorry no gif this time).

Inside the level when the player destroys the battery tower at the end of the level, the nearby foliage that was dead comes back to life. The same is true on the map, the red plants on the right are dead, and will return to life once nearby levels are completed.

What's next?

I'm feeling a bit burned out from working hard this month, though I'm super happy with my progress! To go from having zero world map, to having one with a good amount of functionality, is a big step. I will return to the world map for another month in the future to add remaining functionality and to do some proper artwork for it.

I haven't planned what I'll be working on next. I'm going to take a week off from working on the game, and mull things over, and I'll come back with a plan for the upcoming months.

Thanks for reading!

[Photon]

Maybe I missed it in one of your earlier posts, but I'd really like to know the process/implementation you follow for setting up your debugging stuff.

[Louard]

Your work on the World Map has been fantastic! You clearly have a good sense of what 'feels good' with details like the camera focusing on areas rather than simply scrolling along with the player.

Really like the crates blocking the paths idea too.

About the powerup plants. Would you consider making them 1 offs, or grow back on a timer?

[Ishi]

About the powerup plants. Would you consider making them 1 offs, or grow back on a timer?

I want the plants to be: a way to encourage the player to spend shells, a convenience for collectable/secret-hunting players to get a specific powerup that they want, and a little bit of extra help for players who take damage often. I think adding a limit to the plants would detract from all of those uses. If there was a rare powerup (I don't have any in the game though) that I wanted to limit, I could just make it expensive. Is there a particular reason why you would consider putting limits on them?

Maybe I missed it in one of your earlier posts, but I'd really like to know the process/implementation you follow for setting up your debugging stuff.

I don't think I went into any detail about it before! I don't do anything super fancy but can talk a bit about my methods.

Debug Keys

For the controls for various debug features I wanted to avoid having them spread all throughout the code. It can be easy to lose track of what they all are. So my keyboard system keeps track of them.

Code:

m_pKeyboard->AssignDebugKey("SlowMo", KEY_LCONTROL);
m_pKeyboard->AssignDebugKey("SpeedUp", KEY_LSHIFT);
m_pKeyboard->AssignDebugKey("Pause", KEY_RCONTROL);
m_pKeyboard->AssignDebugKey("DebugRender", KEY_TAB);
m_pKeyboard->AssignDebugKey("DebugPage_Game", KEY_F1);
m_pKeyboard->AssignDebugKey("DebugPage_Sound", KEY_F2);
m_pKeyboard->AssignDebugKey("DebugPage_Resources", KEY_F3);
m_pKeyboard->AssignDebugKey("DebugPage_Input", KEY_F4);

Then I just refer to it by name elsewhere in the code. For example, this will run the game at 1/10th speed if I hold down the left control key.

Code:

if(m_pKeyboard->DebugKeyHeld("SlowMo"))
{
	deltaTime *= 0.1f;
}

So it's really easy to change what the keys are if I need to. It produces an error if I try to assign multiple things to the same key. I also only have to change the code in one place to turn all these debug keys off in final builds of the game!

Debug controls

You can see above that I have some time controls for the game. Running at 1/10th speed is handy for observing behaviour especially with collisions between objects. Running the game fast is useful for skipping bits, especially when combined with another button which makes Leilani float around and be invincible!

I also have some other buttons like:
- Instant level restart, which will also reload any changes made to the level
- In-place level restart, which is the same but keeps Leilani at the same location in the level
- Skip button which takes Leilani to the entrance of the next area, if the level has multiple areas

Debug Pages

Finally I have a simple concept of debug pages. The tab button turns the debug display on and off, and the F keys change which page is displayed.

The first is a generic gameplay page, I can display whatever info I want to see at the time. For example entities are labelled with their X Velocity because I wanted to see it when testing moving platforms.

It also draws entity hit boxes, which is especially handy for seeing trigger areas and things like that that aren't normally visible. And it draws bounding boxes around UI elements which is rarely useful, especially as they currently are drawn beneath the UI itself, but you never know when it might come in handy.



The sound page lists how many sounds are loaded and playing. And the most important feature of this screen is that sounds with a location are drawn at their in-game location, for example the "jump" sound playing where Leilani is. This is very useful especially when there's a bug and a sound is being played unexpectedly, but you're not sure where it's coming from...



Resource page shows info about how many of all the kinds of resource are loaded.



Input page shows the available devices, and which one is currently active. It shows an icon next to devices which have buttons pressed which is useful for identifying joypads and things, especially when there is Steam shenanigans going on where Steam is emulating an xbox pad or something.



I think that covers my biggest debug features! Hope it was interesting Photon.

[qMopey]

Very nice! I love remapping strings to things for slick programming APIs like that. Very cool 

[Photon]

I think that covers my biggest debug features! Hope it was interesting Photon.

I do have one more question though. For things like the drawing bounding boxes, how do you establish the relationship between an in-game entity and the "debugger?" Is the debug code local to the entity classes, or is there some other magic going on behind the scenes? Its one of those things I've thought about before but am never quite sure how to handle.

[ydobemos]

This devlog has been a joy to read all the way through. I think your attention to detail with little things like the particles on many actions, the extra animations and general polish really set it apart from the often done "Let's take a game engine's built-in platformer actions, add own graphics and call it a day" approach.
 
Really neat look to things as well. I hope it controls as good as it looks in the gifs.
 
One question - is the black outline baked in or added on the fly? Some details, like the duck enemy's feet when flipped suggest baked in, but then the bricks, especially when Leilani roll jumps on them seem to suggest otherwise.
 
Anyhow, keep up the great work and devlog. Also, it feels like an interesting thing to have would be a larger scale representation of the negative influence of the machine at the end of the level - like not just some plants nearby, but, say, two screens worth of darker, less saturated look. Which then fades away as you destroy the machine. Would really show it corrupting the environment.

[Ashedragon]

I believe I remember Ishi saying it was added programmatically.

[Ishi]

I do have one more question though. For things like the drawing bounding boxes, how do you establish the relationship between an in-game entity and the "debugger?" Is the debug code local to the entity classes, or is there some other magic going on behind the scenes? Its one of those things I've thought about before but am never quite sure how to handle.

I have a thing that I call the Render Context which is a class that stores information about the rendering setup - for example the size of the screen/render target, and also whether debug rendering is turned on or off. This Render Context is passed to everything that is drawn, so then basically anything in the game can decide whether it wants to show some kind of debug thing if the render context says debug rendering is enabled.

For the entities and their bounding boxes though, drawing the bounding box at the same time as each entity wouldn't work as I want the bounding boxes to be drawn last, over the top of everything else. So the game world renders everything normally, and then if debug rendering is enabled, calls a separate DebugRender function on all the entities.

I don't know if this is a great way to do things, but it works for me!

One question - is the black outline baked in or added on the fly? Some details, like the duck enemy's feet when flipped suggest baked in, but then the bricks, especially when Leilani roll jumps on them seem to suggest otherwise.

I believe I remember Ishi saying it was added programmatically.

This post talks a bit about how the outlines work on the scenery. The outlines are hand-drawn, not automated, but are drawn on a separate layer. So the outlines for scenery tiles merge together, then entities are drawn so they can overlap the outline, and then the coloured part of the scenery is drawn.

For solid things like crates that can be stood on but are actually entities, the outline is just baked into the sprite so the overlapping outlines thing doesn't work for those. I could separate the outline out into a different sprite but that creates a lot of extra work, especially for animated things.

[Kasumi]

I've enjoyed this devlog throughout, and I'm saying so now that I'm logged in. I really, really enjoy Wario's moveset, but actually like a bit less the puzzley aspect of the series. My dream game is Wario Land 1 platforming with a Wario Land 4 moveset, and this seems to be real close.

[Ishi]

Buzz Enemy

Started work on a new enemy type! I have a specific use in mind for this enemy in a level, though I don't think I'll be including the level itself on this devlog - as I get into producing a good number of levels I intend on keeping some of them secret. There's got to be some surprises in the game!

For now it's called a Buzz, it's hard to think of names when I start writing code for an enemy! Proper names will be decided later. It's a flying robot that can carry things (presumably using magnets), and drop them on Leilani. It's fragile though and turns into a useless ball once Leilani hits it.



It can fly around on paths too, and its boosters angle themselves appropriately.

[JobLeonard]

 The boosters changing to affect it's momentum looks so convincing! Did you do that manually?

[Ishi]

The boosters changing to affect it's momentum looks so convincing! Did you do that manually?

It's calculated on the fly, basically the target booster angle is based on the X Acceleration (change in velocity) so as soon as it starts to slow down, the boosters angle in the opposite direction.

If I gave the boosters different animations for different strengths of boost I could also change that animation based on the Y Acceleration, so the boosters go stronger when it's accelerating upwards (see Cyber Shadow). But I'm happy enough without that I think.

[JobLeonard]

Ah, so reversed causality? You determine the path first, and then the physics required for it, and then the animations based on that? Clever!