next »

[whistlerat]

Since the creatures are so simple themselves, the AI probably shouldn't be too complex anyway. It would feel weird to have very intelligent pseudo-microorganisms, I think. These creatures evoke a feeling of we're-running-on-basic-instinct, which I like a lot.

I'm pretty sure I've said it before (either here or on twitter) but I'm loving how organic everything looks and feels, it's so satisfying to watch.

[Vakey Rujevic]

Since the creatures are so simple themselves, the AI probably shouldn't be too complex anyway. It would feel weird to have very intelligent pseudo-microorganisms, I think. These creatures evoke a feeling of we're-running-on-basic-instinct, which I like a lot.

I'm pretty sure I've said it before (either here or on twitter) but I'm loving how organic everything looks and feels, it's so satisfying to watch.

Thanks! Giving the game an organic feel is def something I am pushing for. So means a lot hearing you say that.

I am currently a one man shop so I def don't want to over complicate the AI if I can help it, but it is important for me that everything feels real. So I do hope that what you said is the case where these organisms are simple enough that they don't need a complex AI.

[JobLeonard]

Since the creatures are so simple themselves, the AI probably shouldn't be too complex anyway. It would feel weird to have very intelligent pseudo-microorganisms, I think. These creatures evoke a feeling of we're-running-on-basic-instinct, which I like a lot.

Totally agree, but collaborating hunters is kinda tricky I think.

Although maybe you could modify the boids algorithm in such a way that it results in hunting behaviour?

https://en.wikipedia.org/wiki/Boids

[whistlerat]

Since the creatures are so simple themselves, the AI probably shouldn't be too complex anyway. It would feel weird to have very intelligent pseudo-microorganisms, I think. These creatures evoke a feeling of we're-running-on-basic-instinct, which I like a lot.

Totally agree, but collaborating hunters is kinda tricky I think.

Maybe they could work via a kind of magnetic attraction? Rather than being clever enough to 'seek out' each other, if two of these find themselves in proximity, they automatically gravitate towards each other and then connect. In order to justify them splitting apart again, maybe once they've both sated their separate hungers, whatever holds them together gets weaker so that they just drift apart. Maybe hunger controls the magnetic force? If a starving one encounters a not-hungry one, maybe the strength of the starvation is enough to pull them together even though the content one isn't creating any magnetic pull.

[Vakey Rujevic]

Maybe they could work via a kind of magnetic attraction? Rather than being clever enough to 'seek out' each other, if two of these find themselves in proximity, they automatically gravitate towards each other and then connect. In order to justify them splitting apart again, maybe once they've both sated their separate hungers, whatever holds them together gets weaker so that they just drift apart. Maybe hunger controls the magnetic force? If a starving one encounters a not-hungry one, maybe the strength of the starvation is enough to pull them together even though the content one isn't creating any magnetic pull.

Another thought is letting love be that magnetic force that drives two organism to come together. Basically, this organism would find a partner early on it's life and develop a strong enough bond to continuously connect with each other and no one else. Now since one's survival depends on the other, it would be mutually beneficial for the not-hungry partner to connect and go hunting so that their hungry partner can eat and not die. They would also have kids together and feed them until they are big enough to find a partner of their own. Then there is the concept of cheating where in this case can become quite life threatening.

[whistlerat]

Another thought is letting love be that magnetic force that drives two organism to come together. Basically, this organism would find a partner early on it's life and develop a strong enough bond to continuously connect with each other and no one else. Now since one's survival depends on the other, it would be mutually beneficial for the not-hungry partner to connect and go hunting so that their hungry partner can eat and not die. They would also have kids together and feed them until they are big enough to find a partner of their own. Then there is the concept of cheating where in this case can become quite life threatening.

That could work too, but then you're making the organisms reasonably complex behaviourally, since I wouldn't necessarily attribute love/monogamousness with basic lifeforms. Which is totally fine if it's what you want to go for

[Vakey Rujevic]

Haven’t been able to work on the game much recently due to being busy with moving back to the states, but within the little time I had I was able to implement the biting mechanics of this organism. And omg was it challenging getting the physics to do this. But worth the effort as it feels really good playing it. The gif above is a quick test of this. Next I am going to test how it behaves on moving organisms and how the health of this organism works.

[JobLeonard]

Looks really good!

[Fuzzy Branch]

Looks cool! Must have been tough to wrangle the physics system to behave for that complicated of a case. Would love to hear how you approached it.

I'm working on setting up similar kinds of physics-based creatures (made of multiple rigidbodies connected by hinges) that have to grow & scale up while moving. Couldn't find any good information from googling on best practices for that kind of setup, but from testing, it seems like the best way is to keep all rigidbodies' transforms at default scale (1,1,1) and instead change the size of the colliders, and manually update the hinges' anchors. Does that match your experience?

