next »

[rj]

as a fellow team member i am going to also ditto the vote for tophats in this here game.

more hats in general. octopodes with baseball caps. octopodes wearing glasses.

glasses, in this case, are a hat

[nialltl]

^^^^ yes! the MAJOR exciting news of the day is that rj has joined us on the musical front! from just brief exchanges he has been nailing the soundscape's feel SafetySnail and I had been picturing. expect a clattering yet melodious party soundtrack - more detail on this soon.

also, going to start actively using our twitter even more to post little mid-development gifs and updates and such, check it out if you're interested!


yesterday's work involved giving our dear podes a little vitality in the form of face tracking:

a solid start

currently each player has a trigger area surrounding them that objects of interest will set off - e.g. other players, possible traps and so forth. the plan is for them to then react according to exactly what's irking them, with a different set of faces for different scenarios - the loneliness of being left behind, getting caught out, getting to the party first, to name a few! so right now this is definitely in its early stages but I feel like even just this level of reactivity works wonders.

today we made the switch to using SVG assets for our hand-drawn overlays to allow resolution independent scaling. the caveat of this is that it doesn't translate so well to the initial mockup tests we've been doing, as they rely on inner glow filters to soften out the landscape, and getting the SpriteRenderer in unity to read such filters from SVG isn't so straightforward. I'm thinking of ditching the pure-svg solution and creating a 2D fragment shader to offset transparent sprite's hulls and then apply custom vertex colouring, but perhaps there is a far simpler way that I'm neglecting. hopefully I will have some sort of update on that in the coming days, though for now I'm going to be prioritising other actual gameplay aspects for GameFest and revisiting it later.

*Ahem*

Tophats would be cool

[SafetySnail]

Is it normal for your eyes to fall out while working on things like this?
The crunch for Gamefest is real!

[Octopus Tophat]

Yessssssssssss!

[nialltl]

shade, light and glorious height



overlay, slippery surfaces, and much more

a lot of work has been done over the past couple of days!

I've still been getting disproportionately distracted by the visual aspect of things particularly with GameFest getting ever-nearer, but it was just too interesting to put down - SafetySnail has been doing draw-overs for various rooms and I didn't want to face him having to redraw everything if I found out our approach wasn't going to work later on down the line.
to follow up on the previous mention of SVG assets, I've since decided to switch back to standard unity native sprites. our terrain layering just doesn't play well with SVG properties as to get nice inner glow filters (that 'softness') would have to be approximated with some post-processing RenderTexture solution. basically a lot of performance / visual gain from the SVG assets would be counteracted by the added postprocessing cost in the long run anyway. plus, sprites work just fine, and since we only need to use 1 with some clever dynamic tinting (will go into this later), the texture memory load is pretty negligible.

I finally got one of the main racing mechanic components out of the way: detecting who’s in the lead! we could decide only to care about the order in which people make it to the finish line, however by tracking who’s in the lead we can design the camera to stay with the faster runners:

dynamic leader camera prioritisation

this begs the question of what to do in the case of people being left behind. it’s not feasible to assume the camera could just keep zooming out ad infinitum as it’d get hard to track where everyone is, and it lends itself to pretty slow gameplay.
the solution we came up with is this: when a player has ‘died’ by being left behind, little trigger pads will pop up in front of the leader of the octopus pack. by triggering it, either intentionally or accidentally, the dead player will respawn just behind them, crawling up out of the earth. the nice part of this is that it adds the tension of either attempting to avoid the respawn pads when you’re alive so your friend can’t rejoin, or deciding whether to risk getting them back in for the sake of a fun match. I’ve yet to implement the actual respawning part right now, and I feel like it’ll take a lot of testing to make sure it still feels fair, but in principle it should be pretty fun. I’m envisioning the “dude wtf why didn’t you let me back in” conversations with your partner, or alternatively “I should never have let you back in, I was so close to coming first”.

here are some very rudimentary hand-drawn overlays for rooms that I took while we were testing out svg / sprite formats:

of course rooms boundaries will never be this clearly defined, I’ll combine linked islands’ colours to make it seamless – but it’s a fun little proof of concept from before the gif at the top was created.

one thing you may have noticed from the above few images is another little addition: shadows!
right now the system is a bit hacky and rudimentary but for our purposes, particularly under the time constraints of GameFest in a few days, it works quite well. essentially the way it works is using a two-phase raycasting check. initially, I shoot a ray straight down from the player’s centre. if it’s within a certain distance of the ground, I position a simple alpha-blended shadow sprite at the raycast’s point of collision. it’s rotated to align with the normal of the plane – to prevent jittery shadows I smoothly interpolate the shadow’s orientation over a few frames. it’s very subtle, and not enough to make the shadow ‘lag’, just enough so that you don’t see pixel flickering when going down curves, for example.
the scale and alpha of the sprite are also slightly modulated based on the distance between the player and the raycast’s hit point. the further away, the wider and more transparent it is.

this has its limitations though – when it comes to things like sharp corners, overhangs and steep slopes, shadows end up bleeding out over the level geometry and making it obvious that they’re just decals. ideally I’d have some kind of sprite-warping projection routine here but I am too poor for these high quality Solutions.

so for a second stage of refinement, I move on to raycasting down at the either side of the player’s extents:

if it detects that the vertical gap between each ray’s hit point exceeds a certain threshold, it flags that the shadow should be rescaled so that there aren’t any overlaps. it also interpolates this width over a few frames, you can see it in action in the very top gif as each player reaches either side of the half pipe. I’ve done this very naively and just fixed it to be around 20% of its usual width and it looks okay, but again, a better way of doing this would be to do a few more raycasts and stretch the shadow between the last two ‘valid’ rays that touch the ground. in any case, the system I have so far already makes the podes feel a lot more rooted in the world.

--

more things related to level layouts! I’ve added a little bit of sproing to the slam-switches and it instantly feels a lot more lively. one thing I’m not quite sure what to do with right now is that moving kinematic rigid bodies can cause players to pop right through if they’re standing on ‘em while a switch is triggered. perhaps that’s okay? physics glitches can be fun, but if during gameplay it’s too common, starts to feel unfair or just plum doesn’t fit I’ll revisit this for real.

loosey goosey slam-switches

I also added some probabilistic tuning variables to all the traps for some more varying rooms, and finally added proper support for frictionless and slippery surfaces. best showcased again in that top gif. players can slam right down on them and build momentum, so hopefully we’ll have a few more momentum driven situations coming up.

over the next couple of days I’ll start working on getting a proper character selection screen and other parts of the UI functioning. with RJ! on the beats we’ll get an actual gameplay vid out soon!

[rj]

i def see trigger pads as being perfect for races with more than one person. there's an element of chaotic strategy there, where someone could use the trigger to trip other racers up

also i Can Not Wait for people to hear what i've been working on for this, it's some of the craziest stuff i've ever made

[oahda]

The hats staying in the air when falling after a jump is the best touch ever.

Neat shadow solution. It only really looks weird on edges and really thin surfaces, so I don't think you should worry too much—to some extent I think it can be covered up by clever level design. Looks great in the first GIF of the last post, for example.

Only criticism is I think you shouldn't allow the legs to extend that much before letting go of the floor. Gives a rather odd contrast in length between jumping and standing on the ground.

[corupted]

Lovely Devlog here 

[nialltl]

NOTE: we now have a MAILING LIST, if you'd like to sign up for bigger updates (upcoming alpha builds, releases hopefully!, etc). you can also suggest any hats you'd like to see in game, to honour the time immemorial tradition of character customisation.

i def see trigger pads as being perfect for races with more than one person. there's an element of chaotic strategy there, where someone could use the trigger to trip other racers up

this man has it right. we're aiming for it to be most dangerous to be in the lead - every player has the opportunity to trip up anybody that's in front of them.

Lovely Devlog here  

it was a pleasure to meet you the other day, we'll be seeing you soon!

The hats staying in the air when falling after a jump is the best touch ever.

