I wanted to focus today on the writing side of things, but since that would leave me with nothing to share for the public blog, I’ll cross off some items off the to-do list while I’m here.
First is the matter of embedded subwindows being changed either in code or configuration. I immediately found this code:
It… did nothing, however, it did nothing! It didn’t crash, meaning the syntax is fine but the placement in the code is probably wrong.
The theory is that there’s a box in the Window nodes that basically ticks whether or not the node is gonna be an embedded window. I noticed, however, that without the code and just trying the checkbox itself did nothing. By which I mean that checkbox or not, configuration or not, nothing changed.
Then, I remembered another one of the list’s items: Generating the window through code rather than it being there in the resource tree. Perhaps changing that upon instancing will be the answer.
Now, how did instancing work again…
Right… var then load or preload. The secondwindow = secondwindow is redundant but let’s leave it for now. And then add_child.
Perfect, though I don’t see it in the Resource Window during debugging…?
Oh, Remote is the resource tree during runtime. Neat.
There’s a problem though, the window ignores all the code to embed it.
Sidenote, GOD I hate replies to questions in forums that are like “hey, watch this whole ass video”…
After remembering the basic bit of “you can change properties before adding the child node” I try it aaaaaand it still doesn’t work.
What’s more, if I check the resource tree during runtime, there it is!
…wait.
What if I’m getting all of this wrong? What if it’s not about if the node will be embedded but if the children of the Window node will be embedded? That would make more sense.
Very well. I can work with that. While I’m making sure to not get bogged down in futureproofing (which was one of the many pitfalls I fell into during N1RV Ann-A’s development as I’ve mentioned before), this is such a pivotal part of the gameplay (being essentially an adventure game) that it will save me headaches in the long run to make the gimmick console-friendly (and just for accesability in general, really).
I’ve scratched the objectives with these findings in mind and reworked them thus:
- Draft the UI and player screen. This will determine the resolution of the game also.
- The “second screen” should have a size that fits within a single screen.
- Add the mockup into the game.
- Create an option where the “second screen” spawns as either a window or a regular UI element depending on the play mode selected.
The activity log will continue internally, but since it’s character-related matters, the public version will stop here.