[Vakey Rujevic]

Thanks guys!

Looks cool! Must have been tough to wrangle the physics system to behave for that complicated of a case. Would love to hear how you approached it.

I'm working on setting up similar kinds of physics-based creatures (made of multiple rigidbodies connected by hinges) that have to grow & scale up while moving. Couldn't find any good information from googling on best practices for that kind of setup, but from testing, it seems like the best way is to keep all rigidbodies' transforms at default scale (1,1,1) and instead change the size of the colliders, and manually update the hinges' anchors. Does that match your experience?

Oh yeah, that def matches my experience. I too keep the rigidbodies’ transforms at default scale. It’s been a while, but I do remember experiencing physics issues with joints if you scale the rigidbodies.

Since you are growing/scaling your rigidbodies I would imagine that you must be experiencing issues with the positioning of your hinge joints, since the hinge joint positions (anchor and connectedAnchor) stay the same regardless of the colliders' scale. Curious if you experimented with resolving that issue? My approach has been is to auto calculate the positions of the hinge based on the scale of the collider. So every time the scale of the collider changes I reconfigure the hinge joint like so:

Code:

hingeJoint.anchor =  new Vector2(0, sourceCollider.transform.lossyScale.y);
hingeJoint.connectedAnchor = new Vector2(0, -connectedCollider.transform.lossyScale.y);

This makes it so that the joint exactly is in between the two colliders holding them together. You can of course add padding if you want space between the colliders. This only works if the size of your collider is exactly 2 by 2 (like if you had polygon collider whose x and y points range from -1 to 1).

Another thing is I tend to avoid dealing with collider sizes less then 1. I have noticed that if your collider is too small the physics engine can't handle it. But other then that, a lot if it is just playing with the physics configurations enough for everything to play nicely with each other. Btw, noticed you located in Portland (based on your website). I just moved back to north California (Mount Shasta area). If you are ever in the area hit me up and lets grab a drink 

[Vakey Rujevic]

Ran a quick performance test to the game, here are the stats:

• 51 organisms
• 561 Rigidbodies
• 60 FPS
• 30 FPS while recording ¯\_(ツ)_/¯

This is all running on a single thread. In the future I would love to look into Unity’s new Job System (their multi threading library) to see how many organisms I can pack on a screen. It would be really cool to implement school fish organisms.

[Daywalker]

Those are some freaky wiggly-things ..
I hope they won't eat you alive

[Vakey Rujevic]

Those are some freaky wiggly-things ..
I hope they won't eat you alive

Not these guys. They are pretty harmless since they just eat small food particles floating around. But I do plan on making similar small organism that will you alive.

[Fuzzy Branch]

Since you are growing/scaling your rigidbodies I would imagine that you must be experiencing issues with the positioning of your hinge joints, since the hinge joint positions (anchor and connectedAnchor) stay the same regardless of the colliders' scale. Curious if you experimented with resolving that issue? My approach has been is to auto calculate the positions of the hinge based on the scale of the collider. So every time the scale of the collider changes I reconfigure the hinge joint like so:

Code:

hingeJoint.anchor =  new Vector2(0, sourceCollider.transform.lossyScale.y);
hingeJoint.connectedAnchor = new Vector2(0, -connectedCollider.transform.lossyScale.y);

This makes it so that the joint exactly is in between the two colliders holding them together. You can of course add padding if you want space between the colliders. This only works if the size of your collider is exactly 2 by 2 (like if you had polygon collider whose x and y points range from -1 to 1).

Another thing is I tend to avoid dealing with collider sizes less then 1. I have noticed that if your collider is too small the physics engine can't handle it. But other then that, a lot if it is just playing with the physics configurations enough for everything to play nicely with each other. Btw, noticed you located in Portland (based on your website). I just moved back to north California (Mount Shasta area). If you are ever in the area hit me up and lets grab a drink 

