next »

[whistlerat]

Version 0.9 - Zones 2.0

The last pass was over the 'zone' screen, as seen in an uglier iteration way back in 0.2 and a slightly less ugly one in 0.6. Zones were already a 'natural landmass' in 0.6, but the city-targets were still just clickable buttons, and all that functionality had been pretty much broken. The actual using-monsters-to-attack places is still broken because I'm going to be overhauling and refining it, no need to drag around obsolete code. But the point of this milestone was just to get the actual zone working with it sub-areas and 'points of interest'.

The current design for the gameplay revolving around these screens are this: each zone will be entered via a starting portal, seen in the gif in the previous post as the 'already active' one. This portal is the point of interest in an area, which is both neutral and traversable. Because it is traversable, all neighbouring areas become 'accessible' - IE, the stuff inside them can be interacted with! And then each area also asks itself, am I neutral and traversable? An area is neutral if it is not being protected by a city, and it is traversable if it is both neutral and accessible.

In this way, the map becomes a graph of edges and vertices, with each vertex representing an area, and each edge representing that the two connected vertices are neighbours.

As this map became more complex, the algorithm needed to correctly identify the status of each area was forced to evolve. For example, before I thought about ending turns and the need for cities to re-establish themselves, I was able to use a fairly simple algorithm:

For each area:
- Check if self has portal. If so, area is automatically accessible, neutral and traversable.
- If no portal, does a neighbour have a portal? If so, area is accessible. Check if self is neutral (has active cities) and traversable.
- Update all neighbours. This step was necessary just in case a neighbour had already been processed, and didn't realise that this area was traversable, perhaps, which would thus have made the neighbour accessible.

This algorithm worked at first, but then I wanted to add cities being able to become active again. This was easy in and of itself - I just reused code that I'd written for the cities previously - and when asked to refresh, the map did so according to the rules above. But it meant that you could have 'active' areas (in lightest grey) which no longer had links to a portal. I had to stop and think how I wanted the maps to work, and knew that I wanted the accessible/traversable areas to be directly linked to which portals the player has managed to activate. Once activated, the portal is owned forever, allowing some permanent progression across the map.

So then I had to tweak my area-checking algorithm, and in so doing found that it was irreparably inefficient because it would result in many many repeated checkings of each area since it would go neighbour -> neighbour -> neighbour ->  This was a problem of it before, of course, but ignorable since the situation had been relatively simple. Scrapped it.

Since accessibility is defined by access to portals, then, it makes the most sense to have the algorithm start at the portal and spread out. If it doesn't reach an area, that means it can't reach it, so it would be inaccessible.

New process:

- Set all areas as inaccessible, non-neutral and non-traversable.
- Start at the origin portal (predefined and always existing), and set that area as accessible, neutral and traversable
-- Check each neighbour of the portal, processing them and then adding to a 'this area has been processed' list so that no area is checked twice
-- For each traversable non-checked area, check all of its non-checked neighbours recursively
- Repeat for each activated portal (since you could have multiple accessible areas which are isolated from each other)

And this works pretty nicely.

Example of part of above:

Starting at portal


Checking status of neighbours


Since one of the neighbours was found to be traversable, checking its neighbours (but not the original portal area):

This whole process happens everytime something changes, which triggers an event (using Unity's EventSystem) which the zone is listening to, so that it knows to refresh itself. It doesn't care what the change was, or what caused it - it gets a carrier pigeon saying 'HEY YOU UPDATE YOSELF' and it obliges. This way the zone is always accurate no matter what has happened. Since changes only happen due to either 1) a single direct user action or 2) ending the turn, this refresh doesn't happen often at all so isn't expensive.

That covers the areas, but what about the points of interest within them?

These gifs show 4 types: portals, dungeons, cities, and wild zones. I've already discussed the purpose of portals, above. Cities exist to present challenge by way of obstructing progress, and to offer one reward mechanism (being able to pillage them), and so far the only way to overcome them has been to attack them with monsters. As suggested by this gif, though, that's going to change:

yay wiggling

For those players who would rather not use their monsters for violence, or just prefer having options on how to behave and progress, I'm going to allow bribery and completing quests as viable methods for gaining access to a city's area. Bribery is self-explanatory, but the 'questing' aspect is something I'll go into in the future once I've fleshed the idea out more. Needless to say, it will be fairly simple, perhaps on par in complexity as the 'attacking' option (which will also be much developed in a future version).

The wild areas merely allow direct access to the already-shown scene for trapping and catching monsters. This just makes them a little harder to reach, something to want to gain access to the map for.

