next »

[Cranktrain]

Thanks all!

Had an easy Saturday, I've been dealing with 'big picture' stuff for the last three weeks, pathfinding, monster emotion systems, etc, so I just wanted to pick off a small task from my todo-list.

The walls (currently those ugly checkerboard things) that surround the zoo completely obscure the player when they're between the zookeeper and the camera, so I decided to make those go transparent.



That'll do for today.

[Cranktrain]

Monsters now treat the Zookeeper as a source of meat, if they're hungry. A moving source of meat, so they're quite happy to chase you:



Next, have the zoo visitors treated the same way.

[Cranktrain]

New video devblog! Explaining how I've laid out the emotion/AI system for the monsters:

[oldblood]

This is quickly becoming one of my new favorite devlogs. You're making great progress on a consistent basis!

[Cranktrain]

Thanks oldblood!

Talking about consistency, two updates in one day? Is that even legal? No.

Visitors can now be eaten by monsters. Bit lame without animations, but it's fine for now. There's also no response to this eating, the guests just carry on their merry way.

I built a kind-of reverse zoo:

[nathy after dark]

Following the log. I would definitely play this, and when you need playtesters, I might be willing to help with that as well.

Haven't read the entire thread yet, but personally I like the geometrical warping of the landscape with hills. I think something like that should stay in the game--it's Lovecraftian. I also love the idea of random changes in the zoo boundaries, and I think those should happen without any announcement, so the player ends up finding them after the fact and being confused.

I think a complex system of eldritch abominations' emotions would make for fantastic gameplay. Invisible factors the player could never fully account for (a la Dwarf Fortress) would really support a Lovecraftian mood as well.

Looking forward to seeing where this goes, and nice to see another Lovecraftian game here, albeit one with an entirely different direction than mine.

[Cranktrain]

Following the log. I would definitely play this, and when you need playtesters, I might be willing to help with that as well.

Thanks! Probably a few months away from play-testing, because there isn't really a 'game' here yet, but as soon as there is a win state and a lose state, I'll be grabbing people in for that.

Today I've been working on the next of the monsters. It's another meat-eating creature, the Behemoth, which you might have seen so far in this devlog looking a bit like this:



Decided to revisit it and make it look more like the concept I did back in October (back here), and make it a lot larger, and give it a dangerous, brooding intensity:



Not sure those visitors ought to be getting quite so close.

The Behemoth acts very differently to the Hellion, the existing monster you've seen lots of. Hellions can coexist quite happily, as long as they have enough space and meat, they'll be pretty calm. They're straight-forward enough creatures.

On the other hand, the Behemoth requires a small enclosure, treating extra space as a chance to lose it, and it'll go from calm to raging fury in about five seconds, if it hasn't got fenced restraints around it at all times. It hates... well, everything, but especially other monsters. I think the general rule with the Behemoth is keep it away from everything except meat, always.

[Gargoyle440]

Man this game looks amazing!

I imagine the audio for this game is going to be a lot of fun to put together.
Last time a friend of mine needed some demonic-sounding stuff we read passages from the bible, reversed them, and pitch shifted them down.  Can't wait to see what it sounds like!

[Pixel Noise]

Just found this and wanted to say how cool the idea is, and how it's really grown from page 1 to page 3 of the devlog! Looking forward to more.

[Greipur]

Thanks! Probably a few months away from play-testing, because there isn't really a 'game' here yet, but as soon as there is a win state and a lose state, I'll be grabbing people in for that.

I think it could be worthwhile to let people play your "toy" as well. I don't know if you've read this old Gamasutra article but that's the definition of toy I'm talking about:

Build the Toy First

Start with the core mechanic. Whether spring systems, swarm behavior, gravity, etc, it never took more than a few hours to get the basic theme up and running. This “toy” should be the core mechanic of the game minus any goals or decisions. There is no win or lose state, just a fun thing to play with.

Your game feels like an experience that is heavy on the emergent gameplay rather than set winning and losing states, right? So you might get some interesting feedback even when it's a toy. Perhaps even feedback about possible losing and winning conditions.

[Cranktrain]

Thanks Gargoyle440, Pixel Noise!

I think it could be worthwhile to let people play your "toy" as well. I don't know if you've read this old Gamasutra article but that's the definition of toy I'm talking about: ...

