next »

[Photon]

I said last week that I'd start putting together a level using a new mechanic. That didn't happen, I was still too excited about the moving platform improvements and decided to make some more! The systems I've worked on will go a long way to providing some variety throughout the game.

Paths

The first thing I added was paths. In Tiled I now have a "Paths" layer. Any shapes that I add to that layer (the left hand side of the image below) get loaded into the game as paths (visible in the game's debug view in the right hand side of the image).



You may notice that the rotated ellipse was the wrong size and shape after being loaded into the game... I've fixed that already.

Putting Objects on Paths

I next added the ability for any game object to be put on a path:



This image shows some of the different animation options I currently have for the path movement. Starting from the bottom:

• Linear looping
• Linear ping-pong
• Smooth ping-pong
• Linear looping, with start and end pauses
• Smooth ping-pong, with start and end pauses
• Linear loop, only using part of the path (useful for using a segment of a circular path)

It seems like most game objects are happy to be locked to a path. Here's a fun experiment:



Tile Chunks

Finally, I did a big refactor of my tile map code which allows me to easily handle loading, drawing and collision for additional tile maps. So in the editor I have a new tile layer called "Chunks" and I draw some tiles on it. Then I draw a box around it... and the tiles inside the box get turned into a separate tile map, and attached to a game object.

Here's an image of my first tile chunk. It's just a random shape. But it moves along the path and the collisions work pretty well! (I have a few bugs to iron out though).



Everything combined

I spent some time testing out various capabilities of the new systems...



Really excited to have all this up and running! I think I can make use of these systems to create more level variety without needing a large amount of hand made features specific to each level. And it should also be useful for creating fun little bonus rooms and things hidden in the levels.

Thanks for reading

[Artifice Machine]

Never found much inspiration to utilize paths...
This is very nice use though, got me thinking.

[Ishi]

This week on Leilani's Island...

A BBC programme called The One Show did some filming at the Norwich Gaming Festival and the footage was on TV this week. Was fun to see the Leilani logo on TV! (That's not me speaking though)



I've also been working on a new level design, the first pass of which is mostly done. The big moving block from a couple of weeks ago has now become this spiky digging machine:



It's inspired by Wario Land's Course 4:

[JobLeonard]

Oh man, I'm looking forward to this game so much! I haven't played a proper Wario-style platformer in ages!

[Ishi]

Start of July - Technical Month

Hi all!

A year ago I showed that I'd been working on  a tool to pack individual sprite images together into a sprite sheet. Well, this weekend I finally got around to making the game able to use these packed images successfully!



Here's the tool in action. I reads a series of commands from a file and then runs through them all. Sprite packing is the main thing that it does. The process for sprite packing is:
- Load all of the sprites definition XML files in a single folder, and load all the images that they use. These images can contain multiple frames of a single animation.
- Crop every animation frame as much as possible.
- Remove duplicate frames.
- Pack all the frames into the smallest size image possible.
This means I can lazily create animations that contain a large amount of empty space, or duplicate frames, and I know it won't be wasteful on memory in the final build of the game.

Getting the packed sprites and other data to work properly in the game took a while and involved fixing various bugs both on the game side and the sprite packing side. At one point it was a glorious glitchy mess, but eventually the game was looking perfectly normal.

I added some debug info for my resource loading system so I could test out the effects of the sprite packing.



This is the game running on raw unpacked data. Note in the top left, 573 textures loaded using 11.6MB.



And this is running on the packed data. 57 textures loaded - that's a good reduction! But now it uses 12.6MB, so the memory usage for the images has actually gone up.

I kinda expected this would happen - I'm limiting the packed sprite images to being power-of-two sizes (128, 256, 512 etc) so it's quite easy for the image to be way bigger than it needs to be. If the sprites *nearly* fit into a 256x256 image, but not quite, then it'll double the size to a 512x256 image instead, resulting in a lot of wasted space.

This is ok though. When the game is in its later stages I can be smarter about which sprites are packed into the same sprite sheets and make much better use of the space.

However I did poke around in the current images to see if there was anything obvious that is worth fixing. And I found this:



This is a horribly wasteful 1024x512 image! My packing algorithm was obviously doing a bad job at packing sprite sheets containing very wide sprites.



A quick bit of tinkering with the algorithm, specifically to do with how it chooses the size of image to try packing the sprites into, made this particular case way better. 1024x128.

And the improvements put the game's image memory usage down to 10.3. Hurrah!

[JobLeonard]

Because of the way PNG compression works, the bad packer might actually produce smaller PNGs though

[StateOff]

If you haven't looked into it this is the best resource on rectangular bin packing:
http://clb.demon.fi/files/RectangleBinPack.pdf

He provides reference implementations next to his survey:
https://github.com/juj/RectangleBinPack

Btw: Amazing work. Looking forward to this one.

[Ninja Dodo]

Just found this via PixelProspector. Looks really cool!

[Smerik]

This looks like Lilo acquired some kind of Sonic skills and found her way into the Mushroom Kingdom.
Must have. 

[JobLeonard]

Actually, now that you mention Sonic: my point of comparison was more Wario Land, but I haven't played it so I have no sense of how playing it "feels" in terms of in-game physics and response to input.

Ishi, can you describe how the platforming feels, using famous classic platformers (mario, sonic, wario, and so on) as points of comparison?

[Ishi]

If you haven't looked into it this is the best resource on rectangular bin packing:
http://clb.demon.fi/files/RectangleBinPack.pdf

He provides reference implementations next to his survey:
https://github.com/juj/RectangleBinPack

Btw: Amazing work. Looking forward to this one.

Thanks, that was interesting to look through! I don't think my current packing method is the same as any described there - I honestly don't remember whether my implementation was based on something or if I made it up as I went along. But a brief description is -
- Sort the rectangles with widest ones at the start.
- Place each rectangle as far left in the bin as possible. If there are multiple possible positions, place it in the topmost one.

A lot of it involves fairly brute force looping through positions, there's no clever storage of remaining free space. But speed isn't really a goal. And anyway, the time taken to pack the sprites is way less than the time it spends checking for and removing duplicate sprites! I wonder if I could speed that step up somehow.

Actually, now that you mention Sonic: my point of comparison was more Wario Land, but I haven't played it so I have no sense of how playing it "feels" in terms of in-game physics and response to input.

Ishi, can you describe how the platforming feels, using famous classic platformers (mario, sonic, wario, and so on) as points of comparison?

Wario Land is definitely a big inspiration on the game, but the movement feels very different. Wario (especially in the first game) didn't really accelerate or have momentum, even the jumps were extremely linear up and down motions.

Leilani is more like Mario, the jump has a more of a natural arc at the top, and she has more of a sense of weight. Running has slight acceleration to it, and rolling does too, although there are plenty of ways to instantly reach full rolling speed.

The main distinction with Leilani is that her jumps are intentionally cut down compared to the other games mentioned; she can only jump up 3 tiles. But bouncing on enemies/objects and off ropes gives you extra height, and wall jumping is encouraged!

The game is definitely nowhere near as momentum-based as the classic Sonic games.

[PypeBros]

Both velocity inheritance and large level elements on path are stuff I still have to add to my own engine... Nice to see them detailed here ^_^

[Ishi]

Hey all, sorry for the lack of a proper devlog post last week! I had a busy weekend and never got round to writing one. I have been getting work done on Leilani in the meantime though.

Build configurations
One thing I did was get the game's build configurations set up better in Visual Studio. I now have three configurations:

• Debug - all of my testing features are enabled (for example skipping levels, granting instant powerups to Leilani). The compiler doesn't optimise the code which allows placing breakpoints and stepping through the code, and inspecting the current state of variables. The code can run slowly in certain situations because it's not optimised
• Release - also includes all testing features. The code is optimised, so it runs at good speed but not as good for debugging.
• Final - The same as release but with no testing features! This build is for the finished game.

Steam API

Steam Direct became available a month ago so I took the opportunity to begin setting up Leilani's Steam page! I've worked on it here and there over the last month, but this weekend I began actually integrating the Steam API into the game itself. It all went super smoothly, the API is very easy to use. The game now supports the Steam overlay, cloud saves, and I've set up the process for uploading builds of the game to Steam.



The game's Steam page isn't public yet as it has to undergo a review process.

Rest of the Month

What I want to focus on for the rest of the month is making sure the game is robust and behaves nicely when things are broken/missing - so where possible it should display an error message rather than just silently crashing. I'd also like to take a look at control bindings - particularly I will look into what features Steam provides and how much I can benefit from that.

The Future!

Since I'm talking about Steam, I just wanted to make sure I avoid confusion - the game is not close to completion! This is just a convenient time for me to get the technical work done for Steam integration. Next month I'll be working on the world map, and then I it'll be levels, levels and more levels. Thanks for following the devlog and for your continued support!

[Smerik]

Nintendo Switch ^^?

[Louard]

Keep up the good work, man. I know I've said it before, but I am so looking forward to your game! If it turns out to be Steam only, I hope you;ll consider a Mac port. ^_^

[alaNintendo]

Looking great! The polish is amazing!

[JobLeonard]

Nintendo Switch ^^?

The Nintendo brand is definitely where you'd expect to find people who like this kind of stuff.

[Ishi]

Yep a Switch version would be lovely I'm focusing on just getting a PC version close to completion for now though!

Steam Page Now Live

http://store.steampowered.com/app/664640/Leilanis_Island/

The Steam store page for the game is now live! No release date, price, or anything like that. But it's nice to have another place that people can stumble on the game, see a video and screenshots, and crucially add it to their wishlist.

Input

I've tinkered with how the input for the game works. I'm not longer using the XInput API directly - SDL already provides support for XInput controllers, so I'm now using that. I toyed around with Steam's controller settings and used it to turn a joypad into an XInput controller which was recognised fine by the game.

Save Files

I also improved how my save files work. Options and Window settings have been split out into separate save files. Neither of these are saved to the cloud in Steam as they are all feasibly things that would require different settings across different PCs (Window size, audio levels, controls, etc). It seems better to avoid cloud saving these things, and just let the player set them up the same on each PC, rather than forcing the settings to be synced which will be really annoying in cases where you actually don't want them to be the same.

Window size and state is now tracked and saved properly; so the window will be fullscreen / maximised / the same size as it was last time you played.

Finally if the main save data fails to load for whatever, I've added flow to the game to handle that.



This is the last update for technical month. Hold onto your hats because next week I'll show my first progress on the world map, which is considerably more exciting than corrupt save files!

[LyricalReverie]

Nintendo Switch ^^?

The Nintendo brand is definitely where you'd expect to find people who like this kind of stuff.

Plenty of people who like platformers on Steam as well.

Anyways, this game looks so fun. I also gotta say I like how the developer is transparent about the inspirations for the game.

[TheGrandHero]

Steam Page Now Live

http://store.steampowered.com/app/664640/Leilanis_Island/

Awesome! Already added it to my wishlist!

I also improved how my save files work. Options and Window settings have been split out into separate save files. Neither of these are saved to the cloud in Steam as they are all feasibly things that would require different settings across different PCs (Window size, audio levels, controls, etc). It seems better to avoid cloud saving these things, and just let the player set them up the same on each PC, rather than forcing the settings to be synced which will be really annoying in cases where you actually don't want them to be the same.

This is how I've done it in my game as well with Steam Cloud saves. My laptop can't handle some of the settings, so it needs them off, but obviously I want my desktop maxed out. Likewise, if a game saves a specific screen resolution setting (instead of just rendering to a buffer and resizing it up to the user's screen) it'd mess things up to try and share that across computers with different resolutions.

Finally if the main save data fails to load for whatever, I've added flow to the game to handle that.

Do you keep the previous save as a backup file just in case the main save file corrupts for some reason? I've been doing this for my games when save slots are involved, and I've noticed a lot of other devs have done the same thing.