I have been making cars in unity for about two years using unity's Rigidbodies and WheelColliders and I wanted to make available some of my scripts. I've seen many people say that WheelColliders are unstable and buggy but I've found them to be pretty efficient once you learn more about them. This section is all about the car physics I used in my asset Arcade Car Physics (ACP). It's not on the asset store yet but I'm working towards the validation. To be fair they are more then usable but they require some tips, Here is a list of essentials:
The second element of my game was the IA of the skeletons moving around the map. I knew I couldn't make a big IA and finish the game but I wanted
to have some life in the skeletons (ironic I know). For this I used a simple flocking algorithm with a static list of skeleton accessible to all skeletons.
This static list is the easiest and most efficient way I found to have every IA considers It's surronding friends. Please don't use methods like FindObjectsOfType
or GetComponent every frame it's bad for your framerate.
On top of the flocking algorithm I added a couple forces:
I also added a raycast from the head going down and under the feets of the skeleton by about once it's height to keep them on the ground and added a randomisation of the forces coefficients. Randomizing the flocking coefficients is a good way to give some personalitie to your IA, you end up with some IA who likes to follow and some other who like to explore. Once I got to the end of my level I had aboud one hundred of them wich was not an issue on my machine but I realised that casting 3 raycasts and looping through every skeletons 100 times per frame wasn't reasonable. The solution for this was simply to update the direction every n frames making sure they don't all update on the same frame ;). The result were surprisingly good, the game is running smoothly even on bettery saving mode and the skeletons movement appeared a lot smoother.
I was inspired by @punchesbears work and
wanted to use physics and ragdolls. I find using physics as gameplay and not just simulation
a very fun and interesting, in the same way we enjoy destroying a tower of cubes more than we enjoy
building it. The anticipation of what's about to happen creates depth in your gameplay. A good
recent demonstration of this are the countless gifs of red dead redemption's horses falling entertaining
millions of people.
However the scope of this project being small and short active ragdolls without prior experience in this fiels would have been unrealistic. Considering this I choose to use traditional animation and only trigger the ragdoll on impact. The trick for managing this many Rigidbodies was to get the list of colliders and rigidbodies at start and disabling the colliders and setting the rigidbodies as kinematic.
Once this was working I also went digging into @punchesbears old tweets to find this tweet. Those physics settings did an incredible job preventing the ragdolls from blowing up when it. Disabling the collisions between The wheels ans the ragdolls was also a key point to avoid glitches.
while technicly this project wasn't a technical challenge for me I discovered a few things.
First and most important for me was to realise that to build a reputation, share your work
regularity is key. I've had my work on github and twitter account for a few years now but
never really managed my social media visibility. I had a few conversations with strangers
playing my prototypes but never realy engaged. While I'm still too shy to comment most of
the time I surprisingly got some feedback and cheers which is scary and motivating at the same time.
While I'm only having fun for now it is clear to me that as a indie dev promoting my work would
have to start during development and with regular updates if I ever plan to have a comercial release.
Working a little bit everyday is also a good way to keep going, the project becames part of a routine. While sometimes this routine would be 3 hours and sometimes 10 minutes it made the difference between starting a project and actualy finishing it. But I had to be careful with it, I easily loose track of time and add to be strict about not working too late or the next morning would have been dificult. Never worked past 11Pm during devtober and I plan to have this a rule in my life for now.
Anyway I'm very glad I participated in this challenge and would like to say thank you to @ThisIsEllian and wish him the best. I'd love to see his devtober project go further but don't go at it too hard, everybody needs sleep.