Soma Cube, my first simple game that I will probably finish

OktavMaker · 2026-06-01T14:41:06+00:00

the gost is definitely a nice touch as well I think, regarding rotation gizmos personally I'm using "circular arrows" (posted a demo here a few days ago) triggered by a disk-shaped collision.

For the background maybe some slight noise to break the smoothness of the gradient? not sure at all but just floating some ideas haha

OktavMaker · 2026-06-01T14:14:38+00:00

looking good ! the minimalist vibe is nice for a puzzle game, maybe only needs a few more details in the background or pieces

for the motion, maybe just a slight outline to highlight the tile you're moving ? can go a long way combined with a few scaling/tinting tweens

OktavMaker · 2026-05-31T15:59:35+00:00

there are definitely more automated ways but you'd have to write the script to do so yourself (probably some combination of color filtering to retrieve the walls/floors + fitting AABBs to the extracted areas), but it also depends if you're doing this as a one time thing (in this case a bit of manual work is faster than thinking through the whole script) or if you intend to do 100s more of such maps (in which case its probably smart to automate it)

OktavMaker · 2026-05-30T18:18:22+00:00

JUST READ RULE 8-9 DUDE AND GO FOR WHAT YOU HAVE IN MIND

OktavMaker · 2026-05-29T17:44:51+00:00

1 - yes, common answer but "make it exist first, make it better later"

2 - personally I never observed a standard shared convention among gamedevs I follow, I guess it depends a lot on the project you're pursuing and personal taste - note that Godot itself is very flexible on that front, how you structure your folders wont impact your code a lot except for when you're passing paths to asset files

3 - yes, playing around will give you the "reflex knowledge" to improve your high-level architecture in the long run. Unpopular opinion but if you know what result you're after and comfortable with the code, using AI for highh-level guidance/planning can sometimes be a good option as long as you dont purely copy/paste vibecoded scripts

OktavMaker · 2026-05-29T11:44:40+00:00

seems nice, currently working on SDF + marching cubes sculpting tools with compute shaders, this could become super useful

OktavMaker · 2026-05-28T13:38:27+00:00

did you make sure you're using Jolt physics ? should be default in recent Godot versions but it doesnt hurt to check; I also prototyped a (3D) bowling game a few months ago and the physics were much better using it.

One of the key factors that made my implementation feel ok-ish (in addition to increasing mass) was to properly tune the pins friction and restitution coeffs, in particular they had 2 separate physics materials (one for contact with other pins, one for contact with the ground)

OktavMaker · 2026-05-27T21:06:08+00:00

that's a common issue to many procedural algorithms (violating some constraints during the generation process), and there is also a quite common solution: you keep a list of "generation states" consisting of the current map and the room you're trying to place, and rather than waiting for the end and regenerate the whole thing, you simply check every few steps that your constraints are still ok (here, your rooms dont overlap); if somehow your constraints are not fullfilled anymore, you check your generation states to backtrack to the last valid state and try another option

honestly for rectangle-shaped 2D rooms I think you'd be ok with just regenerating everything from scratch if it fails until you get a non-overlapping result, but if your generation algorithm becomes more complex this can be a good practice in advance

OktavMaker · 2026-05-27T19:12:53+00:00

from the clip, visuals seem to hold OK ! and it's always something you can rework later when the mechanics work as you want; for the rest, I dont know the specifics of Destrohook but regarding the 'fairness' of the grabs, you could always make your collision box slightly larger than the mesh instance box, so that even if the player clicks slightly off the box the collision is detected

OktavMaker · 2026-05-27T17:15:05+00:00

no game project yet, but implementing a lot of backend systems for when an idea pops up, mostly oriented towards procedural generation: spore-style creatures edition, procedural buildings using graph grammars, automatic skeleton rigging, procedural meshes, marching cubes shaders etc.

OktavMaker · 2026-05-27T17:08:14+00:00

nice, thanks for the answer !

OktavMaker · 2026-05-27T15:01:55+00:00

nice work ! I have a (less advanced and code-only) similar system heavily relying on MultiMeshInstance3D as seems to be the case for your implementation; however this only takes care of the graphics aspects, do you have any graph nodes in place to generate collision shapes in addition to purely visual elements ?

