next »

[brainwipe]

I've been making great progress on the Fire Sprites, even though the amount of time I have during the day has fallen off a cliff - mostly because summer holidays means that the kids are around more and time in the morning is squeezed.

I have joined in on the twitter 100 Days of Game Dev challenge. Mostly for fun - I doubt I'll be able to see it through given my commitments. It's been great to connect with people in the community and I think I am getting more subs through YT from it.

My latest video sums up all the work I've been up to - including a little bug where I mistook position for scale.

[JobLeonard]

Another delightful and calming devlog

I think there's something counterintuitive about closing the door first and then putting the sprites back in. The player would need a visual hint I think

[brainwipe]

JobLeonard, thank you so much! I'm glad you enjoyed it. I think I've found my style and this is what it is!

I agree that fixing the door before putting the sprites back in is weird. I can swap it round as I'm not relying on physics at this point. I do want players to put sprites back in at any time and I don't want to animate the door moving much because space is tight around the pipes. I do need more informative tooltips, I have that as a future feature rather than now because I am still unsure if the core game loop is fun enough to continue with Clomper - even after 2 years!

[JobLeonard]

You could explain it lore-wise as them preferring to be in the boiler, but escaping for their own safety when it gets too hot. So they don't dare to go back to check if it's safe, but if you put them there they happily stay in.

Another option could be that the door automatically closes once all the sprites are in, as a hint to the player whether or not they got all the stray ones

[brainwipe]

Those are lovely ideas. I prefer the lore perspective - I want to have game modes where sprites are collected - giving you more/less steam pressure to play with. So, there would never be a "right number".

I think of the sprites more like cats. When inside the boiler, they can't wait to be out. When they're outside, they can't wait to get back in!

[brainwipe]

With the kids each going to new schools, it's been a tough few weeks but I have been soldiering on with the Twitter #100DaysOfGameDev challenge and have made good progress. I'm aiming for a playtest amongst friends but before that is a big chunk of testing!

Here's the latest devlog (49?! wow!) of some of the cool recent bits:





Here's what I've been up to:

Sounds
Not everything has sounds yet but there are enough in there to give a little feedback. I've probably still got about 100 to add and a few I want to change. Games need a lot of sound! This will be enough to make the game feel a more alive.

Pressure + Heat
You now can control the amount of steam pressure that comes out of each boiler. You can wang the boiler up to maximum for extra speed (and utility) but doing so generates heat. You can balance that with the amount of pressure you consume. If you don't consume any steam pressure at all and the boiler is set to high then you're going to go bang.

Going bang will require you fixing the boiler and then collecting the little fire sprites and putting them back in.

Boilers make noise, shake when hot, the explosion has sound and VFX and it's all round a cool feature now.

Steam sound and push
Steam escaping from the end of an open pipe now makes noise and more importantly, it now pushes you too. This allows for lots of parkour shinanigans but also I found in testing that if you crash, the steam can get in the way of you switching off boilers that are now overheating.

Dial upgrades
Dials have warning arcs on them to let you know what "too much" is and will flash when the needle goes into it. I found this particularly helpful when exploring at full speed.

Switch pipe
EMW will remember how tricky it was to link up the grabber claw with the boilers because the ports are so close together. Some might relish that challenge and I will provide a surivival mode in the future to scratch that itch.

The switch is like a T-piece except you can shut off steam to one or more exits. Great for the claw but with some clever piping, you can use it for steering and speed. I'm still experimenting with a layout that I like.

I don't think the game is too easy with the switch, I think it's just less hard!

As an aside I rebuilt a couple of netcode bits now that I understand more, some things should be more stable. There are a few other things I'd like to do too but they can wait.

Generally feeling positive
I like these new additions, they're fun to do even in the evenings when my brain has stopped working.

Thanks for dropping by!

[JobLeonard]

(you forgot to close the second [/url])

> I like these new additions, they're fun to do even in the evenings when my brain has stopped working.

This sounds like a good change then! The game is supposed to be challenging for the sake of fun, not challenging for the sake of being brutally challenging

[brainwipe]

Thank you JobLeonard! Fixed.