Sorry it took me so long to reply -- yeah, that's exactly how I set up the hingeJoints - by manually setting the anchor and connectedAnchor whenever I adjust the scale. I didn't have issues with small rigidbodies except that they would sometimes slip past edgeColliders (probably because they move further than their body-length in one physics step and can thus "skip" past the wall -- it's probably fixable by setting collision-Detection from discrete to continuous but that has a performance hit).

Nice to see that you can run >50 creatures with reasonable performance!

Also, I'll let you know if I'm ever in the NorCal area -- likewise if you find yourself in Portland send me a message -- I really like the way your project is going!

[Vakey Rujevic]

Sorry it took me so long to reply -- yeah, that's exactly how I set up the hingeJoints - by manually setting the anchor and connectedAnchor whenever I adjust the scale. I didn't have issues with small rigidbodies except that they would sometimes slip past edgeColliders (probably because they move further than their body-length in one physics step and can thus "skip" past the wall -- it's probably fixable by setting collision-Detection from discrete to continuous but that has a performance hit).

Nice to see that you can run >50 creatures with reasonable performance!

Also, I'll let you know if I'm ever in the NorCal area -- likewise if you find yourself in Portland send me a message -- I really like the way your project is going!

No worries, dude. I am horrible when it comes to replying. I have noticed similar issues with rigidbodies that are too small (or move too fast) going past walls. Fixing that in a performant way is tough. It's hard enough that we have to create balanced gameplay to also have to juggle balancing performance.

And I probably will find myself in Portland soon, so I'll be reaching out!

[Vakey Rujevic]

Happy new year everyone! Haven’t given an update on the game for 6 months and it’s due time I chat about what I have been up to. You might have heard, but Unity is making a big move in implementing the Entity Component System (ECS) that will allow us to program games with Data Oriented Design (DOD) instead of the traditional (MonoBehavior) Object Oriented Programming (OOP). Why DOD? Well, aside from the HUGE performance gains, this style of programming makes your code more scalable, maintainable, and far less complex then OOP, allowing you make your game at a much faster pace and at higher quality.

These claims are hard to ignore (especially when it comes from veteran game developers), and when Unity released their beta version of ECS back in April, I jumped on it to see what the big deal is all about. After learning DOD, I spent the last 3 months rewriting my game in this new style, and I am soooo glad I did. Things that took me a month to implement with traditional OOP, took me a week to rewrite from scratch with DOD. When it comes to implementing a complex eco system for my game, I struggled with a good way to do this with OOP. But now with DOD, implementing this feels like a breeze (I can see the light!). I also now have full control over the performance of the game and it’s so much more simplified. The picture above where one organism is flowing with the current and the other is going against it depicts how I feel when I program in DOD vs OOP.

Now I will say, despite the ease of use and greater control, I haven’t seen many performance gains yet. And this is mainly because my game heavily uses Unity’s 2D physics engine which under the hood is implemented with OOP. But once Unity rewrites their physics engine with DOD, I am expecting huge performance gains that will allow me to render a LOT of organisms on the screen. And this my friends will open up the door to implementing something like a school fish of organisms. So after 6 months of learning and giving DOD a real good hard try, I am sold! Goodbye OOP, and hello DOD. The only bad thing I have to say about DOD is that it has a steep learning curve, and this is due to there not being many good resources out there to learn it since the paradigm is still in it’s infancy. So you will have to dig to figure it out, but it’s worth it.
With the new year on the horizon I am looking forward to continue experimenting with the eating mechanics and different kinds of eco systems for the game. I hope to be posting more actively in the months come. Here is for 2019!

[JobLeonard]

Now I will say, despite the ease of use and greater control, I haven’t seen many performance gains yet. And this is mainly because my game heavily uses Unity’s 2D physics engine which under the hood is implemented with OOP.

I mean, did you properly benchmark and isolate the bottlenecks in your performance?

But ease of development is a very, very important metric though. Glad DOD is working out for you there!

[Vakey Rujevic]

I mean, did you properly benchmark and isolate the bottlenecks in your performance?

But ease of development is a very, very important metric though. Glad DOD is working out for you there!

I have been using Unity's profiler to measure the performance. Been doing both micro and macro benchmarking with the DOD systems I write. There are def performance gains when I refactored from OOP to DOD. Just overall I am not noticing much. And I didn't expect to see much since my game heavily relies on Unity's 2D physics. I should mention that there is a lot of room here for optimization with DOD. Like instead of using Collider2D for detecting triggers, I can easily implement a DOD solution for that so it's more cache friendly and can be multithreaded. But I'll hold off for now and see what Unity has in store with their implementation of ECS physics. But gotta love how optimizable DOD is.

[Vakey Rujevic]

Hello everyone! It's been a whole year since I blogged about my game. So sorry for the lack of updates and communication. This past year has been a very hard year for me, with a series of unfortunate events unfolding one after the other. And because of that I have not been able to give much (if any) attention for this passion project of mine. But I am doing much better and am more ready then ever to get back into game dev!

Now this game has been in development for quite a long time, mainly because of my inexperience in game dev, because it's a side project (I have full time job), and because it's quite frankly an ambitious undertaking. I loved working in it and would love to continue working on it. But at this rate, the game won't be done for another 10 years. So I will unfortunately have to let this game go and focus on a MUCH smaller project that is more suitable for my level of experience and amount of time I can put towards it.

Thank you all so much for the interest and support that you have given towards Life of Sundura! When I am ready, I will announce my next project here for those interested in whats next for me. See you all next decade!

[JobLeonard]

I'll repeat what I said on twitter: you don't owe us anything, and I'm grateful for the updates you shared with us before; they haven't lost any of their inspirational value!