next »

[ActualDog]

That's really interesting about the unity garbage collection. Lame that you had to deal with it, but really good to know about going forward. Sounds super frustrating, but at least you got it functional.

These sorts of crowd behaviors are neat though. Stuff like this probably goes a long way towards making the game feel nice. Are you planning on adjusting viewing desire depending on game state? It seems like there's a ton you could do with this; tying the system into things like escaped monsters or monsters that are eating or really causing a ruckus.

[Cranktrain]

These sorts of crowd behaviors are neat though. Stuff like this probably goes a long way towards making the game feel nice. Are you planning on adjusting viewing desire depending on game state? It seems like there's a ton you could do with this; tying the system into things like escaped monsters or monsters that are eating or really causing a ruckus.

Yup! All sorts of plans for the system, just got to get the basics implemented. Which I believe I've broken the back of this particular piece of work:



(Gif is sped up a fair bit.)

So the red debug spheres show where the 'open viewing positions' are, places a visitor might be able to stand and observe a monster. The only way to tell if a visitor can get to one of these positions from where they are is to try and path towards it, and when they manage to, they 'claim' that spot as their own, and the debug sphere turns green to represent that. Of course, the possible positions inside the enclosure are unreachable, so are not claimed.

My goal for the visitors this week has been 1 - make the movement less random and 2 - make the movement less mechanical. The first one is getting there, the visitors now appear to have some purpose, rather than gliding around the map ceaselessly, they now want to see some monsters. Who doesn't. There's still some more work to do there, but I'm going to focus a bit more on the second point, which is they move in very strict, straight-lines all the time, smashing into one another. It's not terrible, but it's all a bit too determined for casual zoo guests, I've got some ideas to improve that, which is the next step.

Here's lots of visitors crowding round to see multiple monsters:

[Cranktrain]

Now, zoo visitors will wander to an enclosure and watch the monster for a while. Then, it'll wander to another. When there are a bunch of monsters, it feels like there's quite a lot going on:



Still more to do!

[Cranktrain]

Accidentally turned off some of the physics restraints on the monsters.



Turned them back on immediately. Can't have cosmic abominations popping sick wheelies.

[Juskelis]

I wish I could break dance that well

[Cranktrain]

I wish I could break dance that well

Just accidentally turn off certain physics constraints on your rigidbody, and it should just happen.

Monday morning, so to sanity-check the work from last week it's time for another large-zoo stress test! Been a few weeks since I've done this, essentially I use my debug controls to create a larger-than-will-actually-happen-in-game zoo, like so:



That's 120 visitors, 20 monsters and 2579 fence objects, and the simulation is running nice and smooth. A view like that, where a lot of the zoo is in shot, causes the game to run at about 40fps on my machine, and the biggest cost is just drawing those transparent sprites, which I find a bit surprising. When the player's at the very top of the map, and nothing much is on screen, it's a smooth 60fps. I'm not going to get concerned about this until proper art gets in the game, but I've made a note of it.

I've spotted about 5ms worth of optimisations I can get back every frame, which is a nice bonus. Something for later, though.

[Cranktrain]

Starting work on implementing a generic flocking solution. On writing some code, and running it for the first time:



Yes. That is exactly what I want.

[Cranktrain]

Sorted out my flocking implementation! Currently rather happy with how it functions:



Choosing the right strengths and distances for separation, cohesion and alignment is quite tricky, because every value effects everything else. It's a very simple algorithm, but like all good simple algorithms, the behaviour that emerges appears quite complex.

The simplest behaviour to get is what you'll see in all the demos around the internet, where there's one big crowd that swarms around. The problem with this, for me, is that I want lots of groups, less sticky and more brittle, because I want the visitor groups to 'splinter' nicely when encountering a fence, or a wall. And I want visitors to be spread out a bit more uniformly throughout the zoo, not grouped all in one place. This will do for now.

