I've managed to make a little bit more progress on the platforming front yesterday for pushing and carrying things around.

I had a basic way to push objects pretty similar to how I used to have it set up in Verge, but now with all the fancy features of C# I'm able to do it in a more clean way. My old GML GameMaker code definitely had some if statements that went across the whole code window and more, so hopefully this version ends up being a little bit more organized than that.

So pushing one single block around seems to be working well enough now, but when it comes to big stacks of blocks there might be some problems.

My ideal scenario is that a stack of objects can be carried by another object, and I also want to make it work with pushing objects as well. Objects that can be pushed should always push each other, so a long stack of boxes should be able to be pushed by a moving object, and then after that I can take care of things of how much an object should slow down when pushing and all that good stuff.

On the real life front I am still in the middle of moving chaos, so things are a little weird for me still, but I'm somehow managing to make something work with my laptop at a coffee shop.

Game development ain't all birthday cakes and flowers as some may have you believe. As I move forward with this platformer game I'm realizing how much I actually don't know about platforming! You might think I know a lot with so many platformers under my belt, but now my ideas are way outpacing my abilities as a programmer.

Right now I'm trying to code this system and I'm making little to no progress even though a lot of code is being written. For example I'm currently working on the structure of how objects will update. The simplest way at first is to have each object go through its platforming operations one at a time in their execution order, but this leads to weird issues down the road. An object higher up in the order will have priority over other objects, and this is not something I want!

My new approach is to have each object update in parallel with one another, one pixel at a time. Each object will calculate its speeds and then buffer them into their remainder. Then a PhysicsHandler object goes through and moves all of the objects one pixel at a time each in parallel. This might not make any sense at all, but it's a set up for objects being able to push one another. For example if two moving objects collide, I want them to collide in the right spot, and I think the only way to do this is to move them one pixel at a time in parallel.

So I'm also working on the ability for objects to push one another. I have a simple box that I want to be pushable, but also solid so that objects can stand on it, and also I want it to be carried by other objects as well... but so far that is presenting a lot of challenges for how I've already coded things. For example I have no idea when I should be registering collisions on the side of a moving object now that objects can be pushed.

My assumption was that when I went to move one pixel to the side I could simply check for a pushable object and push that object to the side... however with the current way I check for surrounding collisions the results are not quite what I want. If an object can both collide with, and push the same object, the push only happens for one or two pixels and then the pushing object believes it's in front of a wall so it no longer moves.

As you can see I've already rambled for a number of paragraphs and I feel I haven't even scratched the surface of what's going on! I've been looking at my old Game Maker games platforming code to see if I can learn anything from my past self, but unfortunately the code leaves a lot to be desired. In Verge I did have boxes working that could be pushed, carried, and stood on, but I didn't cover a lot of corner cases and designed levels around not having huge bugs appear. I'm totally sick of designing levels around bugs though and I want to do this right! Unfortunately that means I'm driving myself insane as I try to handle all the possibilities I can imagine with this platforming engine.

I'm not feeling super great and I feel like everything sucks right now, but I guess I'll keep working on stuff and hope I can figure out small bits of it at a time.

I'm continuing on my journey of focusing on my little platformer prototype and ignoring all of my other projects for the time being. I'm still having fun with it, and it's what I've been working on when I set up in coffee shops around the Phoenix area. I'm still in the middle of moving so I've just been working on my laptop. I no longer have access to four monitors for the time being, but maybe that's a good thing?

I've been poking around with adding ladders to the potential game idea. I like the idea of ladders that can bring the player (or any platformer object) through solids. I don't think I see ladders in many platformers and I'm starting to see why as I try to code these things. I thought it would be pretty straight forward but it's a little bit more tricky than I thought.

Having ladders that can pass an object through solids can create a way to totally separate different spaces of a level which I like, the only problem is the weird edge cases that appear because of those rules. I have ladders mostly working now, but if a moving solid interacts with the player currently on a ladder then some pretty messed up stuff happens. I still have to figure out what's going to happen in that case.

