This october @ThisIsEllian suggested that gamedevs could try a challenge similar to Intober. The main Idea was to make, promote or just work on a game everyday for a month. Ideally we would try to make a game in a month but it’s obviously more difficult than this, doing a game in a month after work would require a huge amount of work and I like my sleep time too much to even try.
On the other hand I’ve been sitting on some code I’ve worked on in my last year of university. This was the perfect opportunity to use this code and try to make a prototype/mini game with it as a showcase for my asset. While I wanted to participate in this challenge I knew I wouldn't manage the one contribution per day schedule but I quickly realised that it was not the point. The main point of this for me was to set a goal: release a prototype and my asset by the end of the month.

Itch.io: https://saarg.itch.io/autober
Github: https://github.com/Saarg/AutoTober

Car physics

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:

  • Use realistic values, your car hould weight from 800kg for old cars up to a few tons for big trucks. Going big for cargo trucks gets difficult and you'd probably need to do some work on the WheelColliders value to get this working.
  • Avoid changing the WheelColliders values too much. I'd even advice you not to change them at first.
    Once your car is moving you can change the spring according to your model and the weight you choose and then the stiffness is a value you can play with. If you want to play more with the value you'll need to read the documentation, understand it aand do some trial and error :p.
  • Put your Wheelscollider on a layer of their own and set them up in the project physics inspector so that they don't collide with each other. The WheelColliders is basicaly a raycast going down so you should also avoid big steps or rolling over cubes because it will produce a bump. (your car can start flying if you try to place objects in the wheels)
  • Make sure the parent's rotation and scale are at the default values of (0, 0, 0) and (1, 1, 1)
  • Set your rigidbody's center of mass between the center of the wheels and the ground but do not go under the ground.

Arcade Car Physics on Github
Arcade Car Physics on the Asset Store

Flocking IA

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:

  • Wander force: This is a random force capable of spliting groups and exploring on their own
  • Home force: This force is drawing the IA towards the center of the map to keep them were the player will be. The bigger the lvl the lower this force is
  • Avoidance: This isn't really a force but using two raycasts I steer the skeletons away from obstacles
  • Target force: I ended up not using this one but it's moving the Ia towards a target

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.

Physics and ragdolls

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.

Working a bit every day (almost)

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.

Contact Me


Copyright © none, I love you and you can use all my code.