Currently a visitor has three states, flocking/wandering, pathing to a monster and watching a monster. Now, I've just got to tweak the state transitions such that is all looks natural, and each state blends together well enough to look natural.

[nam1995]

Nice work! :D I can't wait to see the final form of your game.
The idea sounds very unique, but also reminds me of the classic Sims game (the 80s-90s ones).

[Cranktrain]

Nice work! :D I can't wait to see the final form of your game.
The idea sounds very unique, but also reminds me of the classic Sims game (the 80s-90s ones).

Thanks! Yes, lots of influences that include the classic Sim games (Sim Ant) and also the Bullfrog sim games, Theme Park World increasingly.

I believe I'm done hooking the flocking into the visitor state system. Also! Added a gate to the zoo! Well, it's more of just a hole in the wall...



(Gif at 400x speed.) But it is a 'real' gate in the world state, if the visitors wander back out, they'll correct themselves and come back in, and if the zoo 'extends' in the direction the gate is facing in, the zoo gate will move along with the extension.

The visitors, rather than spawning randomly throughout the zoo as they have been doing, now spawn outside and path inwards. The way the visitors enter and scatter throughout the zoo, watching monsters and exploring, is really starting to make it feel like a zoo. I'm very glad I've put the extra effort into getting the visitor behaviour right.

[Cranktrain]

New monster time! You may recall this creature from page one of the devlog, now called the Ibinix.



I'm sure the ignited-nature of the head will not provide any problems, ever.

They use the new flocking code (which is why I paused Monster development to hop back to Visitor behaviour) so they tend to stick together, and grow anxious and panicky (not a good thing) when they are not a part of their flock.

And because bug gifs are fun, I also implemented proper seeding of the random procedural world generation code. It had been a while since I'd touched it, so this occurred:



All fixed now though.

[Cranktrain]

Big update here, two days of work. I've been working on implementing a fire system in the game, because some men just want to watch the world burn.

"I think I'll pen those Ibinix monsters in with tall fences! Oh! Oooh...



Looks a bit strange, because the Ibinix creature is all baked into one sprite, which is lit, and the flame sprites aren't lit, so the colours are way off.

Here's the interesting gameplay mechanic between the Ibinix and the fences which I've been thinking about since the start. A lot of people will assume that the fences are 'upgraded' in a linear fashion, at the start you only have the money for the short fences, then you move to tall fences, then metal fences, then, I don't know, electric ones, whatever comes next. But I'm not terribly interested in an upgrade that is 'better' in some generic way. The tall fence obviously suits the previously mentioned Gastroquin, because they can hop over the short ones, but the tall ones come into contact with the fiery-head of the Ibinix. Different fences suit different monsters -



No fire there!

The fire system only works on fence elements right now, so the player and the visitors don't get set alight just yet. One neat things I like about this new system - one, the fire can spread, and two, the way the fences decay once they've been on fire for a while. Like so:



And so a proper inferno can occur:



Buuuuurn.

[Cranktrain]

Food now comes in boxes:

[Cranktrain]

Started work on an inter-dimensional portal that can open and close:



Also, noticed that this is a thing that can happen:



It's... not immediately obvious to me how I should go about fixing that, where a hinge is removed and the physics that get resolved effectively causes an explosion. I've got some ideas, but they all seem a bit too much like hack-y workarounds that push the Physics problem back another level.

[UmutD]

I really like that you're using 2d billboards for living stuff instead of 3d. Very cool.

[Cranktrain]

I really like that you're using 2d billboards for living stuff instead of 3d. Very cool.

Thanks, I hope it ends up looking good!

I ended up fixing the physics explosion issue by just not using hinges, and recreating the same carrying effect through raw forces. Hinges are just so unpredictable, there's no checkbox for "please, never explode".

My inter-dimensional portal is where the monster boxes will come through, and where the items like food that the player orders spawns through. The final idea will be, a tentacle emerges and drops the thing through, but I think this might be the ugliest piece of placeholder art I've ever created:



Yuck. Looks so mechanical and static. Will all be gone soon, I keep telling myself. Next week is when I start the first graphical pass, which I'm very excited about. Can't take any more of this checkerboard texture, or the blue static sprites.

[Cranktrain]

It's been a quiet week! Haven't posted here because I've been doing exploratory work on the graphical side of things. By the end of December I want to banish the checkerboard texture from my game, and get real textures and character/monster models in the game. It won't all be finished, release-ready artwork, but I want to be more than half way there for the current set of game assets.

First step is stripping out the static billboard characters that have populated this devlog so far, and have something animating. All my previous games have featured some degree of animation, and I've usually gone about this in the old-fashioned way, frame-by-frame animation. Often sketching frames on paper, scanning them in, going back and forth over the frames in Photoshop's Frame Animation mode, or using Digicel's Flipbook software (they really need to update their site) if an animation is really quite tricky.

I've invested in the professional version of Spine, and I have to say it's a bit like emerging from the stone-age for me.

Here's the workflow, first, a character gets painted in Photoshop, each bit of the body is in a different group:



Run a script, wait ten seconds, and then the data/split images are imported into Spine:



A bunch of bones are drawn, images are attached to slots which are attached to bones. Fancy things like Inverse Kinematic constraints can be specified for pairs of bones, which lowers the number of keyframes needed and speeds up posing. Images can be turned into custom meshes and shared between bones, so the three spine bones can stretch and contract the vertices, and the feet can bend in the middle.

This saves out to a json file and a Unity Atlas, which gets imported into Unity:



The Spine Unity runtime is in pretty good shape. I encountered a bug with it this afternoon, but one lovely thing is that it's all open-source, so I was able to find the bug in the runtime, fix my issue, and submit a pull-request fixing it for everyone else.

A few thoughts about this workflow:

• It is a million times faster than doing it by hand. Obviously, but it's not only far less time consuming, it also requires less effort. Drawing things frame-by-frame takes sheer willpower. An acceptable walkcycle can take a couple of days the old-fashioned way, but in Spine you can setup a character and drag one out in a couple of hours.
• Having Unity interpolate the animations itself, whatever the framerate, makes things super-smooth.
• Very much looking forward to doing more with animation blending and Mecanim within Unity.
• The fact that the Spine runtime renders characters as 'proper' meshes means the various Sprite-based Z-sorting problems I was having have gone away. Also, proper shadows! I've removed the circular drop-shadows for now, just to see how it looks.
• Sadly, the shader doesn't yet receive shadows, or lights, but apparently that's a work-in-progress feature, one I'm really looking forward to.

More animation work next week, I think.

[oldblood]

I've invested in the professional version of Spine, and I have to say it's a bit like emerging from the stone-age for me.

Pretty much how I felt. I invested in Spine Pro about 2 or 3 months into Masochisia and it blew me away, but I didn't end up using it in the game as realized I didnt have time to learn it properly and follow my schedule, so I stuck with SmoothMoves which I was already familiar with. I'm really looking forward to diving into Spine with my next game... Don't be surprised if I start hitting you up with questions haha.

Also, the progress is awesome. Love the inter-dimensional portals...

[Cranktrain]

Don't be surprised if I start hitting you up with questions haha.

Yes, do! Spine itself doesn't appear terribly complicated, the more involved aspect is making sure Unity does what it should with the imported assets.

Here was my first attempt at using an imported Spine object:

[Cranktrain]

One of the nice things about Spine is that it's very simple to setup a skeleton that supports multiple characters. One skeleton, many skins, so animations are shared. Sorted out a female prototype skin, and replaced the old zoo visitor renderer with a Spine skeleton:



I've also been experimenting with ragdolls, attempting to turn all the character sub-meshes into physics objects, and then restore the bone positions back from the ragdoll to animating again:



As you can see... some minor issues there. Going to leave the ragdoll work as I don't need it right this moment.