Neat shadow solution. It only really looks weird on edges and really thin surfaces, so I don't think you should worry too much—to some extent I think it can be covered up by clever level design. Looks great in the first GIF of the last post, for example.

Only criticism is I think you shouldn't allow the legs to extend that much before letting go of the floor. Gives a rather odd contrast in length between jumping and standing on the ground.

thanks! I think you're right about the shadow thing. when we were demoing the game 2 days ago I completely forgot about it being an issue, with our art overlays in place the problem completely disappears. there's that perpetual nag of 'this is a hack' still in my head but I think I can get over it.

I see what you mean about the legs, but I'm inclined to keep it. the slow motion nature of that gif I posted really emphasises it, but in motion it actually feels a lot more like the anticipation of a landing with some squash and stretch:

what do you think about it here? if it's still too much I can try toning things down a bit. they ARE very wriggly creatures.


so we spent saturday at GameFest, and it was great! this is the first time I'd attended any kind of expo or showoff or convention or anything - being greeted at the door with a "you guys the indies? walk this way" and getting guided to our table, seeing other polished games alongside us, was super cool and somewhat intimidating. we eased into it pretty quickly though, following a shaky start in which none of the controllers we brought were being registered by our PC.
SafetySnail will do a more in depth post soon about the design aspects we uncovered during gamefest testing, but a personal highlight was a few kids that got super invested in the game and played for half an hour straight (the best bugtesting service I've ever had).

the night before the event itself we had a power surge due to one of my UK - Australia power adapters and the whole house lost power. luckily we'd saved everything we needed and had it all backed up, but it still resulted in lost hours and I was up working on getting the build playable until around 4:30am. as a result the codebase is now messy as hell and I'm aiming to spend the next couple of days on a combination of bug-fixing, feature adding and digital sweeping up.


one of the big features I was able to add in time was the player respawning mechanics. our camera dynamically zooms to accommodate multiple players, but in the event that one gets hopelessly left behind, they'll respawn as a trigger that other players can accidentally / intentionally touch to bring them back in the end. if trigger players ('dummies' as I've called them) are ignored for too long they'll try respawning somewhere else. this was super fun in practice, especially with 4 players going at once, and it overall feels quite fair. since dummies  choose new locations all the time, players will always have the chance to change their mind and bring their friends back into the game.

dynamic respawn system in action

there were also some pretty funny issues along the way:

the way candidate dummy positions are chosen is by a raycast performed out from the octopus in the lead in the direction of its velocity. initially I'd tried experimenting with things like circlecasts to allow a radius of possible dummy positions on all sorts of terrain, but I was having issues with raycasts hitting areas that were impossible to reach due to us sometimes using pretty thin collision volumes. here's a weird intermediate solution I had to do with iteratively projecting raycasts out in the direction normal to the nearest surface:

the lonesome fisherman

the final solution took some more tweaking though, as in some cases players could get spawned too far out of the leader's reach. e.g. in that second gif, the raycast in the direction of the player's velocity while jumping puts the candidate dummy position on top of a platform that's too high. I now cap the direction of the raycast to be within a reasonable range, and make sure that the normal of the surface isn't too steep (to prevent player triggers being spawned upside down, like on the underside of a circle collider higher up than the player).


there are many more things I've been working on but I'll end this post now and get back to it.

bonus slippery surfaces gif from our twitter:

[nialltl]

a name is given its purpose

phew! a lot of developments are being put into place right now. we showed the game off at a local dev meetup in Sydney, and got some good insight from other developers. as it turned out once people got a little tipsier and started getting more competitive the heart of the game really started to show itself -- the initial analysis was really helpful and people had some cool ideas on how to make the gameplay tighter, but seeing 4 people crowded around our little laptop setup on controllers and keyboard calling each other various colourful names, was what we had been pining for!

