next »

[Davi Vasc]

This keeps looking better and better. Nice work!

[Cranktrain]

Thanks Davi!

It would be cool if some zoo patrons could be affected by the animals (poison, nausea) and their colors could change to reflect that.

Yeah, I'm a big fan of classic 'status' effects where the colour changes. I'd be surprised if there wasn't a poisonous monster in the game!

Now I can't wait to see some of the monsters in game! 

Me too!

looks crazy, i want to put all these people on fire.

Yep, going to revisit the fire effect in the coming weeks, and extend it to visitors and the player. buuurn.

Instead of going and working on female visitors like I said I would yesterday, on a whim I decided to revisit the ragdoll experiments that I posted some gifs of previously, mainly gifs of it glitching out. For debug/testing purposes, the player can now ragdoll on button-press, like so:



Rough, but working! The character really needs some animation for getting up, right now it just mixes to the idle animation. Also, Spine has this bug where if you're animating with IK constraints (as I am) and you have a negative scale (in my game, negative scale is where the character facing left) then the ragdoll breaks. It's a known bug, negative scale is a bit all-over-the-place with Spine, but I think I've got to wait until the next big version of Spine comes out before that's sorted, which hopefully won't be too long. For now, ragdolling forces the character to suddenly face right.

Pausing the ragdoll implementation again!

[Cranktrain]

Added female guests:



Which took far less time than I expected! Just a few hours to paint up the variations, and I'm pretty happy with how the visitors look. In the future, I want to come back and double the number of hair styles and t-shirt designs for both the male and female guests.

[Cranktrain]

Correcting a bug with the skeleton, here's what happens when only half a Spine skeleton is imported:



One annoying thing about the fence posts has been when lots of fences are destroyed, their components just hang around forever. Now, after a short period they smoothly fade away, becoming Fence Ghosts:

[Cranktrain]

New monster food boxes -



So I had two dimensional boxes for a while, then switched to 3D ones. When I added a proper holding animation, it looked pretty bad, because the 2D sprites don't really interface particularly well with an object that extends in the Z axis both in-front of and behind the player character. I think the gif shows that 2D is the way to go with all held-items.

Also, there's a new holding animation there. The character leans back a bit and holds the object a bit closer, which is a big improvement over kind-of-hovering a metre in-front.

[Cranktrain]

Started work yesterday on the new Hellion.

The first step is getting the Photoshop file setup, exporting to Spine, and Spine exporting to Unity, to make sure that the size of the monster is right, so the line-widths don't seem 'off' between all the animated characters. Exercising the graphics pipeline looks like:



Looks good enough, ship it!

Okay, no, maybe not. Back into Photoshop, drawing every limb out in different groups, and then rigging them to a skeleton in Spine. This requires a bit of back-and-forth to ensure that joints bend fairly seamlessly:



I have to say, I love Spine. I think it's the first completely new piece of software I've used in a while where I've thought "this... just works". I recommend it, the workflow for Unity is lovely. The Hellion is making lots of use of the mesh deformation feature set.

I've got two idle animations blending here, for the tongue and the tail:



Next, the six-legged (!) walk cycle, and colours.

[Mr Underhill]

Hey fellow Lovecraftian game developer, great job, looking good!

[Cranktrain]

Hey fellow Lovecraftian game developer, great job, looking good!

Thanks! I'll check your game out tomorrow, took a brief look but I need to read the whole thing.

Started working on the Hellion's six-legged walk cycle today. First thing I noticed when exporting some tests to Unity is that the monsters really need to conform to the terrain, which currently they do not do. First attempt at that:



Didn't quite have the quaternions sorted out there.

Since the monsters are quite tall, it's very easy for them to flip over on slopes. I don't mind them flipping over in some circumstances, in the even of an explosion for example, but I need them to right themselves. Here's a test of that, involving me manually rotating a Hellion in a paused environment:



Basic tests done, and now I can concentrate on the walk-cycle. I'm pretty okay with the final animation:



Next up, colour, and working out how the Hellion can eat food with a nice animation.

[Cranktrain]

New Hellion now has some colour, no detail yet:



I've also worked out a sensible way of having them eat some meat with an animation. I'm reusing the player's holding code, so that monsters can now 'hold' items with their mouth, when the item is in position, it then gets bitten:



Of course, things that cannot be picked up can still receive a bite:

[Excy]

Read up on this yesterday and it looks awesome. How are you coming up with/deciding on monsters?

[Cranktrain]

Read up on this yesterday and it looks awesome. How are you coming up with/deciding on monsters?

Thanks for reading! The monster design I think has to be gameplay-driven for this particular game. The creatures have to compliment one another, and work against one another to provide the challenge for the player. For example, the frog-like creature (the Gastroquin) needs tall fences and flat ground, and will otherwise jump over the boundary. However, the flame-headed deer-like monster (the Ibinix) needs short fences or else will set the tall ones alight. Some monsters want lots of space, others don't, some need to be surrounded by other creatures, some don't. I'm aiming on getting the player into a constant balancing act, as they have more and more monsters to care for, and yet they have to work within the zoo they have already built.

