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.

Quick update today…

I got the Soojin materials labelled in code (not sure why they’re always somewhat scrambled). I also have the six values from the lower level node being reflected in the shader materials for the UI-level component. There are six more materials to populate, but that requires exposing them from the lower level node. I think the values currently being used aren’t quite right, either. (They have calculated values, but those values need to be split. Shouldn’t be hard to do.) I’ll have to work that out tomorrow, but that should be fun to get it all working.

Day 9: TGIF.

Today didn’t achieve much, but I did manage to get a couple of small things done.

1. I exported the new Soojin Blender model as .fbx and then dropped it into Godot. Nothing too special there.
2. Got the Soojin object to respond to a mouse drag so it can be moved around. This ability is part of what is driving the model redesign – the new functionality makes it similar to another existing component, so I’m changing the look to be more similar (same family, so to speak). Perhaps down the road, even more behavior will unify – or even code.

That’s it. Not a lot, but taking a small step each day means you’re at least moving forward. It might not be speedy progress, but it’s more progress than none, and a little each day can add up a quite a bit.

They say that seven eight nine. I guess we’ll find out to tomorrow.

I have enjoyed working with shaders in Godot. However, I have found I don’t know all the ins and outs of them. That is to be expected when you’re learning something, but it can be frustrating when things start to go wrong in ways that it’s hard to know how to even begin to attack.

I have been living with this odd shader behavior where one component starts to behave erratically when there are a number of pulses on screen. I happened to be reading a bit about the Godot renderer today, and it was talking about how shaders that use alpha are processed differently. This particular component had two shaders with alpha (a nested situation). I finally had an idea to try to solve the problem.

I ended up getting rid of alpha for one shader and repositioning things a bit. That either solved the problem or avoided it such that I don’t see it anymore (“solved”). Either way, I’m happy for now.

But I have a feeling there will be more like this eventually as I explore the boundaries of both my creativity and the engine.

Beyond that, I tweaked the Soojin model some more, after a walk where I contemplated the design a bit more. It may not be perfect this way, but it will be a good start. Then I can see how well it works. Refine or redesign from there.

Day 7 – almost a quarter of the month done. It has been fun so far.

In the end, I’m glad I didn’t get much done yesterday. I’m not sure why I felt like crap, but taking another day gave me a better idea of how to proceed. Tonight, I got some of that going, with a new Blender model.

The colors are just so I can know where the materials are defined, though I think it’s a cool look. I’m not totally insane, though.

I integrated it into the game, except for the new material work. That will come tomorrow. I think it’s going to work nicely, in the end.

Six days down. I didn’t create the Universe, and I’m not planning to rest any time soon, but it has been some nice progress. And sometimes you have to make a brief stop to go even further.

Not a great day, to be honest. Spent some time sketching, in a not so good way. Began some new modelling in Blender, but couldn’t get some basic things to work. I think I’ll have to look to tomorrow for better productivity.

Day 5, we hardly knew ye.

Not so rainy today, but I still got a bit done. I TDD’d the new “Soojin” node. It ended up being a bit more complicated than I thought, in terms of various cases I had originally not considered, but which became clear once I started pulling it together.

I ended up in an interesting place.

Getting the component to work and seeing it in action, I began to realize what it actually was as opposed to what I originally intended it to be. I find this to be a more common occurrence than I would have imagined. And it’s part of the fun in this creative endeavor. I used to have the same experience when writing – sometimes the characters and plot would evolve as I wrote it in ways I hadn’t anticipated. It’s a joy when that happens.

I had a very specific use for this node when I sat down to create it. In the 2D game there was this component containing two nodes:

The purpose of the component was to act as a sort of “target”. Once triggered, it would remain going, enabling further sections of the graph. As I moved to 3D, I have been trying to revisit these sort of two-node components, to see if I can simplify them. Some components will need to be directional; those will come later. I have been able to reimagine these components as single node components. What that means is figuring out what is fundamental about them and then creating one or more nodes that either implement that functionality or that can be combined to do so.

What I have found is that when recreating these as single nodes, it often happens that I can implement behavior that suffices for what they used to be, but the simplification often ends up bringing it with new uses and behaviors that (ironically) the more bulky component didn’t have, since the original component was more targeted and specific. By extracting out the essence, it ends up with more and varied behavior. I don’t know if that makes sense. Perhaps someday I’ll be able to be more specific.

At one point today, I took a walk just to get away from the computer, and I began imagining different setups with this new component, and it suddenly dawned on me what it actually was. It wasn’t what I had originally thought it was (or what I had named it – “Soojin” was more a “Mary”. Don’t think about that too much. I doubt you’ll be able to attribute any sense to it. It’s more arbitrary than you might think). Apart from it being quite exciting to find new uses (and new puzzle potentials), it also means I’m going to have to redesign its look. It’s important that the components provide good feedback about their state, so players know what’s going on. The current component design doesn’t show enough. There is more going on under the surface that needs to be made surface.

Stay tuned for a new look. And for another #devtober day.

Day four, not looking forward to Monday tomorrow. All that time spent working when I could be doing this.