Dungeons (which is a catch-all term I'm using for things which generally hold treasure and non-civilised monstrous things) are going to be my next focus, I think, so I'm also going to hold off on talking too much about them and end this devlog here.

This has also been a fun venture into gamefeel and UX, which I could go into if anybody is interested.

Have a good one, everyone!

[whistlerat]

This one was difficult. Lots of text ahead, I'll get some pics in at the end!

This entry of the devlog isn't particularly interesting from a 'what progressed in the game' standpoint, but hopefully it is from a 'game making process and its struggles' one. This game is already the most advanced project I've made so far, which, considering how early in development MH is, says a lot! Like many fellow devs, I'm full of ideas and am easily excited by new ones, and tend to get sidetracked, leaving old projects behind to gather dust. The whole point of MH, and keeping this devlog, was to keep myself honest and motivated - which is perhaps part of the reason why I didn't let myself give up, and because I'm better than that!

I don't think I've mentioned it on this log, but I use Trello. For every one of my '0.x' versions, before I let myself touch the game I would stop and think about what this version was, what it needed, and all the individual pieces that would be needed to bring that version to completion, and made cards for all of them. Sometimes the cards would change or become irrelevant as I made progress, but having that baseline of 'all these features are required in this version' is an excellent driving force. It gives me clear focus, it allows for a nice reward mechanism (putting cards in 'Done' is always a good feeling) and it lets me see the end of the tunnel, if development is starting to feel like a slog.

I also treat myself to a new Lego Mixel at the end of every version because I know how my brain works, and rewarding myself for good behaviour helps me build better habits and keep them

So what was the problem here?

Before I started MH, the idea had already been rolling around in my head for quite a long time in one form or another. Once I'd decided on the overall theme - monster collection and breeding - I sat down and wrote as many '0.x' versions as I could that I thought would make sense, mostly to make sure that I had a record of all my ideas so that I didn't lose them. These pre-decided versions took me up to, roughly, 0.8 of what's in this devlog. There are a whole lot of other to-do lists that I've not touched yet, waiting for the right moment. So it's not that I don't know where to make progress at all - but I got to the end of the last version and didn't know the right way to progress, and nothing I'd thought of previously gave me an obvious pathway.

I also realised that I'd suffered from getting too excited too soon and making hasty decisions. Namely, the whole 'portal/city/dungeon/wild area' thing in the map previous - it was roughly in-line with my ideas, but not fully thought through. I've known from an early stage that I wanted there to be locations you could visit, which served different purposes. One, you visited to capture monsters. I've actually already implemented a version of that, a while back. Two, you would visit to fight/overcome in some way - which I've already kind implemented with the 'attacking cities' feature also visible in this devlog. Attacking cities would get loot, maybe experience for your monster... maybe other stuff... it was something that I just put down mentally as a 'I'll figure out the details later' and in so doing dug a bit of a hole for myself.

That early choice to conceptualise it as 'cities' was what resulted in the castle motif in the last version; I thought, maybe they'd represent people and entities which owned territory and you'd defeat them to claim their territory and progress through the maps, ideally to reach the more useful wild areas they were protecting. All well and good. But then I started to overcomplicate matters. What if I let cities not only be attackable in order to 'neutralise them', but bribable, or maybe offering quests? Like to give them a particular monster, or to defeat another thing on the map somewhere? What if there were things which weren't cities, per se, but still attackable? Like caves, or dungeons, that just gave you loot, or were the object of quests? What if cities could be destroyed/neutralised, but dungeons were repeatably lootable? But wait, a traditional dungeon might have something like a necromancer and undead army, but also would have monsters... so does it make sense to separate dungeons and wild areas, where you go to trap monsters? What if I combined them? But then I suddenly needed to design a screen which would let you simultaneously attack a dungeon (which is a whole system that I haven't yet talked about here) while also be able to place traps, but what if a particular dungeon doesn't have monsters, does that need a unique one? What about keeping things simple and recognisable? What if I built dungeons like a series of rooms, and each room had something in it - loot, monsters, enemies, nests with eggs - and you progressed through them? What if I made it more interactive and you chose which monsters to take and actually moved them through the rooms, choosing where to move them based on their abilities and what was known about the rooms?

And cue brain slowly melting and clear vision of the game growing fuzzy.

So I stopped and asked myself: what am I trying to make, here, exactly? And I looked at what I'd made so far, and at what I was struggling with, and realised what a small part of the overall experience that this really should be. The primary goal of Monster Husbandry is to obtain and breed your ideal monsters. That's it. Every mechanic the game offers, every challenge, every obstacle and every reward should be with that in mind. What on earth was I doing going off thinking about building some kind of a crude dungeon crawler in a management game about breeding monsters? So I scrapped it all, closed that Trello board, ripped out all the nonsense from my repo and got it back to a decent starting point, and thought about it again.

Ultimately, I want the map to be a source of two important things for the player. Firstly, a way to get wild monsters. Secondly, a way to challenge the monsters the player already has. So all of the city/dungeon/bribe/quest/etc mess has all been neatly rolled into the concept of a challenge, the details of which can more easily change. A challenge presents a way (or more than one) to overcome it, usually through picking the right monsters. (I'll be going into more detail on this feature at a future time - but for now, imagine an example of this as 'to defeat this tower, you'll need a monster which can either climb, fly or teleport') The challenge also offers a reward for successfully completing it. This can be anything, maybe money or loot or monsters or eggs or the ability to unlock other things in the area. Because a challenge can also be a blocker, much in the same way that a city was a blocker as seen in the previous devlog. A challenge might block other challenges in their area (which in turn might block others) or just the wild areas where its possible to go and place traps for monsters.

