Really interesting concept ... maybe when you have a group selected you can press a key to pass the ball between members of that group?

Thx Rusk!

Update: This week I implemented the Path Graph, a data structure which stores information for more efficient path-finding. This is a necessary optimisation to allow the path-finding to work fast enough on big levels with many path-finding agents.

The Path Graph caches all walkable tiles, roughly guesses where jumps and falls may occur, and will eventually include info about bridges, one-way platforms, ladders, and so on. Then, instead of examining the world directly, the path-finding routine uses the graph.

Here's a screenshot of the PathGraph. A yellow line links two tiles if an entity could potentially jump from one to the other. A pink line designates a fall between one tile and another. To optimise this further I could cull many of the yellow lines by doing simple path-collision checks -- but I'll leave that for another day if I see performance issues. For now it works really well.



The Pyre/Volcano level is coming along nicely. The area will be split into the volcanic terrain part, and an underground cathedral-type structure. At the very base of the cathedral will be The Archive, an abandoned repository of knowledge with stacks of books and bookshelves. A creature we're calling The Librarian will roam around this area.

The cathedral itself will be split into multiple sections, connected by long diagonal tunnels, and the entire area will be a mix of reds and purples.



We've also started on the concepts for the Veil area, things are moving quickly now. Next week I'll go through the designs for the labyrinth in the Veil. Lastly, here's a gif of the jump links in the Path Graph which are updating dynamically as I modify the world.

Cheers!

Update:

This week I've been implementing A*-pathfinding for the AI -- this will allow enemies or NPCs to find a short path through the world to moonman or some other target.

Starting simple, here is a case where the target location is the top of those tiles, and the knight knows that he has to take a series of jumps on the left hand side. The planner knows how to move and jump and searches the entire nearby space for the quickest route to the top.



Here's a more complex case. The squares show the potential tiles the knight will move through, and each one is checked for collision. If a tile is blocked then the path-finder will find another way around (if there is one).



One interesting problem I had was to predict which tiles a human would move through as they jumped. To solve this I assumed the jump path was perfectly parabolic, which isn't exactly correct, but a good enough estimate for now. The problem then becomes: given start and end locations and jump height, what parabola goes through those points?

A page or two of algebra, and many mistakes later, I ended up with the equation. You can actually play with the equation over here on Desmos. For that equation I assumed the mob was at the origin and wanted to jump to point q, with a height h.



You can then trace out the parabola in tile-space (adding the human height along the way), and if it collides with a block then you know the jump won't be successful. In terms of A*-search, this path (between p and q via a jump) would be invalid.



You can see the behaviour of the path-finder below. As I move the target around the algorithm finds a new shortest path.



It's important to note that the path is an ideal path, and assumes a perfect ability to jump between platforms, etc. Following the path is another thing altogether (especially in a physics simulation) and the success will depend on environmental factors, the physics state of the mob, and some how precise the AI-control can time things. But for the most part a mob will be able to follow a path fairly well .. and if it fails at any point then it'll simply re-plan and try again.

Here's a video of a knight following a path. He's pretty good at jumping between all those platforms, although halfway through he fails a jump and has to re-plan the route.

And here's a gif or a knight following Moonman (crunched to a few colours because of it's size):



The implementation is super simple at the moment and there are a lot of things that the pathfinding doesn't consider yet, like doors, sloped terrain, bridges, platforms, ladders, etc. These will all be brought into the system one by one until we have some semi-intelligent mobs that can't be tricked so easily.

The path-finding and path-following components are just one piece of the AI system, but I think it'll be the trickiest to implement. One necessary optimisation I need to add, for instance, is to cache the graph for the A* system. Being tile-based, Moonman has part of a graph already (just use the tiles and their neighbours), however it doesn't account for jumping to and falling from ledges, and I'll need to find and cache that info whenever the world geometry changes.

It's interesting also to consider how A*-search would work if entities are allowed to modify the world/graph. For instance, if an enemy in Moonman could mine through a wall or build a bridge, how would that effect the pathfinding system? I assume it's a very difficult problem to do well, although some basic logic for hacking through a wall could push the game in a very interesting direction! For now though, it's in the todo-later basket.

Another interesting thing I've been thinking of is path-finding or following going wrong. Consider a "dumb' enemy. Would he make a bad plan? Would he make bad assumptions about the distance he can jump? Would he cancel a plan halfway through? When coding the system I stumbled across a bug that revealed a strange, but entertaining, behaviour. Here the knight believes the shortest path to the spaceman is to bunnyhop the entire way. See you next time!

Update: This week I've been teaching the AI how to jump. [...]

I'm not sure if the analytical approach is that complex as you don't seem to steer mid-air..

The jumps are not pure parabolas, see the gif with the two knights. They don't move at a constant speed horizontally and their vertical accelleration isn't exactly constant either. Some variables that make the analysis complex are: jump force, jump duration, mass, move duration, move speed, a pause at top of jump, and dampening on horizontal movement.

