Home Creators Posts Import Register Favorites Logout

Content

Hey! Sooo we sent the big dossier out the door... what's next? Well instead of waiting I've just started working on various stuff that needs figuring out, sooner rather than later on this (big) game.

This week I got help from a real gamedev that gave me some pointers on how to render this game more efficiently (spawning a real 3d object for each stitch on the grid is very NOT optimised. So I've been looking into that. (spoiler: it will involve me having to learn to do shader code).

Let's dive in.

Basically what Nick (the dev) suggested was to use shaders. Translate the flosscross code to a texture that has specific values for the colors and the stitch types, and then read from that texture and apply it to a big grid of stitches that update dynamically every frame.

That sounds all nice and well. But I don't know anything about shaders. I can take a shader from godotshaders.com (great website!) and apply it to something. But this will require me to actually write an entire one pretty much from scratch. For those that don't know about coding, shaders are written using a very different language (in godot that's a variation of GLSL ES 3.0), and they require a very different approach to "regular" coding, where you basically have to math your way through the pixels on the screen.

Side note: all this explanation might be wrong. I'm still at the beginning of the learning curve (and it looks like an almost unclimbable mountain right now).

(if any of you know shader code and want to help me write this, hit me up)

So I started with the bits I vaguely understood: transform a flosscross instructions file into a texture.

Here's one of the characters Myu designed, and this sprite is not coming from pixelorama, but is translated from the xml flosscross file. The first sprite collects the colors, and the second one the stitch types (this might change, to probably fit everything in the same image, maybe with the pixel transparency to indicate what stitch to use?)

And from there, the plan is to basically build the game like a "regular" 2d pixelart game, with the sprites taken from the xml files that get translated to a tapestry that the player sees.

AND that's where I'm at right now. I've managed to get the viewport of the 2d game onto a variable in the shader. Baby steps. First show the shader in a variable, then try and show the shader on the mesh. Then... I dunno yet.

I've been thinking about other stuff here and there, working a bit on the logic for the combat system, trying to write out how it will (probably) work. More on that later. Myu was busy with some speedrun stuff this week, and should get back to organizing that mess of an affine doc.

And that's it for this week. I've been busy at school, there's 3 weeks left before I start an internship for 8 weeks, and that will be a wildly busy time, where I don't know if I'll be able to get anything done besides that. Time will tell.

Check out tomorrow's stream where Myu is going to teach me (and you) how and what a game design doc is, how it's put together and what goes in it!

See you!

Files

Comments

No comments found for this post.