Today ended up being interesting. Taking a long walk at one point, I gave some thought to next steps, and they yielded some fruit.

Breaking the connection between the extent of scrolling in the world and the extent of the grid simplifies things a lot. I was able to make some minor progress in terms of getting buttons to appear and disappear (which involved some minor rearchitecting to put the game state in a more accessible place, since the controls needed access to it in a more dynamic way). So not much in terms of code.

The interesting part in my thinking was realizing it would be really cool if you didn’t have to specify the grid size – that it would actually be arbitrarily large and would figure out the minimal size based on where you place points. In other words, have it be truly sparse as I had originally intended. If I could do that, besides possibly being interesting to code, it could lead to the potential for larger levels, since it wouldn’t need a full grid of internal positions. That was my initial intention, before expedience pushed me to simply get something simple working.

Wow. The month is over half done. It has been a good experience doing these daily updates, as it forces me to do something. Well, two things actually: both writing the entry and doing something worth writing about to begin with.

Almost no longer a teenager. On to tomorrow.

I began diving deeper on the underlying grid in relation to the grid points and sparse nodes. It ended up simplifying the code. The issue is that the grid is hexagonal, which means that constant x, y, or z, all run in diagonal lines. Trying to treat it as a rectangle means things weren’t syncing up. What I ended up doing was iterating directly over the x’s and z’s. The result was a parallelogram, which (strictly speaking) the player will never directly see, as the actual game level grid points defined won’t typically be the full grid.

It did raise the question for me about the relationship between the number of screen steps and the grid. I originally planned to have the game level editor input the number of screen “steps”, and then it would compute the grid from that. But the grid being slanted makes it ambiguous about the grid should be. And perhaps some levels want a much smaller grid than screen space (e.g. if the background is quite extensive beyond the grid).

So now I’m thinking I might just make them separate. They already are internally. I’ll just have to expose them that way.

In some ways, it simplifies things. I don’t have to work out the “right” way to relate the two, given there might not even be one.

That will come tomorrow, hopefully. Go with editing the number of screen steps and then move onto sizing the underlying grid.

Another Sunday bites the dust. And it’s getting so dark and dismal these days. It’s not even close to winter yet.

Today was satisfying, ultimately, after a slow start that seemed would end badly. Later in the day, though, I just started trying some things, and it started to come together.

I ended up at the point where I have multimesh instances for both the edit grid and the game’s grid points. That was one difference that simplified things: instead of having a single set of grid points that appear, disappear and change sizes depending on state, I went with one multimesh instance with the full set of grid points for editing (which can be shown or not shown) and then another multimesh instance for the game’s grid points. And instead of trying to augment the multimesh points incrementally, the code just rebuilds them from the sparse nodes whenever a change is made. It seems fast enough, it only happens during editing (so it doesn’t have to work everywhere), and I haven’t seen any negative effects to it.

Some of today was spent looking at draw calls and other display statistics, and some simple changes made quite a difference in the numbers.

A significant change was the realization (after reading some Godot reddit posts) that I had shadows turned on for grid points, grid lines, conduits and pulses, none of which need shadows. Turning off shadows reduced draw calls for each by 75% (4 calls to 1 call). Adding a conduit now only adds one draw call, whereas before it added four.

Pulses also still had the full default settings for a cylinder (4 rings and 64 radial segments), so reducing those down improved the number of vertices used greatly where a source is starting up.

The next step in being able to resize a level is to resize the sparse nodes to the new size. I can think of a brute force way to do that, which I might just go with to start.

Get it working, and then get it working better.

Day 17, over and out.

Not much today besides some research. I didn’t find what I was looking for in terms of a solution to my problem, but I guess I at least know now what isn’t part of the solution. One advantage to having separate mesh instances for each grid dot is that you can detect when they’re clicked on (for editing). The multimesh instance doesn’t have that, not even (as far as I can see) for the thing as a whole. So I’ll need some sort of solution.

Day 16: not so sweet.

I had some good luck today with the Godot MultiMesh and MultiMeshInstance, after some initial stumbles. Creating each instance within the mesh is straightforward – I was able to take the code that currently generates instances of the grid dot scene and just set a new “instance” in the multi mesh at that position instead. You get to specify the transform for each instance, which means I can represent active and non-active points.

