Mudtato
Flying
It’s been a productive couple of weeks, and development has been going consistently well. I’m still having great success with Unity, so I’ll stick with it.
Most of the core game mechanics are done, to at least an MVP level, including:
- Camera controller
- Character controller (run, jump, double jump etc)
- Background/foreground parallax
- Slopes
- Disappearing platforms
- Falling platforms
- Moving platforms
- Conveyor belts
- Sticky surfaces
- Slippery surfaces (needs more work)
- Climbable objects
- Launchers
- Spawners
- Enemies (idle, moving, flying, jumping, following, projectile)
- Collectibles
- Breakable objects
… and more. So yes, quite happy with the progress in a limited amount of time.
To be fair, most of this stuff was already in my previous, custom engine, but it’s been much faster and easier to do in Unity.
The progress on the development side of things has enabled me to spend some time on the art. I’ve created a few prototype models of some enemies and have been looking at some different colour palettes.
A lot done, a lot still to do.
Unity
Well I’ve only spent a day in Unity so far and I’ve already got a surprising and significant amount done (incl. movement, camera, moving platforms, death/restarting). It was definitely the right decision to make the switch.
I can’t see the core platformer mechanics taking more that a month to iron out, and then I can focus on level design and asset creation.
Excited.
April Fools!
I’m not building my own game editor, like Unity or Godot. I can’t believe you fell for it.
Of course my focus is 100% on finishing my game, and going off on a tangent to build an editor is definitely not something I should be doing.
I wish I could say that was the case, but sadly it was not…
I did make some nice progress on an editor, and it may still have a case somewhere down the line, but right now it’s just a big distraction. Unfortunately I enjoy that side of development too much, probably due to it being similar to my day job (which, strangely, I don’t tend to enjoy).
I thought I might explore the possibility of throwing out the game engine along with the editor, but after playing with Godot for a bit and looking at Unity, I decided it wouldn’t be worth it. I’ve already built so much, and (I think) it works well.
So it’s back onto the game/game engine proper, and maybe we’ll see some real gameplay soon. Maybe.
Edit: I’m going to give Unity a try for a week and then make a decision. The sad (and good, I guess) thing is that it’ll probably only take a few days to get to the same point it’s taken me months to get to so far with my own engine. It’s all been worthwhile, but it’s time to shift priorities to finishing the game.
How did I get here?
Somehow I’ve found myself building an editor for my game/engine. Last time I checked I had set out to make a game.
There are a lot of comments online about people who wanted to make a game, started building their own engine and then never actually made a game (or an engine in most cases).
I’m nothing like those people…
Anyway, I’m using .NET MAUI (with Blazor), so it can be a cross-platform editor. It will probably only ever be used by one person on one platform, but do I care? Nope, because I love building stuff. I’ve only spent one afternoon/evening on it, and only really got as far as a basic layout and selecting and moving objects around.
Ah, I remember how I got here now… As I was making ECS related changes I thought it would be best to abstract all of the components out to a class library, so I could share them with a separate editor project. Up until now the level editor has been inside the game, and really hacky.
Overengineering
Perhaps I was too busy thinking about if I could and not if I should.
Looking at DKC2 there’s never more than tens of collidable objects on screen (often less than 10). If that’s my inspiration then it’s a bit ridiculous to be optimising for hundreds of collidable objects.
There’s also the topic of collision in general. I like my current point-based collision system. It’s accurate and feels good, but does the game really need it? Probably not.
I’ll try out a couple of different ideas, e.g. capsules and a silhouette based system, and go with what works best.
On the plus side, I’m absolutely loving ECS.
Duh
So after yesterday’s genius level discovery that rendering a large number of large textures can decrease the FPS (who knew!?), I thought there must be some other rare and hidden wisdom out there to optimise things like collision.
Lo and behold I came across quadtrees and added them to my collision system. I did previously have a basic method to check if objects were close enough to each other before checking them for collision, but nothing as Mondrian as quad trees.
I’m also a big fan and user of LINQ in my day job, but I’m going to remove it from some of my systems and see what sort of improvements I can get.