The new Hellion now comes into a new box, so you can actually tell what monster is contained in the box before you open it. Also, the player can switch directions while holding items, which they couldn't before:



You'll also notice new meat objects! Hooray meat!

If you've been following the devlog from the beginning you'll know what a big deal it is to finally get this task into the 'Done' column:



Also, today, fixed a few significant bugs with how visitors not wanting to watch the monsters. That's the whole reason they are there!

[redwolfplayer]

Yay no more checkerboards! A big milestone for any game 

Your game is looking super awesome! I love the way the Hellion and everything is coming out of the boxes. Can't wait to get deliveries of monsters!

[Cranktrain]

Thanks redwolfplayer!

Look! A new video devlog! Click this thing:

It's been a while since I've done another of these, need to do another a bit sooner! Plenty of things you've already seen in gif form, but in much higher quality and with me talking over the top.

[Cranktrain]

Decided to polish up how fences are constructed. A really ugly bit of prototyping art has been in almost every gif since page one of this devlog, which is the Red Dot projected on the floor. It was meant to mark the place where a line of fence posts would start to be built from, but clearly this needed to go.

I thought I'd go for a more obviously 'temporary' look to the fences as they are dragged out, which is to display them semi-transparently, but also in a blue coloured wash reminiscent of blueprint diagrams. It looks like this:





As with these sorts of polish work, it's a big improvement. The blue marker that replaces the Red Dot projection slides around the grid smoothly, which is far less jarring. What's more, before I was creating and destroying the fences every time the dragged line of posts was extended, which was noticeable in the profiler, so now it does it a bit smarter, only destroying/recreating the ones it needs too. Oh, and before it didn't show temporary fence crossbeams, just the posts.

You'll notice in the gifs above one mistake, that I forgot to turn off shadows for the blueprint crossbeams, which looks bizarre. I've fixed that now.

[Cranktrain]

Revisiting my favourite of the monster characters, the Gastroquin. As with the Hellion, the first stage is finding the scale with a messy sketch:



Heh.

Spent the day whiteboxing a new version of the character, using different colours to check how the different limbs bend together:



It's all rigged, so tomorrow I've got to get down to animating the character, I'm looking forward to getting him into the game.

[ｂ∀ ｋｋｕｓａ]

i hope you're keeping him for an easter egg or something :D

How did you come up with the Gastroquin name?

[stringkiller]

Hi DizzyDoo,

This game is getting more and more interesting. I have a question though, are you also using spine for the human characters?

Their walking and running animations look a bit stiff and I believe it would work wonders if you used the mesh skinning features to move the shoulders and the hip a bit while "squashing" the body a bit. I've tried that technique before and it works wonders making a character less stiff which is a common problem in skeletal animation.

You can find and example I did a long time ago here, although it's very subtle you can see squishines in the body and in the hips. If I would do that kind of animation again I would greatly exagerate those same movements.

[Cranktrain]

How did you come up with the Gastroquin name?

Not sure! I keep saying names until I come up with one I think fits. In this case, the large stomach and the tendency to explode got me starting off with the 'gastro' part.

Their walking and running animations look a bit stiff and I believe it would work wonders if you used the mesh skinning features to move the shoulders and the hip a bit while "squashing" the body a bit.

That's absolutely correct, but to my mind this comes in a later polish pass. I want to get every in-game graphical asset to the current level of quality, and then I'll come along later and refine all the animations. I know for a fact that I've got to revisit every model anyway, to normal map them, and I want to reserve the ability to change the shape of the meshes if I need to. As you know with Spine, if you change the shape of the image you've got to recreate the mesh, and so the animations that move vertices around become useless. The mesh deformation is probably a last step.

Today I've been animating the Gastroquin character, and giving it some colour. I also had to sort out how the hopping worked to make it play nice with an animation, and there was some extra work to stop the creature jumping over tall fences, which I realised they could still do.



Still needs an eating animation, and a new box.

[stringkiller]

Really looking forward to see how this looks with normal maps on! are you going to use sprite lamp?

As you know with Spine, if you change the shape of the image you've got to recreate the mesh, and so the animations that move vertices around become useless. The mesh deformation is probably a last step.

I suggest you to mess around first with the mesh skinning capabilities of Spine, before polishing the assets (If you still haven't done so). It's very unintuitive but when your skeleton is well rigged to the mesh the animations will be kept thanks to the rigging even when you change images. This way you can have multiple skins with the same deform animations or modifying previous material, although you will most likely have to add some extra control bone here and there.

[Cranktrain]

Really looking forward to see how this looks with normal maps on! are you going to use sprite lamp?

Nope, planning on using the upcoming 'Magelight' update, so really I have to wait until the Version 3 update shakes out to polish up anything.

So far this morning I've added an animation for the Gastroquin to eat some food, but there's a bug in the Spine runtime that makes it look rather messy, so I can't show that here quite yet.

The Gastroquin, while being fairly genial in nature (if also creepy) has the tendency to explode when agitated. The explosion effect is still a work in-progress, but the Gastroquin really needed an animation to let the player know of the impending combustion:



Clearly, a rather bothered creature.