A parabola would be a decent estimate though.

Update: This week I've been teaching the AI how to jump.

A simplified version of the problem is this: In order to jump N units across, how much vertical and horizontal force do i need to apply?

One way to approach this is analytically, by calculating the trajectory an entity would take if he jumped with a certain force, and then using the inverse of the equation to get the force required to jump a certain distance. Depending on the complexity of your physics engine this may be possible; however, the simulation in Moonman is too complex (esp. as it uses Box2D) for me to try this.

Another approach is experimental: simulate a whole range of jumps inside your game and use that data to inform you jump calculation. This is exactly what I've done. After setting up a test harness, I simulated a mob of humans jumping with varying jump parameters (equivalent to a player's duration of jump button pressed and duration of move button pressed). From this I extracted the distance and height jumped, and plotted it below. Each blue point in the graph corresponds to a certain (jump,move) parameter.





Analysing the data I saw a few interesting things, which I've outlined on the rough diagram below. Most importantly, note that to jump 3 units across, there is a minimum vertical force we need, and a maximum height we can reach based on jump force. For a jump that spans 3 units we can have a low jump or a high jump, or somewhere in between.



I then processed this data with a Python script to get the minimum and maximum jump parameters for each jump distance. In the code below, for example, you can see that to jump 2 units horizontal with a minimum amount of force, you need to have your jump = 0.01 and move = 0.073. These values directly map to how long the AI holds down the jump button and the move left/right button.



Here's an early test of the system. Lava added for malevolent reasons. Goose-knight is ok at jumping, but not good enough, and must suffer the consequence.



This approach doesn't factor in vertical height. For example, jumping 3 units across and 1 unit up will require different parameters than jumping just 3 units across.

We could solve that problem with experimental data. But I've decided to fudge it: if an AI wants to jump N units horizontally and 1 unit vertically, I simply add a little to the jump parameter and remove a little from the move parameter. If it wants to jump 3 units vertically, I add more, and so on. This approach seems to work so far, and because you can adjust your horizontal movement mid-air there's a little lee-way with this.

Here's a (sped-up) gif of some mobs jumping around between platforms.



And oh! I've discovered a glitch in the game, which I call the splash jump. If you walk off a ledge and jump just as you hit the water, you'll jump about a block higher than normal. This is because when you're in water your jump force has a multiplier. I could remove this bug but I like it, so it stays.



But, like always, it's the malfunctioning code that is the best. This guy was really struggling with the concept of jumping.

The devlog marches on! Will I ever finish this thing?

Update: I've begun work on the AI system. My immediately goal is to have more intelligent enemies and NPCs. They'll eventually be able to pathfind around obstacles and will be smarter during combat. In addition they'll have more behaviour types; for example, a warrior with a guard behaviour would only chase the player a certain distance before returning to his post.

Here's a gif of the first steps of the new system.

If I get time I really want to implement a few idle actions to add more character to the game. Imagine watching an NPC walk over to a chest, take out a rock, and then throw the rock into a hole. It's a nonsense set of actions but it links together the different aspects of the world, which is important if you want the world to feel alive and cohesive.

I was thinking about this game again today. Was curious how I would do it now, so I redrew the portraits. At such a tiny resolution I'd stylise them way more.

Saw this at GDC and it looks ultrarad. <3

How was Seattle? Did you see Pike Place Market?

Seattle was cool. Stayed with a friend who works for Amazon AWS and it was crazy to see how big that company is ... inhabiting like 5 sky scrapers and building more. Yeah we went to Pike Place Market and I bought a banana. The EMP museum was quite interesting - I loved the little sci-fi section with props from Alien, Terminator, Fifth Element, etc. Overall Seattle was interesting but it seemed way too cold for me. Portland was super chill and I'd love to spend more time there. SF was a weird mix of ultra rich and poor, not sure I'd like to live there.

Update: I'm back from the USA. Here's a post about my trip. GDC was amazing and it was awesome to meet so many of my TIG friends there. I got to see a talk by the Rain World crew which was super inspiring, that game is coming along really well!

it is pretty impressive from a technological perspective since Yoshi actually leans/runs downwards against the distortion.

Oh really? That sounds pretty amazing :D

> You have to use this somewhere! It could be the Moonman equivalent of Touch Fuzzy, Get Dizzy.

Oh yeah for sure. I have a similar effect already when you wear one of the masks.

Update: The final closed alpha build is now out for Windows and OSX. If you're a tester then jump on the Alpha forum and please leave some feedback. Now I'm off to 'Merica for a few weeks!

Hey eigenbom, nice cameo in Blitz Breaker.

Hehe, yep

Update: Hey all, the devlogs will be going on hiatus from now, as I'll be in the U.S.A. until the start of April. The next few days I'll be wrapping up the next Alpha build, and will hopefully have that up by the end of next week.