one thing that made itself evident through playing a bit more is that the gameplay is too 'heavy' - I like the simplicity of a control scheme of 'left, right, jump, dash', but it ended up making games too monotone and didn't allow many subtleties on behalf of the player. therefore I've been working on a Dash mechanic (fitting with the name! finally!). the idea is that you have a fixed amount at the start of a race and you can use it strategically but it'll wear out and you'll get tired as it recharges. this won't slow you down further when you're tired as that just feels annoying, but it's something that you'll be punished for if you try and use it too liberally given that it's harder to predictably control your trajectory.

octopuses do little flips if you dash while you're in the air. this took a while to tune to a point that felt nice - it's still far from complete and I'm hoping to go a little crazy with juicy goopy particle effects (ink?) when I start focusing more on the visuals, but for now I'm happy with it. there were a few issues along the way:

but now on the plus side I can perform arbitrary octopus rotations and the legs will follow accordingly. we want to try a mechanic akin to cannonball-rolling down slippery hills and inclines, so the moveset isn't quite final yet, but we'll see if it's necessary once we do some more playtesting. I think it could be fun and will help make rounds less buttonmash-y.

you may have also noticed in the dashing gif that the octopodes have a little visual upgrade. I've finally incorporated a subtle gradient into their design - this was something I ended up being minorly on the fence about as I am fond of the flat visual design. but I went for it and am really happy with the result, they seem to sit much happier within the world now (to my eye at least). right now the podes are by far the closest to their final form - it's important to remember that everything visual is pretty subject to change. I'd like levels to be procedural beyond the point of their layout - with some clever palette choices it'll be great if we can get every level having its own distinct feel. this should be reflected in the flora of the level as well.

here's an image of an intermediate stage of giving the legs the gradient with vertex colours, in which I accidentally gave them tights:

a leg customization option is now being considered. can you imagine these guys with little boots? I KNOW you want to.
I've also spent the past couple of days doing some bugfixing and optimization - changing the camera rendering path in unity to legacy vertex lit on games like this can be a real framerate saver, pro tip to you. also worked on making the player respawning a lot tighter, and as a result you can get into some very fun multiplayer situations.

[cottontrek]

This devlog is fantastic

[maruki]

This devlog is fantastic

I second that. Those hats, those faces, those legs, I love everything!

[SafetySnail]

Hey everyone, thanks for the kind words about the devlog!
As Niall mentioned we have recently been trying to show the game around small local conventions/indie dev meet ups and the reaction has been both really fun and super eye opening! We've been working hard to try and keep the game as easy to pick up as possible while still allowing you to develop skills that can get you ahead.
We've found it generally takes people 1 full playthrough of a race to really get the hang of the controls and be able to properly race without having to think too much about what button to press and when. With such a small control set it really allowed players to get into the game quickly, which is exactly what we were aiming for.

One issue we saw a lot was that because most of the rooms are designed around moving one direction the game can become sort of button mashy. While we feel this isn't necessarily a huge problem for a party game like this we kind of wanted players to try to find the more advantageous routes in the rooms and make better use of traps to help them get ahead instead of just running along hoping the person infront of you messes up somewhere.
The first thing we tried was to remove a few mechanics we had added to traps. Switches now no longer require a slam to activate them and will trigger simply when players run over them. Seed shooters also don't need another player to run over them first meaning they can be fired by anyone. We're hoping that by taking restrictions off the traps/interactable elements it opens up the game a little more and makes it a more interesting environment to play in.
Another thing we noticed when watching people play was that straight rooms were REALLY boring. Because everyone's top speed is the same, whoever enters the straight first, leaves first. It completely takes away any gameplay and you're basically stuck where you were over the whole room. Straight run rooms were originally incorporated into the game because it felt almost too intense to constantly have obstacles and we wanted to give the players some breathing space.