The thing is, almost nothing of the above paragraph has actually been implemented, because this version was such a headache that by the time I decided that's the approach I wanted to go with, I was tired of this whole feature. Instead, I decided to just implement what would be necessary to get me off to a good start for when I was ready to swing by this feature again, so the game currently looks like this:

And I'm showing this because I'm pleased with it:

I knew the map scene needed an overhaul, and would need to be easier to use, so I built the list on the left. The list elements correspond to the points on the map which are currently accessible, ie, can be interacted with because they're not in a greyed-out area.

The castle and dungeon images have remained because I like them, but underneath they now represent the same object: a challenge. I've just arbitrarily decided that a blocking challenge looks like a castle, for now, because that was the least amount of work! And then I called it a day because I want to keep forward momentum and staring at this scene was killing that. So 0.10 represents that list above and a lot of design/re-prioritisation work.

I'm not entirely sure what I'll be working on next, but it'll definitely be something to do with the monsters. Maybe getting family trees in, or improving the lab view, or that overhaul of the genetics system so that can start to get more interesting. Because the monsters are the most important thing, and I can't forget that!

'Til next time! Here's to a more successful dev cycle. Have a good one, folks.

[whistlerat]

Seems I jinxed myself with my optimism last post - but no matter, my momentum is improving!

It's been a long time since the last post because I decided to work on a bit of tech for the game that I thought would make my life easier. Essentially, it was a script to 'flatten' the monsters into a single sprite, so that I could use that rather than manhandle the whole monster objects whenever I wanted them to appear somewhere. This was a really fun and surprisingly complex dive into Unity's Texture2D objects. with pixel manipulation becoming way more interesting once you try to juggle multiple textures which are not at all aligned with each other. Halfway through I pre-emptively wrote up a devlog about it, with helpful pics and everything, which I still may post here or somewhere - but, frustratingly, it was not to be.

It works; I can create a single flat texture from my multi-object monster hierarchies, but it's too slow to use in-game. GetPixels(), SetPixels() and especially Apply() (all Texture2D methods) are just too expensive to use at the kind of frequency I would need it. And because monsters are unpredictable and created entirely on the fly, pre-producing a bunch doesn't work. I've tried some optimisation but got pretty disheartened with it, after spending a LOT of time on it, and I may in the future try to find ways to sneak it back in... for now, my TextureFlattener will go on the shelf, mostly-finished.

If I get time I might tidy it up and release it - it works pretty nicely so long as time isn't an issue, so it's perfect for in-editor stuff or rare one-off flattening needs, or if the textures involved are few and/or small.

But 'I made a thing but it didn't work out' isn't what I want to leave here, so I did some other stuff too, which I'm calling 0.11 - Lab Improvements.

Changelog:

• Lab is now split into tabbed sections, currently: Monsters, Breeding, Hatchery, Tech (placeholder)
• The Monsters tab shows all owned monsters, and selecting any monster shows a larger details panel and view of the monster itself
• The Breeding tab has the male/female draggable functionality as before, but now helpfully shows all available monsters in gendered boxes
• Family trees! Can view the ancestry of any selected monster, which goes back as far as great-grandparents. Only monsters bred by the player have recorded parents - wild ones have no known ancestry.

There are a LOT of improvements to make to the Lab scene and family tree functionality still, but I completed my Trello board on the subject so rather than get obsessed on this one thing I'm calling it done and moving on to another section Will inevitably end up coming back for another iteration and this way I'll have a little bit of distance from it, so I can quietly observe how much I like interacting with it while working on other things.

In other news, I recently quit my job and have given myself a significant amount of time before I start my next one, which has officially been designated as a dedicated gamedev period. It'll be great to be able to spend some serious time on this without a day job to compete for my brainpower!

'Til next time!

[Untitpoi]

your game is quite interesting!  I would like to know how if you manage or try to make some kind of crossing over during breeding phase? I would love to make a game with more or less the same mechanincs than yours but as I my new to Unity, I will try to do easier game to train myself. If you need a tester or someone to discuss the genetic part of your game, I would be glad to help  .
Good luck with your project!

[whistlerat]

Hey thanks! Yes, I do have some genetic crossover right now when the two monsters reproduce. Each monster has 2 chromosomes, and one is chosen from each to go to the child (so that the child also has 2) and at that point the chromosomes undergo some random and minor crossover of segments.

One of the major things on my todo list is to overhaul my genetics engine though - I want to move away from the evaluate-to-number system I have now (described in the first post) and towards a more realistic allele-based one. This will allow me to have far more interesting and predictable variety in the monsters phenotypes.

