Hello good people!
John's busy trying out some new dev-textures, experiencing what it means to "block out a level". It means more productive workflows, by the way. He'll figure that out eventually.
Here's what will be going on between now and November. Granted, nothing else that's super big and super important will interfere.
We decided we'll use the time to catch up on our development tools and technology. During the development of the demo it became clear that we had some ... shortcomings. So it's gonna get a bit techy here. A glimpse behind the scenes.
If you played the demo, you'll know how the library looks in-game.
(If you didn't play the demo, you should)
In the editor it looks like that image above. Those coloured markers are all pieces of game logic to a certain extent. You can imagine, it's a pain to find the issues in this chaos when something goes wrong.
That process needs speeding up so - how?
We figured a developer console will do the job.
It seems like a simple thing to have and it is. I can recommend it to any developer out there. It will make your life so much easier so many times.
Workhorse in this console is a powerful command processor and you can get your hands on its code soon. If you want your own consoles in your games.
It's become a super useful tool.
With it, we can manipulate the gameplay mechanics anywhere in any way we want. We can trigger certain events without actually playing. This shortens the time we need to find issues or test certain gameplay contraptions dramatically. Going forward, creating puzzles will be much faster.
Another change, very code-heavy, was a trace function for the gameplay mechanics. As you can see in the console, we can print a trace of what happened and who started it. It's very useful to debug those complex gameplay contraptions when they don't do what we want them to do.
What we still have to work on:
More editors. You can never have enough editors.
For one, the item database. It's terrible right now and needs to be better.
Look at this monster.
Extrapolating to round about a 100 items (possibly more) this is going to be veeery nasty. So. Making it better it is.
We got a thing called PlayerVars. It's a bunch of stuff that represents the players state. In there you find flags about what the player has seen, how the player has reacted to things, what kind of outcome certain puzzle chains had and much more. It's a global context which is used to create branching in dialogues and gameplay. Currently it's a loose set of variables. It's hard to keep track of all of them.
So we have to build a kind of library where we can view all variables, create new ones, manage existing ones and so forth. If you ever worked with an RPG Maker you can think of its variable database. That's basically what we're looking for. But in Unity.
We also need some more types of triggers. Triggers are the things the player walks through and something happens. it gets triggered. Hence the name.
We're looking to integrate aforementioned PlayerVars with triggers directly so that, for instance, a trigger only happens if John has experienced a certain situation or owns a certain item. Something of that description.
Translations. We're not looking to actually translate anything just yet.
But we need the groundwork for it to be there.
(I ran out of images :C)
And that's what we will do until the end of October, friends. If you want to stay up to date, click that "Watch" link. It's great..
We'll be back with more in November. Maybe earlier.