Personally, I don't think The Eldritch Zookeeper works as a 'toy'. There's no single innovative mechanic or mechanism, that by itself is fun to play with. I understand what the authors in that article are getting at, but for a game focused on complex interrelated systems, I really don't believe it works very well in this particular instance. How would you make a toy out of Sim City 2000? The Eldritch Zookeeper is much closer Sim City than World of Goo.

Added a new monster today! You might have seen this concept back on Page One of this devlog, it's my favourite monster design so far. They hop, rather than walk, so...



Yeah. We might need to build some taller fences to keep those in.

Not entirely done with them yet, there's a few more mechanics that I'm going to call 'troubling' for the player, hopefully I'll be able to show you one of them tomorrow.

[Greipur]

Well, in my opinion city building games already lean heavily towards being a toy in its finished state so I would argue that the transition between toy and game would be easy. What I took away from that article is simply that toys are interlocking mechanics with consequences minus the extrinsic motivations for a player.

I wish we had shared Crest in such an early state, we did a lot of toy prototypes we played around with but never shared, mostly because we made them with paper. But that's where I'm coming from. And Crest is also closer to SimCity than World of Goo.


Looking forward to see the game's art style develop from white boxing to finished state. I'm curious how it will look.

[Cranktrain]

Boom!



So the newest monster, dubbed a Gastroquin, has a bit of a unique danger to it. Where as the Hellion gets a bit bitey when it's angry, and can cause damage to fences, and the Behemoth has an even shorter fuse, the Gastoquin works out its anger a little differently. It self-destructs. Best keep them (and all other monsters) calm.

Obviously everything graphical is still work-in-progress, but I did take this opportunity to experiment with Unity's particle system, not something I've used before, which is the reason why the effect looks a bit more developed than the rest of the game. Taking inspiration from Nintendo's particle effects, for example, The Wind Waker HD, but also the 3D Worms games, I tried to come up with an explosion that is recognisable as an explosion. It's a few miles from perfect, but it helped me work out some classic particle system 'problems' early; like how you sort a bunch particles across different emitters.

'Good enough for now' is the current motto towards graphics.

[Yxven]

I love the idea behind this.

[Juskelis]

I know that it's totally a prototype, and I get that it's going to change. BUT

I think using Wind Waker as an inspiration for the explosions is a bad idea; simply because WW has a very whimsical and somewhat friendly vibe to it. While your game is a little loose and strange like WW is, the explosions feel too curvy and smoothed out for this, especially with the rest of the art.

Personally I'd go for something much more sharp and abrupt to show explosions, but this also isn't my game so ultimately its your call, and so far you have made an awesome title so I'm sure it'll be fine. 

[Cranktrain]

While your game is a little loose and strange like WW is, the explosions feel too curvy and smoothed out for this, especially with the rest of the art.

Absolutely! The main reason I know the explosion won't look like that, is that I don't know how the game will look yet. So who knows! An aside, but what surprised me about The Wind Waker explosion is how long the effect goes on for, the sphere of particles just hangs around for five seconds or so.

Got two sizeable chunks of work done today, firstly:



Tall fences! They actually keep the Gastroquin in, and everything. The Zookeeper can't jump over them, hence the smaller fences in the back corner. I'll have to revisit how the player enters/exits these pens, but I probably won't get to that for another two or three weeks.

Second chunk of work, which took a surprising amount of effort, was to have fences react to explosions to the appropriate way:



When the monsters collide with a fence in an angry fashion, it's comparatively easy to tell that the fence needs to break, because you've got two Rigidbodies colliding. But here, there's just a particle effect. Unity offers a OnParticleCollide hook, but I found this deeply unreliable. I could have created a temporary invisible SphereCollider, had it stick around for a frame and check any collision overlaps with fence items, but that sounds like an incredible phaf (faf? faph?). Raycasts would be another option, but they're super-slow.

Instead, I went down a route that's been working for looking up various other items, which is to store all our fence items in a Quadtree, which is super-fast. There's always a little overhead as I hook up registering/unregistering items with a new Quadtree, but it's all code that's easy to understand, and quick to execute.

That's it for this week! Super-productive last six days, as usual I'm taking a break tomorrow, see you all Monday!

[Cranktrain]

Added a new monster today, the Grondomut:



The Grondomut differs from the other creatures added so far in that it needs other monsters around it. It gets lonely, and when it gets lonely, it gets angry:



