Weekly Wrap-up #32

This has been a very interesting week. After some consideration I decided that the sheer amount of configurations required to create the actual “game” is quite massive. Although typically I’m used to them since I’ve been staring at them a long time, my future design team had commented that it is quite overwhelming.

Thus, this week I dived heavily into proof of concept and prototyping of a designer tool that will allow users to create various parts of the game directly through an interface instead of staring at JSON files all day.

The prototype is going well although I’ve realized this week just how much data there actually is required and placing it all into a visual aspect is proving to be challenging. I believe I’m going to need a couple more weeks before it will become usable enough (and trustworthy) to start building the actual game parts from.

Although this will be a rather long sidetrack, I believe in the long term it will be work the effort as it should save a substantial amount of time during game content creation.

There have been too many changes to the code for the designer right now to both putting things down into list form, but hopefully by next week I’ll have it a bit more stable and can start listing feature additions as they come in.

For now though, here’s a quick peek at the very, very rough prototype showing a basic decision tree data reading:

DesignerPrototype

Introducing Cut-Scene’s !
Weekly Wrap-up #33

Comments

  1. Sorry Tony, for some reason I never saw this post. Better late than never?

    To quickly answer though, there is also a set of “events” running in the background that the decision tree’s can query to determine the current “state of the game”. So for example, should you talk to someone, we can set an event flag to say that we’ve talked to them, and then the decision tree knows next time it comes across that node, that it no longer need to consider that section.

    The events will typically “drive” the game itself story wise, while the decision tree’s will be more focused on smaller area’s such as a particular map (allowing certain things to happen in certain places based upon the event states).

    On the flip side, we can also use the same tree’s to check up on the state of the player themselves. For example, if they recently finished a battle, didn’t heal up, then wander into town to talk to an NPC, that NPC could then acknowledge that fact and then perhaps behave differently (like a vendor giving you mercy and give you a deal on healing potions)

    The plan is to let these tree’s allow things to be slightly less “static” feeling by giving different reactions to different things. All in theory at this point, I think it should work out like I’m hoping.

  2. By decision tree, you’re talking about implementing the AI, correct? If so, what is preventing the exact same actions from taking place during game play every time a similar scenario happens?

Leave a Reply

Your email address will not be published / Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.