This week has involved lots of miscellaneous things: we've added a new small town area, a new teaser volcano area (that has basically nothing except lava), added in a few more item sets (dungeon, gold, and bone), and made sure that lot's of creatures and things are available for the next alpha. One thing I won't have time for is balancing, so the next build will be looser, with just a bunch of stuff thrown in.

Here are a few of things we've been working on:

Website has been updated with new screenshot, pre-order widget, and team avatars.

I've added pop-up labels to items:



New weapons and background decorations.



Some new backgrounds and areas, like the town:



Oh and there'll be a new character available: Carl. In the final game you'll have to unlock him, but in the alpha he'll be available to play. He starts with a powerful laser gun that has a small number of charges.



And that's it. Thanks for reading and I'll catch you back in the devlogs in April!

lol, hundreds of skeletons. nice. great way to test system memory.
i dont have much to say. ill just leave my post like this.

Yep love them skellingtons. Thanks for commenting, it's pretty quiet on my TIGs devlog these days.

Dammit! All these screenshots and animated GIFs are making it WAY TOO HARD to wait for this game! BOOO! But also NOT BOOO!

Ha, one day, when you're like 90 years old, you'll hear that Moonman has reached v1.0.

is love a collection of molecule?

♥

my love for you is more than molecular

This looks just amazing!

thanks!

Update: Lots of misc updates and fixes this week. I also fixed two core issues that have been around for a while now:

Threaded-loading bug
Memory allocation
The first you may see sometimes when you change to a new area as a bunch of warnings that appear, saying something like 'resource unavailable'. That's fixed now. The second was much deeper and required 2 solid days of refactoring how memory is allocated in the game. I'll leave the details out, but the new system is much more flexible and I fixed some bugs along the way, too. Hopefully this'll fix some of the random bugs.

To test out the memory system I was having fun spawning hundreds of skeletons. The renderer runs too slow to be fun but it's nice that the game doesn't crash .. it just keeps allocating more memory as needed. Other fixes: Fog Of War is now saved between areas, the controller support is fixed (how long has it been broken?!), and a crash caused by the auto-save should now be fixed (by upgrading the boost library).



The backgrounds are still being worked on for the main areas and sub-areas. Here's a preview of the town area:



In terms of progress, we're running behind schedule. We'll definitely be pushing out another alpha in two weeks with all the changes we've made over the last 4 months, but the closed beta will have to wait until after GDC.


 

The ASCII level previews are a cool trick (how Dwarf Fortress of you, as well!)

Thanks, yeah I love it, it's so useful. The engine doesn't need to load up half the resources and can just dump the map and then exit -- makes debugging dungeons super fast.

woah moonman just turned into meanman

the happy grin continues to convince people he isn't a murderous psychopath

just to reiterate, moonman isn't good or evil. he just is. him eating someone isn't an act of anger or violence, a person is just a collection of molecules.

Super late to the game on this but this is really shaping up to be a great game!

Hey, welcome

those alpacas look great

Cheers I like them. Although I call them horses because that makes them seem more derpy.

Hey, the green one is that Pokémon.

Probably!

Update: Dungeons are a type of sub-region that appear in different areas: the forest has ruins, the mountain has tombs, the veil has the labyrinth, the volcano has the lair, and so on. This week I fleshed out the structure of some of these.

The ruins will appear mostly in the forest, and consist of a small set of rooms, loosely connected and obviously abandoned. Here's an example of the structure in ascii-form. The entrance has been generated at the lower-right and a treasure room two floors above it. The ruins will be rare, but if you find one there will probably be some interesting items in there.



I'll typically print out an ascii version of it to inspect the global structure, but I also try to play within the level itself to get a feel for it. I also take lots of screenshots and paint over them with concepts, which I'll then fit back into the algorithm. Here's an example of a generated ruins-level that I've overpainted with some ideas.



The tombs will appear in the mesa/mountain level and will be much bigger than the ruins. I imagine they will be a very dangerous place, full of the undead and curses. They'll probably reach a maximum of about this size:



In terms of the dungeon generator, I'm trying to create a set of high-level structures, and then low-level details and connections. For instance, one type of dungeon may actually be two separate dungeons joined together with a horizontal tunnel (as shown below). I think if I have enough variety of these high-level plans then dungeon-exploration should be a lot of fun!



Alex has been working on some of the backgrounds this week, and he'll continue to refine them for the next few weeks. Here's a sneak peak at the new volcano background, which I think looks totally awesome.



And finally .. if you head over to this topic you'll find some Moonman comics and sketches, featuring the amazing work of @salt and friends.

Update: There are now more interesting features above ground in the forest area, such as hills, bridges, and an occasional chasm. Below ground I've started to add some ruins and bits and pieces.



On the art side, Alex has been working on the creatures again and we now have a basic system in-place that allows us to create variations of colour and features. You may now stumble upon a rare blue laser horse during your adventure.

This looks great! Good luck with dev