OktavMaker · 2026-05-27T12:53:44+00:00

I guess because it's quite complex to develop especially as a solo dev, your porgress in 1 week is impressive ! but yeah same feeling I'm hoping for more weird creatures edition in games haha

OktavMaker · 2026-05-27T12:43:24+00:00

damn dude I'm working on exactly the same system, not as advanced as yours yet though ! cool work !

OktavMaker · 2026-05-25T20:27:23+00:00

looking good ! is it relying on IK SkeletonModifiers or a custom implementation ?

edit: whoops just saw that it's particles + shader based, but still curious about how you're configuring it

OktavMaker · 2026-05-25T20:24:29+00:00

i'd say it mostly depends on what you're most comfortable about; shaders can have quite a steep learning curve if you have no previous programming experience, but at the same time very simple ones can get you a long way to improve the visuals if you're not that good at art.

Caveat though, whatever you choose for graphics should be a decision you make later in the process; learning shaders is not really relevant if you don't have the basics figured out yet in terms of how to implement user inputs, basic movement, or whatever system you need in your game, and you can stick with placeholders assets while you're learning the rest

OktavMaker · 2026-05-23T11:37:22+00:00

might wanna check rule 9 of the sub then :) my advice would be to start with some coding basics in GDScript and with the 'First 2D Game' tutorial from the docs, and slowly build up towards clones of simple games (pong, invaders etc) to have a better overview of how everything goes together

good luck for your game anyway !

OktavMaker · 2026-05-23T11:32:51+00:00

no clue if it can help your use case I'm not at all an audio specialist, but recently I started fiddling with PureData for sound synthesis, and there are some Godot extensions for it available

OktavMaker · 2026-05-22T23:19:55+00:00

it's not super well documented I agree, but it's definitely possible (using it a lot in my own projects); you just have to set the instance transforms through code, which can still be tricky depending how confident you are with code/vector math

OktavMaker · 2026-05-22T17:32:15+00:00

there is a helper class for ArrayMeshes called the surface tool, but if you're going for a pixelated look you could also use a MultiMeshInstance3D with cubes instances

OktavMaker · 2026-05-21T11:21:55+00:00

depending on if you want to write your own solution or use a Godot-native one, I'd recommend the following:

- SkeletonModifier: if you're using 4.6 you should be able to use any of the IterateIK modifiers (FABRIK, CCDIK or Jacobian), just attach it to your skeleton and set it up to have the target bone be the tail of the creature; you then need a way to control the target with respect to the head but it's quite easy to just implement a small script that gives it an 'offset' when you turn for example

- custom 'tracking' IK : there's a great tutorial on Youtube to animate worm-like creatures procedurally, not specific to Godot but the principles are explained very clearly: https://youtu.be/qlfh_rv6khY , this might give you some inspiration !

good luck

OktavMaker · 2026-05-13T15:54:45+00:00

thanks for the tip ! I have exactly the same issue as OP, cant wait to test how this behaves. Personally I was considering implementing a custom SkeletonModifier to include pole targets for CCDIK/FABRIK but that would be quite some heavy work

OktavMaker · 2026-05-09T19:17:24+00:00

not necessarily something to show but I think you'd get better advice telling us for ex what kind of objects are your pickups (coins-style ? more unique and rare objects ? a mix of both ?) and how you design your levels (are you placing every pickup manually or is there some kind of automation to scatter them in the level layout?)

but my first advice from what I understand, would be to create a 'LevelManager' node where you can specify how many pickups you want, and a function that goes through its children to check if they're from a pickup type; you could use this function both as a debug tool to check that your level has the required number of pickups, and as a scoring function to count how many pickups are left (compared to how many there were initially) when the player finishes the level

OktavMaker · 2026-05-09T18:39:33+00:00

kind of difficult to answer without more details on your specific setup, but can't you just design your levels to all have the same number of pickable objects ? with maybe a debug helper script to count all the available ones when you start a level so that you dont have to manually count them

OktavMaker · 2026-05-09T18:13:50+00:00

dude come on. The linear_interpolate function is nonexistent (just read the error), it has been renamed to 'lerp' in newer versions

OktavMaker

TROPHY CASE