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?
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.
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.
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.
Today didn’t achieve much, but I did manage to get a couple of small things done.
I exported the new Soojin Blender model as .fbx and then dropped it into Godot. Nothing too special there.
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.
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.
Today was a rainy Saturday – which, once I had some caffeine to overcome the gloom, was a perfect opportunity to spend a number of hours working on Impulsing.
I started out in the morning looking back at the 2D version, as I had completed a number of levels there, some with components I don’t have yet in 3D. I decided that in order to get those levels up and running in 3D, I need only a couple more major components. So I decided to work on one of those today.
I came up with a simple design for it, visually, and got it up and worked out in Blender. It changed a bit as I worked on it. Sometimes you gain inspiration as go along. Also, what looks good in Blender – where you can pan, zoom and rotate – sometimes doesn’t end up looking good in Godot once you look at it in 2.5D at a fixed angle. You lose some of the visual cues that tell you what it is. Here is the new component, “Soojin”. (Code names abound on this blog.)
I got far enough as to get a new component created and integrated into the palette, along with a bare bones underlying node that doesn’t do what I want yet but gives me a place to “make it happen”.
Tomorrow, it will be “TDD time” to get the functionality in place. I thought it might be straightforward enough that I was tempted to just implement it. But then I realized that the behavior was more complex than I first believed. I need to think about what I really want it to do before I try to code it.
Despite having been a software developer for a long time, I have found game programming to be different in very striking ways. You would think it’s all just programming, but it becomes so much more. It might be because I’m actually designing the game as well, but I think it’s also more than that.
If you’re writing, for example, a paint program, as long as people can get done what they want to do in the software, it doesn’t really matter how you do it. You can even have a completely ugly but functional application. The important thing is the ability for people to use it as a tool.
When writing a game, though, you’re actually creating an experience. Just a bare-bones, ugly, functional game would work, but it wouldn’t do well. That’s not what people want from games generally. You need to not only consider what people will do but also how they do it and what they see and what they hear and how do they know what is going on and – most critically – does everything behave in a reasonable way?
My understanding of the elements of my own game has evolved over time and continues to do so. The more you dive into the details, the more you see. And what you have created – if you care about what the player experience is – constrains what you can create, because as you work out the rules and behaviors, the next set of rules and behaviors has to fit in with what you have created so far. You can’t just hack things on. You have to keep refining what you’re doing to avoid ending up with an unholy mess.
Sometimes, the design experience is revelatory. I didn’t know even all of what I have created in the game so far when I started this. The game itself presented issues that became design decisions as I solved them. Sometimes that was the most exciting part, when you come up with that answer to a problem and it’s not just a hack but something that emerged from what you’ve been working on in a natural way. Part of the work of design is seeing what the game is telling you and forcing you to face.
What’s interesting about that (and possibly sad) is that when the design decisions are so natural, nobody but you may ever realize what it took to arrive at them.