Our current solution to this is the previously mentioned dash mechanic. Having the dash allows us to have the easy terrain of straight runs while still giving players the opportunity to overtake their competitors. It also caters to another playstyle we saw when playtesting,wrestling!
We found that almost everyone who played the game had a few races, got the feel of the game and then wanted to stay in one room, bop each others heads and roll around. Playing around like this is too fun and we're really happy with how the dash mechanic allows for this sort of play while still racing. It's also got us thinking about potentially having a wrestling playmode with battlerooms but we'll see how that goes later!
Playtesting also revealed a few other small things that help with keeping the game fair. Our respawn mechanic used to try and respawn the first player to go off screen and would keep trying to respawn them before anyone else. We've now changed this so that it cycles through players that are no longer in the race meaning that friends can either save certain people or purposefully avoid them if they want to be really mean.

Alright, time to get back to making this game beautiful!

[nickFromPaintteh]

Hello

First: this looks amazing guys ! Congrats!

Second: is there a chance that you have online multiplayer available in the future?

[rj]

online is hard. ideally? we want to? but um. online is hard

this is an ideal couch friend game anyhoo

[nialltl]

Hello

First: this looks amazing guys ! Congrats!

Second: is there a chance that you have online multiplayer available in the future?

hey, thanks so much! what rj said is right - multiplayer would be fantastic, but it's something we've never wrestled with before and I know it can be very time consuming. the initial focus will be on local multiplayer only but if the game gains some more traction I'd love to be able to focus on it more. for now we'll try and get the game as best as it can be in the flesh before worrying about net code!

here's a preview gif of the foliage systems I've been working on:

any suggestions for plant types you'd like to see?

[Ghat-Smith]

I took a quick look on the topic. This looks really interesting. I definitely need to read all this topic (but no time at the moment, damned).
I love to see work in progress gifs and it's really cool to see your progress to reach the current project state.
Please, keep up the good work and good luck !

[nialltl]

@Ghat-Smith thank you so much! glad you're enjoying what you're seeing.


just a quick update -- the foliage / decal systems are well underway and I'm really pleased with them. I'm using little 'decal area' objects that you can place in the scene view, that will then populate anything in their area of influence with randomized splatters and plants and such. here's what it looked like in its early stages:

I've since extended the decal area options to be a bit more versatile with some scaling options, and added a lot to the 'squashy' objects in the inspector as well:

what's nice about this system is how much variation it allows. right now I've only been logging things using one test plant but nothing's to stop me adding as many as I like and having decal areas cycle through them randomly. it can be used for both moving objects that sway in the wind and can be pushed, AND I can add ground splatters /  textures to the list of spawnables and they'll automatically place themselves on the ground based on the pivot point set in their original art asset.

they also have a 'chance' variable that defines their probability of spawning, so in some areas you'll see a certain set of flora and if you get a similar area again later on it'll look different.

we've also now switched from marking some colliders as slippy to just defining 'slippy areas' as per the decal system, which can be probabilistically placed too! here's a test from that where I've mixed slippery and flora decal areas and ended up with multiple surfaces looking like some gooey toothbrush:

I'm going back to work on sfx stuff for now just with placeholder sounds while rj's getting his laptop fixed. here's a preview of that!

[nialltl]

no easily discernable changes at the moment, but I've been working a lot on getting processes automated between the art asset creation and the code. I have rooms automatically assigning themselves their corresponding art overlays and it's handling shifting platforms etc quite well. I do however feel like as I get crazier with particles and moving decals etc that I'm probably not being so efficient (one of our modified SVG shaders may be unnecessarily drawing terrain pixels twice and I'm not really sure how to check). in any case I try not to worry too much about prematurely optimizing anything as it's still smooth as a whistle, but the feeling's more 'bracing myself for what's to come' - if anybody has experience optimizing 2D stuff within unity please get in touch!

I've also juuuust begun dipping my toe into procedural palettes, and have started experimenting with varying backgrounds. here's a glitch I got from some materials that went missing:

octokyo drift

I personally really like how the darker levels end up looking - things will definitely be able to get all airy and pastel-y but I'm trying to make sure there really is variation in every corner of the game.

[nathy after dark]

Never heard of a foliage decal system like that, but it's looking good. Although in the GIFs, it doesn't look like the plants are always appearing squashed when they should be. Looks like they get squashed when a player runs on top of them, but not if a player gets bumped on top of them by another player. Bug?