I'm always super happy to get feedback on all aspects, definitely including the genetics part - that's supposed to be the meat of it after all. I'm hoping to get a rough playable build of it sometime in the next month or two, once all key features are in in some form, and will welcome testing!

As for making your own genetics game, please do, there aren't enough good ones! There are a whole bunch of awesome tutorials out there for Unity But you don't necessarily need something as 'heavy' as Unity for a game just like this, especially mine since it's just a pure 2D UI game, but I want to improve my Unity skills in general which is why I'm using it. I started with no game and just playing with how to build creatures with genes, and you can see from the first post that it wasn't particularly pretty or complex!

General devlog update: I'm making great progress on the next version, which deals with Challenges, and fingers crossed will have a meatier update in the next few days.

[whistlerat]

0.12 - Challenges. The groundwork for challenges has been laid out!

This totally replaces all of the 'attacking city' functionality described in 0.2/0.3, because I didn't like the fact that that forced an 'aggressive' narrative, where you have to use your monsters for destruction and killing. It's certainly an option, but now the whole thing has morphed into a more general idea of 'using your monsters to overcome challenges' - and now these can be anything like 'destroy the city', 'defeat the evil necromancer', 'explore the dungeon', 'save the sinking ship', 'stop the volcano erupting', 'win the talent show' or 'complete the monster equivalent of Ninja Warrior'.

The current goal is to have the game full of areas with these types of challenges, and you can decide what sort of monster keeper you want to be by which areas you go to and which challenges you take, or you can not care at all and do all of them indiscriminately. It shouldn't make a lot of difference, in the end, and the whole tonal thing isn't a big focus - it just gives me leeway to come up with lots and lots of types of varied challenges to pit your monsters against.

So what are challenges? Currently, they look kinda like this:

This tells you how many turns the challenge requires (one), the reward for completing it (100 monies), the 'blockers' (the circle and cloud) and the 'complications' (the trap), as well as the fact that this is a 'dangerous' challenge, which means that monsters could die while attempting it. May or may not keep that fatal aspect as feels right.

Blockers are aspects of a challenge which require a monster to be able to counter it. For example, the challenge above means that it involves 'floating' in some way, so it could be an obstacle course in the clouds. So only a monster which flies can attempt it - everybody else can't even try.

Complications are just things which will make it harder, or change the default rules in some way. The 'trap' complication, then, may increase the likelihood of failure (and harm) unless a monster is nimble, or observant, or some other trait which can counter it.

In this build, the complications aren't considered at all, so they're still quite undeveloped. But I have dealt with the blockers, so that choosing monsters for a challenge only lets you pick from monsters which are qualified for that particular  challenge.

All of these monsters can fly, as shown by the icon with two wings. They also have a bunch of other possible traits - swimming, diving, leaping, armoured, strong - some of which are counters to blockers, and some of which are counters to complications (not that that is at all implemented) and some could be both.