You're right that I'm pitching this game to people who want to just have some fun. I appreciate the brutally-hard market of games such as Super Meatboy but Clomper isn't that. I have plans for "difficulty settings" that will allow a player to make it really hard to play but I expect those people to be the outliers rather than the norm.

Thank you again for the support!

[JobLeonard]

Well, you do have a way of saying "hellscape" that almost makes it sound cosy

[brainwipe]

I've been trying to answer the question: "is my game fun?" for 2 years now. I thought it was fun but that wasn't enough; I needed something that might convince others. I've been designing, prototyping and playtesting for 2 years.

Some things I learnt (in no order):

1. Put your netcode in first. Putting it in later will mean reworking huge amounts of your app.
2. Be very careful with the netcode framework you choose, it must fit the model your game is based around (hosted, matchmaking etc) because taking out midway is a nightmare.
3. Keeping on the LTS version of Unity is worth the effort. Upgrade when each LTS comes out unless you're close to release.
4. Domain driven design is by far the best way of structuring projects.
5. Everyone is obsessed with events in Unity to decouple everything rather than relying on good domain model boundaries.
6. Avoiding transform parent. Will cause physics lag and netcode rarely supports it well.
7. Do a performance pass every so often. Unity's profile is good enough for scripts; the frame debugger for understading what's going on with the GPU.
8. Have a strong idea what the minimum viable game is and keep thinking "do I really need that for a prototype". Clomper doesn't even have any menus yet. MENUS. 2 YEARS, NO MENUS! Don't need them.
9. Don't setup a Discord community unless you've got content to feed it and a worthwhile call to action (like a steam page). It's a time sink.
10. Spend time on other people's YouTube channels and Twitter feeds - think about helpful comments and reply with constructive ideas. "This is great, keep going!" is nice of you to say but isn't building any community.
11. If your video doesn't do well, change the graphics, title and teaser text. Ensure your tags are correct and numerous.
12. Know why you're doing this in the first place. Is it a hobby? Do you intend on earning money, if so, how long can you wait? What if you stopped? Are you compelled to make this game? What about a different game?
13. Be organised. At the end of a good coding session, get your tasks ready for your next session. Future you will thank you for well thought out tasks after a future hard day.
14. Decompose tasks into small chunks. You should achieve something each coding session.
15. Jetisson bad ideas. You spent 3 weeks on something but it's awful. Kill it.

There's probably more, thank you for all your support!

[JobLeonard]

Ah, another devlog, another "the outside world is a hellscape" in the most soothing voice imaginable

[brainwipe]

I'm tempted to record a section of video where I soothingly describe "burning lava, skin flaying steam, bottomless chasms, crushing hammers etc" just for you! 

[JobLeonard]

Ah, so option two it is then?

Speaking of which, my vote actually goes to option two - what good is being trapped in a lady-bug in a hellscape if you feel like you can't change it for the better?

Anyway, I can tell just from the video footage that the last playtest was a lot more fun - coop games are at their best if you somehow make things work as a team despite hectic chaos (ideally partially caused by the players themselves).

Why do you say it's probably only a two-player game though?

EDIT: also, have you considered communicating things happening the outside world influencing the clomper via the noise of straining metal, with the implication of legs (or other parts) crashing into things for example. Or to make the entire room shake as the clomper moves (or hits something, or walks over more or less rough terrain) by seeing small object shake with every THUD of a leg stepping down.

EDIT2: but seriously, the way you describe the game always makes me think you're going for a steampunk version of Das Boot, but neither your presentation style nor the game itself suggests anything like it





