I'm ditching this account because I hardly ever use it and people are apparently blocking this instance. If I pick a new place to move my alt to, I'll post it here.

the most inefficient way to render a pink square i've ever used... 64x64 grid of single-pixel pink sprites.

the blue/red bar is the highlight, it indicates which boxes you're going to change when you hit the change button! pink is my current "nothing here" color.

I just spent ages trying to figure out why this node wouldn't let me update its transform, only to realize the reason it wasn't moving from (0, 0) was because my math was missing some parenthesis and kept multiplying everything by 0

It's just a match-3 (or more, IDK how hard it'll be to get matches)
The direction blocks fall depends on whether a row or column was switched to make the match.
Blocks will never fall into space that wasn't occupied by the matched blocks.

New blocks arrive in the empty space nearest to the center of the board.

I might also add Yoshi's Cookie-style line-sliding for lines shorter than their neighbors, but I'm not sure.

Show thread

It's been a while since I've posted here, hasn't it?
I'm working on a project for LOWREZJAM 2019, so I'm probably going to post about it here.

The basic idea is as follows:
1. A 64x64 grid (the full allowed resolution) of colored squares. The player can select a single row or column, and when they press a button, the entire line "switches." What exactly this means for each color varies: Red becomes blue, blue becomes yellow, yellow becomes red, white becomes black, black becomes white, etc

vive motion controls outside VR, pt. 6, i forgot somethign 

Show thread

vive motion controls outside VR, pt. 5, the final part 

Show thread

vive motion controls outside VR, pt. 4 

Show thread

vive motion controls outside VR, pt. 3 

Show thread

vive motion controls outside VR, pt. 2 

Show thread

vive motion controls outside VR, pt. 1 

Cubic gravity works! It made me notice some issues with the camera, and I still need to find a solution to the whole going-into-orbit thing (It's not unique to the cubes, but it's more of a problem on them.) It's functional, though.

Hey! Wanted to apologize for being quiet lately. Here's a quick screenshot of something I've been working on: A cubic planet! One of the faces is still entirely flat and the others don't have much to do on them since there aren't any objects in the game for me to populate them with other than bumpers.
I'll get a video out once I have the cubic gravity code worked out (it's more complicated than you'd think! I'm taking a page out of Patterns's book. Practically the only good one it has, haha)

love to look through the docs to try to find a function that does what I want, think it's not there, try to figure out how to do the math myself, then realize the function is there and is named something really obvious and i didn't see it because I assumed it would return a different type than it did

Thanks to someone on the Godot discord (which is really great, by the way) I now have come up with a really efficient way of storing my gravity shape data (for cubic planets, tubes you fall towards, tubes you fall around, and planes that flip your gravity when you pass them). My original method resulted in a lot of duplicate data and code. Tomorrow I'll code a number of weird gravities near that of of Super Mario Galaxy!

Google's Blocks tool would be amazing for creating levels... If I could see object dimensions while scaling and not just placing, and if I could configure the grid snap like I wanted it. Currently one grid snap unit is like, 1cm and I can't make it snap to anything bigger, and the grid lines are 4cm apart.
For reference, the ball is 1 meter in diameter.
I can certainly scale them up when I'm cleaning them up in blender so that 4cm=1m, but I don't *want* to do that.

Show more
Gamedev Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!