I still need to see if I can hide an instance as opposed to having to rebuild the instances for each visibility change – or change its scale to 0 or something horrible like move it sufficiently below the ground. I’ll have to think about that a bit… use the right technique.

This image shows some playing around. All the grid dots are held by a single multi-mesh instance, with different scales applied.

Since you can rotate instances as well, I may be able to use another multi-mesh to hold all the grid segments and just rotate each one and position it as needed. Neat stuff.

Learning is fun.

Day 15: what a mesh.

After I wrote yesterday, I worked a little bit more and tried out the new pulse width code. It ended up being what I was going for, so I think that’s good for now.

The next step is back to being able to set the size of each level. However, that raises the issue of the grid points. Right now, each possible grid point has a separately instanced prototype scene. The single screen so far has over 100 points. A level with 6 x 6 screens (as an example) would have 3600 individual nodes, each with its own mesh. I think that would be a potential problem, performance wise. Also, I’d like to be able to support even larger levels, if desired.

I began looking into a Godot’s MultiMesh(Instance). So far, it sounds like what I want. It has to support:

1. Different sizes of grid point.
2. Showing and hiding individual grid points.
3. Being able to click on a grid point

I don’t know yet if it supports those. That will be tomorrow.

Day 14 – baby steps and distractions.

Not much today, but I did manage to do some math on paper to work out some possibilities for the pulse widths. I’ll give them a try tomorrow.

Day 13: bad luck.

I set up a scene to more easily visualize pulse widths. In order to have the variety I wanted, I had to extend the Saurin component to set a value. That was a good addition and something I probably should have done before (though I didn’t need it until now).

Not much more transpired besides this, but it does make me want to drill down on how many draw calls are made for each component. I saw a large grass field simulation in Godot today that only had 55 draw calls. The above has 872. I don’t know if that’s good or bad, so I think I need to isolate things and get a good understanding of what the numbers mean to develop better insight into what is acceptable.

On the twelfth day of #devtober, my true love gave to me…

I ended up not working much on what I had intended to today as, once I began thinking about it, I realized there are some issues that need to be resolved before I can make a stab. I don’t need to know all the details, but I need a plan.

I did a lot of thinking about things, some playing with the game itself, and began working on an outstanding issue in terms of pulse widths. The last one involved some math, which I haven’t totally worked out but which I have taken a first step at working out.

All in all, today was less productive than yesterday, but… mama said there’d be days like this.

I have had some broader thoughts that I’ll make some separate posts for. One has to do with having interesting puzzles as opposed to mechanical exercises. Another has to do with my thoughts about Portal and The Witness (perhaps as separate thoughts and to different extents). In particular, I’ve been mentally breaking down how the different objects in Portal (moreso Portal 2) have multiple uses. A third has do with musings on how you actually end a game. It’s easy to get a game started, but how do you bring it to a conclusion?

I made good progress today.

1. Finished (for now) the “Soojin” component work – materials, new logic, etc. Seeing it now, I have one lingering question about how it looks, but I’ll put that off for now. I think it’s important that the look be precise, since understanding of the game is going to come strictly from what the player sees. A “visual design”, so to speak.
2. Got the “locked” state working for Soojin and Huberts. This is a key part of some puzzles, and I’m glad it’s in place now.

Trying out the two Soojin levels I have so far, I made a discovery based on experimentation in terms of what will actually end up resulting in a puzzle, I’m sure. That has happened at least three times so far, where instead of working out a puzzle scenario ahead of time, I actually discovered neat behavior just while playing with it, behavior that I can help the player to find as well. I want more of that, because they have always been more interesting than what I come up with.

The next step (tomorrow, I hope) will be to extend the editor to allow defining how large a level is. It’s hard coded at the moment, but it needs to be flexible. I have a plan for that. Some upcoming levels need to be larger than a single screen.

On a side note, I was looking at the various game stats while the game was running, and I found a simple mesh optimization that greatly reduced the number of vertices being displayed, especially when the editor is active and all the grid points are visible. If you ever create a cylinder mesh object in Godot, be sure to tweak the parameters for it (e.g. number of radial segments and rings).

It’s amazing how fast this month is going. I’m pleased with the progress in the game, and I’m enjoying just writing.

Day 10 – the sound of two hands clapping.