next »

[brainwipe]

Clomper is a pipe building co-op exploration game built by a solo dev in his spare time in Unity.

Latest Devlog





Latest Gameplay Video (June 2020)





Background
In Clomper you live and work inside a mechanical ladybird called a Clomper. You lay pipes to power machines that in turn drive your Clomper across a hazardous landscape. A mysterious benefactor sends quests from somewhere outside, follow the quests to grow the story or ignore them to do your own thing.



It's too dangerous to leave the ladybird, you will interact with the storm ridden world through a number of steam powered
machines such as a map, periscope, grabber, whiskers, mole torpedoes and cannons.

Current Progress
The core game mechanics are in: laying pipes, moving around the world, receiving/choosing/tracking quests. The Clomper can take damage and be repair. Players can use a funfair claw machine to pick up scrap (resource) from the world and store it.

What isn't done
The graphics have leapt up but still need another few passes, there's no juice or polish. There's no sound, story (although I've created the outline on paper) and it's missing some more stations. There are no menus either! It's long before alpha with anyone but my son.

Coming Next
Periscope for navigating up to close objects.

Thank you for your time! I'll be updating this on a regular basis now.

[brainwipe]

This week I added a new station to the Clomper: The Grabber.





The aim of the grabber is to give the players a way to interact with the outside world; namely picking things up and putting them down. I went through a whole load of designs before settling on a cartesian robot style claw-machine arm.

The players never leave the inside of the Clomper, so they must experience the outside world using a means fitting to the steampunk aesthetic. I thought of a fixed periscope - and I need that for later - but in this case I thought a camera obscura would be perfect.

Below are pictures of camera obscuras we have in the UK, no cameras or TVs, just light, mirrors and lenses:





I was impressed with how fast I got render textures working Unity; much quicker than I expected!

[brainwipe]

This week I was mostly ill - or my little family were ill. General illness made it hard to get anything done but I struggled through all of that and changed my core algorithm from a depth first search one to Dijkstra-like. I explain why and how in my devlog...





Hopefully next week will be less of a struggle and with a fair wind I'll have a new feature to demo.

[KPas]

Hi Rob, I really like your project and your log, so I feel I should raise an objection before it's too late. I didn't do any research, so perhaps I'm wrong, but I think there is a false assumption.

When steam is involved, it is all about pressure. The pressure in a small pipe system is the same everywhere regardless of the size of the pipes. And if one of the pipes isn't connected to a consumer then the steam engine cannot build up any pressure and none of the consumers will work.

The steam engine constantly builds up the pressure with a certain output and each working consumer reduces the pressure by a certain value. A valve cannot reduce pressure but only turn it on or off.

So you wouldn't need Dijkstra. If one of the pipes is open then nothing works. Otherwise all consumers reduce pressure over time while the steam engine builds it up. Perhaps you need a safty valve?

Hey, if I'm right then your code could be simplified. Anyway I'm hoping to not spoil your good mood. Keep it up!

[brainwipe]

Thank you for your brilliant feedback, KPas.

You're absolutely right that steam will build up within a pipe network because the boiler is providing pressure and not flow (like you would get in water). You're also bang-on that valves don't reduce pressure, they reduce the rate at which pressure builds on the other side of the restriction. I complete agree and you're right that I wouldn't need Dijkstra if I was purely modeling pressure. All that code goes away as the simplification would allow me to use BFS and split pressure between the consumers like I did before. Absolutely agree without reservation and thank you!

Given that, I've decided not to do it properly and treat steam more like a liquid than a vapour (which is wrong). It's upsetting to the dormant Cybernetics graduate in me but... I think it might be more fun this way. I hope I don't upset too many other people. Perhaps I could put a humourous disclaimer somewhere in the opening titles?

I've just watched my latest devlog again and realised that I didn't mention that. I should have done, it was an oversight. I was so delighted that I could draw graphs on top of images that I didn't include that in my opening. My apologies.

I hope you're reading this thinking "yay, I'm right" and "ok, that's a fair decision" and not "filthy fool, how dare he play fast and fancy free with physics!"

[KPas]

Obviously I'm caught in my preferences sometimes. You did it intentionally, and I simply didn't think of that.

I've decided not to do it properly and treat steam more like a liquid than a vapour (which is wrong). It's upsetting to the dormant Cybernetics graduate in me but... I think it might be more fun this way.

I totally agree, gameplay fun ranks first! Otherwise there would be no platformer with double jumps or space games with sound. 

[brainwipe]

The claw will be the main way in which players interact with the outside world. Initially scrap (the game's resource) will be collected using it and in the future it will be used for grabbing and placing quest items.

To make the claw useable, I needed to give the players fine control of its movement, for which I needed a valve. Valves restrict movement in a way that's not realistic; as KPac pointed out (shout out in the video). It is fun though, so it has that.

It doesn't feel like I've made a lot of progress this week - perhaps because the progress is steady and slow. I can keep up steady and slow without burning out but it does feel like I've done nothing!

[brainwipe]

This week I've been mostly failing with the Unity physics engine. It's been quite annoying to feel like I've made little progress but I still have more things to try.

The main issue is with their quite reasonable constraints of not catering for parent-child relationships in rigidbodies. I knew that was the case and I tried some ways around it with little success.

I'm going to make the claw be a kinematic rigidbody and control it through Move Position/Rotation rather than relying on forces. I think it will be simpler in the long run!

I'm going to timebox the task. If I can't solve it in a few hours then I'll do away with the pot for now and have the scrap fade out.

[brainwipe]

I rebuilt my collider/rigidbody setup so that there was only one non-kinematic physics body in the hierarchy. This simplified the setup while losing a little bit of the fidelity you get using joints.

Also added a neat thermometer that shows the amount of scrap, improved a bunch of things and now setting myself up for a big QA and multiplayer fixing session - which I know there will be a lot.





I'm now approaching a big test cycle, how do you test your game?

[brainwipe]

With the claw/camera obscura working, it was time to begin a regression test pass and then a performance pass. I do this when I feature complete every new feature. Regression testing is where I go through a big list of features ensuring each one still works as intended. It took about 2 hours and I found 10 bugs as a result. It looks like this:



With that done, I've been doing a performance pass. Using the profiler to start with, I began with a CPU pass. CPU passes are usually about reducing the effort done in Unity's *Update() methods. Garbage collection calls are slow, so I removed *Update() methods where possible and wrapped expensive operations in if statements so that the expense is only called where absolutely necessary. I'll be doing the GPU pass next, which will mostly involve baking lights, because I know they're all set to dynamic when they don't need to be.

Here's what profiling looks like for me. Note the spikes when the garbage collector runs. Nothing terrible but not good either.



I'm looking forward to getting onto the next feature (periscope!).

[brainwipe]

I definitely have performance problems. My guess right now is that the Unity dynamic batcher can't batch up the pipes because they are using too many materials. Solving that won't be easy but it will be worth it because performance is everything.

Here are my stats; this isn't good - the game should be able to run more than 30FPS on my PC with a GTX1660Ti, the scene isn't that complex!



To that end, I've raised a Unity Forum post to try and understand what the issue is.

[brainwipe]

Performance profile is good fun; I like finding places where my code is rubbish, fixing them and comparing the stats. This week I've been using the Unity tools to understand how my game is slow and working on fixing them.

The first thing I did was identify garbage collections that weren't required. I then found that I had a camera that was rendering to texture more than it should and finally I discovered that I was making the Unity batcher's life hard by having too many materials, shaders and parameters.

I've shown how to do that and how to do some fixes in my dev log. I hope that helps someone!





Next week is going to be more performance stuff; especially around pipes, which is my core mechanic.

[brainwipe]

The past few weeks have been about performance. I improved the CPU load by removing garbage collection and improved batching on the GPU by merging all my materials into one with a single shader.

I think my shader is not very performant but that's a job for another time. Here's my last two devlogs:









Next up I'm going to get stuck in with some features!

[brainwipe]

This week I finally got my periscope working. I was glad that I didn't have to refactor very much as I had already abstracted away the player states into their own classes. I did move mouse hover into the player state classes so that I could control when the key reminder image was shown more accurately but that didn't take long.

My solution (outlined in my devlog) was to do a cinema setup: the outside camera renders to a texture and another camera in turn points at that flat surface. I did try building it all on one camera but it was difficult to get the single camera to show the inside of the periscope box as well as the outside nicely at the same time. With this setup, I have lots more control.





It seems like the vast majority of this week was spent tweaking fields of view, clipping planes, texture ratios and the like. Getting the compass moving took a very short amount of time!

[brainwipe]

I was a bit too ill to do a devlog last weekend but have been chipping away at the game, even something as small as a drawing. I've even started on the next feature:

Pick Up and Drop
Pick Up and Drop is a quest where you use the claw to pick things up, they get stored inside the Clomper and then you go and drop them off. Here's the design scribble (starts top left), work clockwise.



This is an important feature because the act of picking something up and putting it inside the Clomper is a feature that is going to get used a lot. Space is at a premium inside and with more machines, spawn points, etc then it's going to get more cramped. You can do more than one quest at a time, so having multiple large quest items on the go at once is a bold choice where there's not much space.

For this I need a new model for the lift and a recess in the floor. The modeling was easy; although I needed to make a new copy of the clomper inside to use as a collider as the full-detail model was getting too complex. I was expecting to do that at some point.



I've found with adding in all the stations that it takes a lot of fiddling to get the scale, position and port holes in the right place. For this one, I've recessed the steam port right into the floor so that you can use a bend pipe straight off it.

And this morning, I got it working!

Here's a neat imgur video of it working: https://i.imgur.com/zUxo43O.mp4

Now, I might need to implement a ladder...

[brainwipe]

It's certainly been tougher to make progress now that we're in lockdown but I'm still crawling along with progress.

I even managed to cobble a dev log together, although it did take me several goes to complete.





I like my new lift; it mostly works (although pipes don't collide when they should). I've not tested it in multiplayer yet but I am expecting that to be OK, it's pretty simple after all.

There's a bunch of game-logic that now needs to be decided. The player doesn't interact directly with all the systems in the Clomper, so they need some idea of how things outside of their reach are behaving. This means more indicators for the Con, which I was expecting to do and now is the time.

Looking forward to getting the actual quest working!

[brainwipe]

I was delighted to have one of thos mne development moments this week where I used my limited understand of Unity to answer my own question. It's definitely a hump to get over.

I feel like I have a fair wind behind me now. I don't really have any more design blocks - I think I know how to implement just about everything that's left and although that feeling is probably a falsehood, it feels nice.

[brainwipe]

I jumped through lots of logic hoops this week with one of the core mechanics: picking stuff up and drop it. My original design felt like a good idea and it sort of looked fun but in reality, it offered only complexity for little return.

It had taken me 6-8 hours worth of work to get working but if a feature is no good then you just have to say goodbye to it.

Could I have trapped the problem in the design stage? Possibly. I'm not new to coding complex systems but I am to game dev and on paper it looked OK. Now that it's removed, it definitely feels like the right choice.

[brainwipe]

It's been a tough couple of weeks; as I added features to my grabber claw, I realised that the resulting code would be a huge mess. I stopped, deleted all the game logic and applied some Domain Driven Design. I went through what my aggregates were (especially one particular aggregate root) and how they communicated.

Once I had nailed that down, the process of getting the code clean without losing function was pretty easy. I explain this is more detail in my dev log below!

[OctoMini]

Interesting stuff! I appreciate the unity/programming insights as well as the game dev progress. Your voice and clarity in the videos are great, but I would like it even more without the music. To me the music is just a distraction. It might be just me though;) Anyway, great job with the videos! They are well made!