(mind you, I don't think a game version of Das Boot would be any fun)

[brainwipe]

The consensus does appear to be option 2! Helping poor souls struggling to survive on the hellscape certainly needs a more interesting hellscape, that's for certain. Before making the video, I had no idea which way it might go.

The second playtest was much more fun, I didn't show the early stages where they just filled the entire room with pipes but the real fun came when they realised how to complete the mission (there is no tutorial) and then doing it by being ever so careful.

I think it's only 2 player because once the pipes are laid down, there are two job rights now: looking out through the periscope and watching driving. The third player can try to refactor the pipes as you go but there isn't really much of a third job. I can make the inside of the Clomper more "busy" with busy work repairing things and so on but that isn't really a job. There are no guns and I'm not sure I want guns either. As much as it's a job to do; it's not really what this game is about.

Regarding noises: I have a huge list of sounds to make for creaking, etc. The legs to thud (difficult to hear in the video) and I've only just started adding screen shake. That will certainly come. I do love Das Boot and that was someway an inspiration but it's also pretty harrowing and I want this to be a little bit more light hearted - more like Disney's 20,000 Leagues Under the Sea.

Thank you for all the thoughts and feedback, they're very much appreciated!

[JobLeonard]

The third player can try to refactor the pipes as you go but there isn't really much of a third job

Could you maybe fix this by having constrained resources (in terms of space, connections, pipes) so that at any given time you can only make N out of M machines hooked up to steam, requiring constant rerouting as tasks change?

In other words, the constraints have to be overcome by players juggling their allocation.

As a simple example: imagine if you can go forward and backwards or turn (or go sideways?), but not more than one of at a time without reorganizing the pipes

[brainwipe]

That's an excellent idea and I think a side effect of the survival mode (where resources are spent to buy pipes) will certainly do that. Your example of changing the pipe network to turn is essentially how the game started - removing and adding pipes to turn. It made the gameplay something of a chore. I can imagine that being the case for short periods where you're low on pipes/resources but it's not fun in the long term.

Another possibility is to have ports open randomly around the inside of the Clomper that the players must pipe steam into for a period of time or damage is done. That would mean a certain amount of rework. Realistically, I need more stations with some other job that players can make an impact. I was thinking perhaps weather charts - avoiding storms then becomes another layer to the navigation.

I also like the idea of a player being a game director (because I was a TTRPG GM for many years) but that's not really part of the design, so it's in the "nice to have" pile of stuff that won't happen.

I don't need to rush into the third job - if it's a two player then that's OK. I won't restrict another player joining, it just might be boring for the third.

[JobLeonard]

How about leaky pipes? With pipes wearing down faster as more steam is pushed through, combined with higher risk when fixing pipes if they're still in use?

[brainwipe]

Yes! That's a great idea, one I've had myself. Leaking pipes is a much more interesting damage model than I have now - especially if you set the difficulty such that you pay for repairs with resources, or the setting where uncapped pipes waste steam. That, however, is a kind of busy work that some may like as a side-hustle within the Clomper but not as a job as the player isn't making any decisions, they are just running around fixing.

I do enjoy your feedback, thank you JobLeonard!

[JobLeonard]

I can imagine it's a fine line between feeling like you're doing tedious maintenance work and feeling like you're Scotty ("Captain, she can't take much more!") doing his best to keep the Clomper alive.

[brainwipe]

The reception from my last video (devlog 50) was enormous. I gained over a hundred subscribers, passing the 1000 mark. Although the reach will be nice in the future, it's the quality of the feedback I get in the comments that makes it worthwhile. Although there are new faces, the best feedback is still coming from those that have been with me on the journey for some time.

I threw myself into environment creation. I needed to rework my tile loading/creation because I originally did The Simplest Thing That Worked. Originally, I just needed an environment to test out all the other systems, so I knew that it was going to need to change when I added more complexity to it. That time was now.

I've built some Unity Editor tooling to allow me to quickly iterate. Slick workflow is everything - especially when you're strapped for time. I don't have the time for fixing human error, so automation is going to be key.

I wasn't impressed with the Unity Editor prefab creation utility - particularly that they don't have a specific type for prefab - they reuse GameObject. A prefab shares many of its properies with a standard gameobject except that you can use a game object directly but you cannot a prefab. In enterprise dev world, you'd use a separate type for that. If I find in the future that the confusion causes lots of errors, I'll wrap their functions in my own type.

I'm pleased with the crevasse addition. It adds more variety to the world but doesn't add much functionality. It's just another thing to avoid - like the mountains.

Now that this devlog is out, I'll be working on giving the players a little feedback to help them know when they're perilously close to a crevasse edge.