Another thing to consider is moving ladders! Which might make things a little crazy. Right now all of my platforming objects operate independently, but I might move to an approach that involves a manager object that controls the order of execution of certain events. For example having all moving solids, moving ladders, etc, do their thing first might make things way easier. Also having objects check for neighboring objects all at the same time before and after movement would be more ideal than each object just moving and checking in its execution order.

That's it for now. Back to work! I have to catch up on some things I've been neglecting for this project, whoops.

I've been pretty productive on coding stuff lately so with that comes some updates for Otter! Here's some of the things that have changed or been added lately in the dev branch:

* OgmoProject has a lot more utility methods now like GetValue() and GetLayerData(). If you need to check out level data before actually loading a level into a Scene this can be pretty useful.

* Added OgmoProject.RemapAsset() for when you need to assign a different path for an asset being referenced in your Ogmo projects. For example if you need to take the path of a tilemap from the ogmo project and reassign it to something else when being loaded into the game.

* Fixed a thing that I broke in SetHibox on Entities.

* Util.Clamp now supports Vector2 input and output.

* Added shortcuts to Scene methods like GetEntity<> on Entity just to make code a little bit less verbose at times.

* Added Button.LastPressed and Button.LastReleased. These are both timers that will count up since the last button press and release respectively. Pretty useful for doing input buffering type stuff, or waiting until an input has been released for some amount of time before changing state, and all that kind of stuff.

* Added GetFillRect() to NineSlice.

* Made Debugger.RegisterInstantCommand() public and added Util methods to go along with it. You can now add debug commands that can be used immediately instead of executing them at the next update. Also fixed some bugs in the debugger related to this.

* Fixed the rendering of GridCollider (it was too large by 1 pixel for each cell.)

* Added GetTileIndex() to Tilemap and GetIndex() to TileInfo.

* Texture.CopyPixels now actually works (warning: blittng operations are very slow.)

* More Collider parameter options in all of the Collide, Overlap, etc methods.

* Added Scene.GetEntitiesWith<> which is a weird way to grab a list of Entities that have a specific set of Components. This is probably very slow and should be used sparlingly, but it might be useful to some folk.

* Various small fixes and tweaks that don't really effect end users.

My travels for the year still have not ended! As it turns out I'm currently in the process of moving, so everything is at least a little bit chaotic. I'm staying with friends just going to coffee shops with my laptop to work on stuff, and in that way it still feels like I'm on the road even though I'm just a few miles away from where I used to live.

I'm using this time to focus on my platforming prototype for now and totally neglecting almost every other project I have spun up. I suppose at some point I'll do a review blog post to go over the status of all my projects.

Most of what I've been working on is the core "physics" of the platforming stuff. I'm referencing Matt Thorson's technique for most of what I've been working on. One of the things I'm playing with transferring momentum from the platforms to the player when the player stops being a passenger for the platform.

I'm slightly referencing the memory of the Mega Man X games for this which have a little bit of this when you jump out of a moving mech. You keep the platform's speed with you until you collide with something.

On top of that I'm working on slopes, which can be a huge pain in the butt most of the time. It's easy to get them going, but then a lot of the simple assumptions that are made with the physics engine get a little more complex. It's no longer the case that a player is against a wall to the right if they have a slope next to them, and all that kind of stuff.

Whenever I work on a platformer system I always think of the past however-many platformer systems I've made and how they're all pretty much the same. I've more or less been making the same platforming engine since Bonesaw: The Game and I've just been slowly refining it over the years. I still run into a lot of the same issues whenever I go through it which is like some sort of weird Groundhog Day type nightmare, but platformers are the most fun thing to work on (I think) so it's totally worth it.

The last Otter example I was able to jam out before leaving for PAX was all about Text and RichText. Text seems to just be insanely difficult and time consuming to implement, so making it really easy for users of Otter was a big goal of mine. For most simple cases of using Text, Otter should accomplish that goal!

Here's a quick example of just some normal text using some simple effects.

For doing text beyond that Otter has a RichText graphic object that can be used. This allows for some more advanced things such as limited text boundaries, word wrapping, text align, effects applied to specific characters, animated text, and more, but RichText is also less efficient for rendering larger blocks of text.

For the full example head on over to the Otter example.