You'll also see there a green, transparent cube. This is representing a new source of food. The Behemoth and the Hellion both eat meat, but the Grondomut and now the Gastroquin survive on a diet of cosmic ooze. You can't have 'Eltritch' in the title of your game and not have slime, it wouldn't be right.

Placing these inside a zoo will require a balancing act, which monsters will get on best with the Grondomut? The Behemoth is out of the question, of course, the Hellion would be fine until it gets hungry, the Grondomut is a very meaty creature after all. The Gastroquin isn't a meat-eater, but its tendency to explode makes the knock-on effects of that potentially worse still.

I'm unhappy with the white-box sketch rendering of the Grondomut, I'm going to be doing some fairly heavy tweaking of that tomorrow. Even though these are sketches, and will all be thrown away, there is value in getting the form, the shape of these monsters close to accurate, because of course collisions depend very heavily on them.

[Cranktrain]

As I said yesterday, really didn't like the form of the new Grondomut. Reworked it this morning:



Whitebox graphics are all rather unimportant, for the most part, but I'm much happier with how the new shape sits in the game. The old one seemed unbalanced (too much neck, weird back, head was too high), especially when looking at the physics primitives which make up the collision mesh. More natural, if an unnatural creature from a nightmarish dimension can look 'natural'.

[oldblood]

Just chiming in to say awesome updates as usual. I love the way you're already creating things that will force the player to do things in their zoo they may not want to (like mixing different creatures to keep them happy and using trial/error to perfect the process).

I know it's all just test art, but I'm still not a big fan of the Grondomut. I think a lot of it is in the eye, something about the large pupil makes it stand out compared to a lot of the other creatures and seems like a very "human" eye vs. eldritch. It also seems like it should have a much sadder look to it if its always lonely. That may just be me though...

[Cranktrain]

I know it's all just test art, but I'm still not a big fan of the Grondomut. I think a lot of it is in the eye, something about the large pupil makes it stand out compared to a lot of the other creatures and seems like a very "human" eye vs. eldritch.

Maybe! I don't mind the big eye at the moment, it's the only monster with expressive eyes, but we'll see when some newer art comes along. Sadly, that's not going to be before December.

Rather frustrating period of development today, spent all day to get this:



Not particularly impressive.

Here's what I'm trying to do, I'm pausing work on the monsters and returning to the zoo guests. Right now, they just pick a random spot and walk there, with no heed to monster, nor to other guests. I think the time has come to deepen the behaviour, make it bit more crowd-like, and less mechanical.

The first step is to give the guests somewhere specific to go to. Ie, they want to see the monsters, that's why they've come to the zoo. So for every monster, I need to generate a set of positions in the world from which it can be said they can view the creature, which the guests will then use as possible destinations.

This seems like an easy thing to do! Here's some additional requirements, there can be obstacles that can obscure the view to the monsters, for example, the walls, but there'll be more obstacles in the future too. I don't want a guest to be staring at a wall. This requirement means we're probably looking at a Djikstra-like walk, like this image from wikipedia:



So that, coupled with a raycast on the grid to check things are visible.

My first pass at implementing this was a very expressive bit of code, two nested generators, yielding the positions in a very readable way that I was very happy with. It performed terribly. Turns out, recursion, along with IEnumerable's, is very CPU and memory intensive. If it were just CPU intensive, it wouldn't be a problem, because that could just be given to a thread like I'm doing with the recalculation of the navmeshes.

The memory usage in this case is arising because heavy recursion plus IEnumerable's mean there's a lot of allocation on the heap, keeping track of the stack in the different calls. And the problem with this is Unity's Garbage Collector. That mysterious harbinger of swift memory deallocation hell. This would cause the occasional (once every 10 seconds or so) massive frame-skip, as the game dips to 10fps. Very noticeable. Pushing it into a thread doesn't help, since the Unity GC only seems to operate on that memory when the code returns to the main thread. It's mysterious, plenty of articles around the internet speculate on exactly how it works, but no one really knows. All I know is that when it runs, it does it all at once, all whilst laughing directly in the face of your framerate.

Anyway, binned all my nice, clean, understandable code, and rewrote the same thing, all in one while loop. Typically recursion optimisation, flattening it all down. Seems to work. Quite messy.

Next step is actually use this new position data-structure to direct my zoo guests around.