(old-ish gif which doesn't show everything described below)

It's possible to select up to three monsters for a challenge, start the challenge, and then go through the turns until it either succeeds or fails.  Only if it succeeds does the money get awarded. Monsters can die or drop out/fail the challenge as it is in progress, adding to the difficulty, but these are all things which will be given more complexity and depth with more trait design and integration.

This part of the challenges is 'complete' in so much as it works end-to-end, but requires a lot more content and complexity to make it more fun. The other core part is to re-integrate it with the zone maps, so that successfully completing a challenge unlocks the other things in its area/neighbouring areas like in 0.9. Finishing this, and then re-implementing/tweaking the monster-capturing will mean that the game actually has a playable and non-trivial game loop of catching monsters, paying for their upkeep, breeding them and completing challenges! That's pretty cool!

And I leave you with the new monster details page, featuring Dorca, who I chose because the four-legged ones are my favourite.

'Til next time!

[whistlerat]

One of my favourite things is refactoring. The more code I'm throwing out, the happier I am. Is that strange?

This is a relatively old change because I've just not happened to update this log yet, but 0.13 - Genetics Overhaul was successfully completed (well, 90% completed, just needs some polish and edge-case fixing probably) a while ago. My engine was ripped apart and put back together more sleek, powerful and interesting.

The changes explained below can all be summarised as: we have alleles, baby.

What does this mean? If you look back at my first post, I explain how my creatures' genetics work by generating a sequence of 0s and 1s, and then drawing an averaged value from a particular section in order to determine some feature of it. For example, size. The creatures had two sequences, AKA chromosomes, which were split and mutated and combined reasonably sensibly with another creature in order to produce offspring. While this worked as a proof-of-concept, I quickly realised that its potential for complexity - the good kind of complexity - was very limited. Every creature feature (any quality you can think of - size, colour, number of offspring, fertility, diet, number of legs, type of legs...) boiled down to being determined by a single number between 0 and 1. But how are you supposed to use this, as a player/breeder, to any satisfying end? Breed two monsters at the outer bounds of the trait you want (say mother has a 0.2 and father has a 0.5, and you want the trait which is required by 0.35) and hope for the best? You could keep inbreeding/selectively breeding to narrow the possibilities, but... this didn't feel right. And it also meant that it would be impossible to 'gate off' content in the form of particular traits, unless I just kept more elusive traits at the extreme ends of the possible values and then only introduced creatures with those extreme values later on, but that hardly seems elegant.

So it all went out the window, a code massacre happened, the leftovers were coaxed into a shiny new form and now we have beautiful, beautiful alleles.

Now, instead of consisting of 0s and 1s, a chromosome is merely a sequence of Gene objects. A species is defined by a particular order of genes. A gene can have multiple forms, ie alleles. On any single chromosome, a single gene can express itself only as one of its possible alleles.

So, for example, take a 'Body' gene. Let's give it two possible alleles, 'b' and 'B'. A chromosome containing a 'Body' gene in its third location could look like either 'xxbxxx...' or 'xxBxxx...' where 'x' is just some other unimportant allele.

Having just two alleles like this lends itself to some simple genetic rules. Let's decide that B is generally dominant, and b is generally recessive, but that when they are both present another variation is expressed. IE, we have 4 possible combinations with a creature which has two chromosomes in a pair: BB, Bb, bB, and bb. In terms of 'dominance' or 'preference', BB > bB = bB > bb.

What I have here is the description of a single phenotype group - the 'Body group', which decides which body shape the monster has. This is made up of a bunch of different variants of phenotype, but only one of these variants can be chosen per monster. Here I have three possible variants/phenotypes: Round, Hench, and Furry. I then have defined how these variants can be chosen, by associating that variant with genes, and more specifically, which alleles of those genes.

For simplicity, each variant conveniently requires the Body gene, and nothing else. Each variant then has different requirements for which alleles it needs the Body gene to be expressing in order to itself be expressed.

My current implementation shows dominance by ordering; the higher the variant, the more dominant, since the possible variants are checked in order. This means that a creature with BB will satisfy the top variant (Round) first and then skip everything else, whereas a creature with bB/Bb will not satisfy the top variant but WILL satisfy the second (Hench). bb will only satisfy the last, Round.

Thus, any offspring of a Round-bodied monster can never have a Furry body, since it will always have at least one B allele by Mendel's law of inheritance. But the offspring of two Hench-bodied monsters COULD have a Furry body if that offspring happens to get both b alleles.

And that's just a straightforward phenotype group. Here is the slightly more complex Leg phenotype group, using exactly the same fundamental rules:

I won't explain this one except to say that there are now two more genes, 'Legs' with alleles L and l, and 'Biped' with alleles Bi and bi. But I will show some monsters using just these two phenotype groups as examples! So by necessity the poor creatures are reduced to their most basic forms... bodies with legs. Still pretty monstrous I suppose.

Here is a random female with her image and genetics (showing Unity's default inspector, but you can see which alleles she has per chromosome):

And a random male:

What do we get if we breed them together...?

Neat. I leave it as an exercise to the reader to understand where those body parts come from And they maybe weren't even the best examples since the parents weren't all that different, so if anyone is interested I could add some more mother/father/offspring screenshots!

Needless to say, making a genetically interesting species for players to experimentally breed to try and piece together the relationships between genes should be fairly straightforward (if time-consuming) and a lot of fun.

Because this update is so late, I'm actually already over halfway through 0.14, which is just a general sweep over existing functionality to improve and expand - in this case, the lab page, and in particular the hatchery/incubator. I'm trying to intersperse adding new features with polishing old ones so that everything comes together steadily and nothing gets left too far behind. There isn't a lot left to finish up, so assuming I don't take forever to do a write-up, it should land within the next few days!

[Zireael]

I think the genetics overhaul is a step in a very good direction!

[whistlerat]

I think the genetics overhaul is a step in a very good direction!

Thank you, me too! I can already see that making a species as diverse and detailed as I want, while offering the player interesting genetics to experiment with and investigate, is going to be a LOT of work - but I'm looking forward to it. I mean, even if you ignore all the body variations I want to include, there are the challenge-related traits to add in, and then from there whatever I think is sensible for the scope - size, colour, patterns, fertility, personality, diet, habitat preferences, diseases/syndromes...

[jctwood]

I love the silhouetted style you have used and the breeding system seems really flexible.

[whistlerat]

Three weeks counts as 'next few days', right...? I did start my full-time job in that time, so I hope it's forgivable!

Either way, there really wasn't a lot to finish up and I've finally crossed off the last thing on 0.14's to-do list, so it's devlog time This version was 'just' a sweep over the lab side of things, so the views and functionality corresponding to the monster storage, breeding and incubating sections. Perhaps not as exciting as a brand new feature but I personally love this update because it was an excuse to inject some more juice into the game! #everythingbetterwithwiggles

But let's do this systematically and save the best to last. First of all, I decided to do away with the grid-monster-storage view that I had before and plug in the monster list that I'd previously made for the challenge side of things, which was satisfyingly straightforward with a few tweaks. I then wasn't sure what the point of having a 'monster storage view' and a separate 'gendered monster storage and breeding view', so have decided to combine them together for now:

All the actual functionality is pretty much the same, you drag and drop to select and then click 'breed' if the monsters are able:

As a happy side-effect of using my existing monster list object, I could get filtering working nice and easily:

Wait, what is that little pacifier icon, you ask...? I bet you can guess! But let's hop over to the new hatchery/incubator tab and have a look at a WIP shot:

Early iterations of this page had a grid of eggs on one side and hatchlings on the other, but I didn't really like that. Hatchlings now live on the main page and this is for eggs only. I may in the future reintroduce a kind of 'nurturing the newborn' feature and put freshly hatched monsters onto their own page again, but this is fine for now! This update was focused on eggs.

The main change is now that eggs no longer mature automatically, because they need to be explicitly incubated first. By default the eggs are put into 'hibernation' which keeps them kinda on ice until you want to mature that particular egg. This is shown in the pic above by the box on the left; eggs inside the incubator are actually maturing. You can drag and drop between them. OH ALSO THE BEST BIT IS THAT INCUBATED EGGS WIGGLE.

With the above view working but ugly, my goal was to make it look better and overall tweak and refine the whole system, like making eggs wiggle more the closer they are to hatching. I'm very happy with the result!

And as a bonus, baby monsters in the list after hatching!

'Til next time, whenever that is

[Zireael]

I love the little UI touches such as "must not be tired or pregnant" under the choose prompt (so many games miss this note and the player has to guess why this and that particular critter won't breed)

Also the wiggly eggs 

[whistlerat]

I love the little UI touches such as "must not be tired or pregnant" under the choose prompt (so many games miss this note and the player has to guess why this and that particular critter won't breed)

Also the wiggly eggs 

A pet peeve of mine is when a game doesn't tell you everything you need to effectively play it. So many games where so many details are only accessible through luck, coincidence or straight-up googling... I always wish that the game could find a sensible and in-context way to tell me what I want to know without needing to 'cheat' to find out. So making sure that MH is upfront and transparent and easy to use is very important to me Even at these fairly early stages I try to think about how I'm presenting everything, the flow, the instructions, and how accessible they will be to someone who doesn't have intimate knowledge of how everything works... which is currently a town populated by just me!

I'm umming and awwing over what to tackle next, I've been thinking a lot on the particular focus and direction of this game and am fairly confident that I've got one to finally settle on. But that could probably be a devlog in its own right - discussing the game design on a higher level than most of the ones so far - so I might save it 'til I know what I'm going to work on in the short term. If I decide to do another pass on the genetics engine, that won't result in much to show here, so a post about the future would fill that gap. I'm trying to commit to no fewer than one update per month

And I know, the wiggling just rocks, right?!

[whistlerat]

This would have gone up on Saturday, but I was taking part in that weekend's Ludum Dare... not my first gamejam, but it's been a long time, and while I'm a LOT more experienced than last time, boy was that 72-hour deadline a shock to the system.

Crazy how much two people can get done in that time, though. Even if we didn't finish.

So I am done with 0.15 - which ended up being another pass on the genetics stuff - at a pretty good pace, mostly because I love building systems, and because I'm feeling really positive that I know where this is all going to end up! Can't yet tell how long it'll take, I'd love for it to be finished before the year is over but with a full-time job competing for my time, it's difficult to make any guarantees. I wouldn't mind it taking a long time, except for the fact that I have so many more projects which I am keen to work on... but refuse to start a second until I have finished my first. Shipping is a skill too!

If I was making this game in a personal bubble, I would have probably left the monsters in their 'body + leg' state for a while because... it functioned, and there are other unrelated things to work on. But I want the things I post here to be more appealing, and besides, I hadn't made any new monster parts in a while, so... presto!

And everything is being 100% dictated by genetics, of course

The meat of what I worked on, though, was validation for the gene maps. This basically means making sure that all the genes and alleles and phenotypes you created, y'know, make sense. Because the more you add, the more complicated it starts to get, and the harder it is to hold all that information in your head at once, let alone make design decisions with it. 'So I have three genes associated with the HeadShape phenotype group, each of which has three possible alleles, and I want this head shape to be more common than those, but if it has this particular pair of alleles I only want this head to be possible, and...'

I introduced some useful things:
- Checking if any genes haven't been used so far
- Checking if any alleles haven't been used to far
- Whether or not any particular phenotype variant is impossible to reach (which can happen if it is low down on the list and every possible chromosome is satisfied by one of the variants above it)
- Whether or not any particular chromosome combination won't get a match in a phenotype group (which can happen if your variant definitions are too restrictive)
- The ability to see the % chance of getting any particular variant in a phenotype group, given that all relevant alleles are random (this is super useful!)

I think the croc head is my new favourite.

0.16 will definitely be a new feature, and the accompanying devlog will doubtless go much more into detail about my new clear vision for the game... but I will just say that it is moving towards #monsterlove <3 Say no to monster games about forced entrapment and enslaving!

'Til next time!

[foofter]

Someone besides me is talking about #monsterlove?! WOOHOO! Let's get that hashtag trending!
And exciting for your game, too.

[Untitpoi]

I love how you manage to use genetics in your game! The idea of variants seems to work quite well and should be a lot of fun to figure out. I wonder if your intention is to link your traits like climbing/swimming/flying to some specific variant. Like a Croc head can go under water, but you need dragon or fly wings to fly and success some specific challenges.

By the way, I agree with the #monsterlove idea!! Free the monster!!
Good luck for what's next, what you have done so far is already great!

[whistlerat]

I love how you manage to use genetics in your game! The idea of variants seems to work quite well and should be a lot of fun to figure out. I wonder if your intention is to link your traits like climbing/swimming/flying to some specific variant. Like a Croc head can go under water, but you need dragon or fly wings to fly and success some specific challenges.

By the way, I agree with the #monsterlove idea!! Free the monster!!
Good luck for what's next, what you have done so far is already great!

Hey, thanks! I definitely plan to link the visuals to their abilities to some degree - like having a wings being a requirement for flying - but I don't want to gate-off any interesting combos just because some visual is linked to a useful trait. Like in Spore, one of the things which really frustrated me was being 'forced' to use certain body parts just because they were 'better'. I want people to be able to direct the 'underlying genetics' (stats and invisible stuff) somewhat separately from the 'visual genetics' as much as possible, to allow for as much individual expression as possible!


I just finished up 0.16 - Camps, and hooooo, it's a doozy. This is gonna be long.

This version represents something awesome - a finalised direction for the game! Not least because it involves yet ANOTHER rework of the map system... but I'm hoping that this will be the last time, because the roadmap for MH is clear to me now

Let's start go with the order I worked on things chronologically, then, and so save the best for last

Embracing #monsterlove means that I wanted to pull back on the more aggressive/violent aspects of the game. Why did I ever have things like attacking cities and stuff in the first place? Because... it was a monster game? And I knew I wanted to 'do something' with the monsters rather than just have some kind of sandbox pet sim, and monsters fight stuff, right? Says who? So while the game won't be 100% sunshine and rainbows, because raising animals isn't either, you're no longer going to use them for some nefarious ends. Instead, you're playing the part of a researcher who is... wait for it... learning how to look after and domesticate this weird species - husbandry!

With this, I had to get rid of the castles on the map, because you're not just assaulting random nations anymore. They've turned into much more generic (but hopefully recognisable) !'s, representing 'challenges' which can, narratively, mean anything. The effect they have on the map - blocking non-challenges and map zones - is still all the same for now, but I'll probably tweak that as I make some challenges blockers and others not. Something I did do, though, was make it more obvious what stage a challenge is in:

A challenge in progress:

A successfully completed challenge:

Some challenges will be repeatable, either immediately or after a period of time, and some may be permanent. Right now they're all permanent but adding this won't be too hard when necessary.

But wait, you say, I recognise those flags. If the challenges are now exclamation marks, what are they? They are the meat of this version, which was to add camps. Previously, I had conceptualised the monster-collecting aspect of the game as areas in the game where monsters gathered - wilderness zones, or similar - which you unlocked via map interaction and then could visit in order to place traps. You'd then catch monsters and... forcibly enslave them, I guess. After playing Pokémon Sun, I was enchanted by the whole idea of Poké Pelago, and in particular the 'this wild Pokémon wants to join you because your island is so awesome' aspect. If you don't capture a wild monster by force, and I still want them to be animalistic (so they don't have language/higher intelligence that you can reason with, per se) then how can a player still 'collect' monsters? By the monster's choice!

This will bring a different perspective on the 'ownership' angle; you now attract and keep your monsters by building appealing camps, feeding them well, keeping them in habitats which suit them, entertaining them and generally keeping them happy. If you fail to do so, they may just abandon you.

If you want to prevent them from being able to escape so easily, you might build walls and more strict enclosures, but this has two drawbacks: it might make them unhappier, and thus more unruly, and it'll prevent any new monsters from trying to join that particular camp. But hey, you do you.

This 'keeping your monsters happy' feature will run in parallel with the overall game's goal of raising your monsters' domestication. For those unclear on the distinction between taming an animal and domesticating it, you tame an individual and domesticate a species. Taming happens in one lifetime, whereas domestication happens over generations. This will manifest in the game, as each monster will track its own tameness (something you can influence by keeping it happy or not) and its domestication (something in its blood). Domestication involves more than just being tame (and is something I'll go into more depth about in the future because I've got enough to cover this log anyway) but, in the game, a monster's domestication on being conceived will depend on its ancestors' tameness, as well as other factors.

So a camp is something that you'll build in a location where you will be able to home and look after your owned monsters, as well as attract new ones. In effect, they've replaced the 'wilderness' zones, as well as the whole concept of trapping wild monsters. Note that I haven't actually implemented the 'this monster wants to join you' aspect yet, but that's in the pipeline!

What is implemented: camps existing on the map, camps being buildable from the map (for a token cost of generic currency for now), camps being nameable, and camps being viewable from the lab screen.

They have a tab of their own!

Aw. Let's fix that! But before we do, let's look at the other way in which I was inspired by Poké Pelago - and also take a journey through the development of this particular feature.

For those who have played Pokémon Sun/Moon, you know that the pelago is somewhere you go to see your critters in storage, bouncing around on the map all happy and not stuck inside some PC. They don't move in a very interesting way, though - they either stand still or move along short, predefined, repetitive paths. I wanted my monsters to have a little more freedom.

Also - this was the first time I realised that I really need to find better gif-recording software. Oh well.

Awesome, it's neat seeing the monsters on screen and moving like this, even if it is flatly in one direction, without even turning to face the way they're moving. They can also choose between moving somewhere or just taking a breather and sitting still for a moment. It's a start. Let's fix the facing-thing first, that's the most obvious problem.

They sure take their time getting anywhere, huh... So not only speeding them up a bit, let's give 'em a bit of bounce.

Bouncing looks great - but we can make it look better.

And they should have shadow, too!

Believe it or not, the shadow was the hardest part to get working, but only because of how these monsters exist in terms of gameobjects in the scene. And it's not perfect yet even now, buuut I'll work on that when I need to.

Near the end I also sorted out the layering issue where monsters would appear to be behind another in terms of the y-axis (higher being 'further back') so that they actually obeyed this. It's not super obvious because they're all black silhouettes, but you can see in some of the gifs above that sometimes grey limbs would go in front of a monster when it seems like they shouldn't!

This whole thing has SO MUCH room for adding personality to the monsters, it's bonkers. It's already nice to sit and watch them bounce around even though it's just completely random and arbitrary movements. How much better will it feel when you have monsters moving to food, to nice places to sleep, towards other monsters they're friends with, hatchlings following their mothers, lazy monsters staying still lots and being lazy, flying monsters alternating between walking and flying, friendly monsters gravitating towards your cursor... and I'm still on the fence about actually animating them body-part by body-part. While that'll look neat, I know it'll be a BIG piece of work, and I'll have to see if I can squeeze enough personality from this whole-body squashing and moving first. Still aiming to actually finish and release this thing, not spend forever adding more and polishing.

All put together, and with some forest assets that I spent more than 5 minutes on (there's a reason I cropped the above gifs so aggressively), we have this scene, which I'm very happy with. It represents the first version of a view you'd probably spend a lot of time looking at.

All together with the map side of things:

And that's it for now, I'll go into the plans for the game more with each successive log, this one is long enough already But just for fun, here's some extra images and gifs I captured during development.

Implementing bouncing and introducing an antisocial bug... they deliberately moved to these positions and then just sat there indefinitely.

Forgetting to scale properly, whoops. Could you imagine if I let monsters be even half this big on screen...?

Testing its limits! This is how many I had to add before the framerate started dropping. (Don't look too close or you'll spot that lingering issue with the shadows that I mentioned... shhh...)

Aaaand that's all for this time. I'm juggling two games at once right now (despite myself) but I'm still going to aim for at least one update a month, so hopefully I'll have another one sometime in September  with more neat stuff to show. 'Til then!

[Josh Bossie]

I am really, really digging your style. I wish more procedural generated games incorporated such a simple graphics like your silhouettes because it's soooo much better at masking patterns and reading more real

Definitely following this one

[whistlerat]

I am really, really digging your style. I wish more procedural generated games incorporated such a simple graphics like your silhouettes because it's soooo much better at masking patterns and reading more real

Definitely following this one

Thank you! I've grown really fond of the silhouettes myself, really engages the imagination in a way that it would be harder to achieve with higher-detailed sprites I'm planning on doing a big sweep of the quality and shape of all the assets (because while some combos work super well, others can be borderline unreadable) in a late stage polish phase, as well as revisit the colour-vs-monochrome situation, but I'm happy with it for now.

I'm planning out the next version, which will be wild monsters joining you (then there'll be a solid and repeatable gameplay loop, whoop whoop for vertical slice!!) but now that the game's vision has solidified, I have been mulling on the idea of a name change while the game is still pretty unknown. I kinda liked the Guide to Monster Husbandry thing which I had a variant of early on, but have been toying with something along the lines of Domesticating Monstrus Monstrus, or maybe just Monstrus Monstrus (which would be the 'scientific' name for these creatures).

Any opinions?

[foofter]

I'm not sure what the swirly one is. It looks like a timer or a weight, but I guess I would guess that it's a portal of some kind?
The whole shape vaguely reminds me of a vertically compressed Germany? I'm not good at geography, though.