August Update

Hey folks!

So, doing the Dev Diary I think has been a very positive thing overall, and I’ve enjoyed writing them a lot more than I thought. Today’s update will be instead of the Dev Diary as it seems surplus to write this big one and a smaller one containing less information.

Parser

First up, the parser/director system. We’ve been looking at alternatives to expedite the process of getting those working, and have been looking at Twine. To begin with we were looking for possible programs in which to just write branching scenes, but we’ve since been looking at using Twine (and Harlowe, its markup syntax) as a kind of temporary replacement for the parser.

This would mean that we put the work we have on the parser/director aside, and use Twine to write scenes for the interim. This’ll save us a lot of time, as instead of essentially making our own language, we’d be making an importer that takes those files that Twine creates and simply pointing the variables at game data instead of data inside the Twine project. Once we’re in a more comfortable position, we can return to working on our own parser/director system.

To test it, I wrote a short scene that I’d like to include in the game a bit later once we’re ready for it (and once it’s finished). Twine has the benefit of being able to export html files that play out the story within, so you can just click this link to go read The Troubled Couple. It’s NSFW. It was pleasingly easy to use and didn’t take long to put this together. Most of the time spent on it was for the short setup phase for the player. Not something I’d call game-ready quality, but do let me know what you think. :)

As far as writing goes, it’s slightly more limiting than our Director system, but not impossible to achieve the same thing. It just takes a little more Twine-code to get it working, and there are lots of guides for working in Twine as it continues to gain popularity.

The parser/director system is kind of my baby, since it was the first system I really designed and built myself, so it’s not gone forever. But we have to look for temporary measures to get as far forward in as short a time as we can, and Twine seems like a good fit for this purpose. Plus, scenes written in Twine will continue to function once we eventually implement our own parser system, too.

Map

Crimson’s tightened up how it passes around data before we started on the battle system, so it’s a much more streamlined beast now. We also fought with Unity for a frustrating few hours trying to get it to display text well at smaller sizes without Unity mangling it into a pixelated mess, so for now we’ll simply be using a larger font to combat the blurriness we saw in the character creator demo.

Battles

We now have working random encounters, at the moment applied to every single tile. It causes our first enemy to appear, the Feral Canen. We have in place a rudimentary battle system, where an enemy can spawn, the player and enemy can hit eachother depending on speed stats, and the player can be returned to the map afterwards. Art for that character is in the works right now.

The build we’re working on is a littler further ahead. We currently have working databases with ID’s both for weapons and for moves, and are putting together the GUI in order for the player to be able to select those moves in battle. I also put together a working equation for how we’ll calculate battle damage, taking into account player stats, weapon stats, the move used, and the target’s stats, and scaling well across levels. Math has never been my strong point so I’m pretty proud I got that working.

Thanks to Crimson beating Unity to his will, we can also view a lot of this inside the editor itself. Things like which characters have which weapons equipped and which moves are attached to that weapon. This’ll make creation and debugging later a lot easier. The current task is to create a dynamic GUI element for displaying these things during battle to the player.

As I said in the last Dev Diary, we’re achingly close to the bit where all the weapon and move designs I’ve made can be put into the game, and I’m very excited for that. :3 We should have a new build with this stuff fairly soon.

Misc

I’ve been thinking about putting together either a thread, or a thread containing a public GoogleDoc, with all my current ideas for the lore and world. I’m unsure whether or not to include anything that might be spoilery though, as a lot of my thoughts have been on the main story itself. Let me know what you guys think; either way I will put something up soon for you. Perhaps over time I can turn it into a kind of Carnal Codex.

More of a side note, but a few days after I made the post about Brexit and our financial problems, my dog died (heart failure and old age). I didn’t want to mention it at the time as I didn’t want anyone thinking I was using it as emotional leverage for more funding, but it’s made it tough to focus recently so it’s worth mentioning for that reason. If you own a dog, give them pets and loves.

Lastly, thanks so much again to everyone who has supported us, and supports us now on Patreon. I can’t fully express how grateful I am. <3

Until next time!

tl;dr: Simple battle stuff done, more battle stuff and art is nearly ready, new build very soon, Benji wrote a little scene and actually did math, Benji will write out lots of lore and world stuff soon, Crimson is a programming magician.

7 Responses to “August Update”

  1. Zulcoringa says:

    What do you mean by not game-ready quality, that scene is GOLD!

  2. DSTORQUE says:

    I’m concerned about your use of Twine instead of your parser/director system. Is it really wise to use a temporary measure as the basic groundwork for everything you plan to build upon? I would think that the first thing you would want to do is establish your system that will be driving the whole game before adding more systems atop it. Are you positive that you will be able to easily interchange the Twine and parser/director systems without any problems further down the road?

    • Crimson says:

      The parser/director system does not drive the game. As a markup interpreter for a custom markup syntax, it only responds to data sent by the game. While the parser/director provides some syntax shortcuts that Harlowe (Twine’s markup language) doesn’t currently offer, the trade-off is that Twine gives us a functional and well-tested tool for writing and testing interactive story content right now.

      Until the game itself is complete, I’m unable to prioritize writing interactive story authoring tools for Benji. Twine has proven to be an adequate tool in the interim. It allows Benji the ability to write and test game content in an immediate feedback loop without having to constantly rebundle his changes in Unity.

      The impact of interchanging our custom syntax and Harlowe is minimal. If a text asset is written in Harlowe, it goes through the Harlowe interpreter. If it’s written in our custom syntax, it goes through the parser/director. Neither system can directly manipulate game data. They each have a temporary variable space while interpreting. Both systems output text content and publish story choices back to the game’s logic core using the same API.

      If Twine turns out to be sufficient on its own for authoring all of our interactive story content, we could save ourselves a lot of time by dropping the parser/director in favor of just interpreting Harlowe. Harlowe is in active development and is only a couple features away from being a more expressive markup language than our original custom solution. Harlowe also has the benefit of being used and tested by many people. Our custom solution has never been used by anyone except Benji.

      If Harlowe doesn’t work out in the long run, then we slowly phase it out in favor of our custom solution.

      I hope this addresses the concerns raised, but I can continue to answer questions if any remain.

      • Farlun says:

        So that means Twine can read *everything* that the parser was supposed to? Are there any actual in-game limitations when compared to the custom system?

        • Crimson says:

          Twine is just an editing and publishing tool. However, Harlowe, the markup language used by Twine 2, is capable of producing anything that our custom solution could have produced. As stated before, interpreters for both markup languages receive the same data and produce the same output. In-game, there is no notable difference between the two.

  3. The use of twine to make that interactive story is awesome! makes me want to use it some (looking up tutorials) downside is i can’t put images in it in a conventional way like drag the image from your folder and onto the passage in twine, if you have anyway to put pictures into it then i be happy to hear

    and as for the codex that your thinking of i think that be awesome too. it would hold all the info of the worlds lore and that is always good to have. you going to have category’s for each thing for
    eg character, items, world, magic, place etc?

    and when your on a page about a race some words thats related to them would be a link to that certain page example
    “the rabbits of south burrow recently had a uncivil racial tensions with the Fox folk of the Bails”
    the fax folk would be a link to their race page and there be a back step thing so you can go back to the previous page yu were on

Leave a Reply

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

Time limit is exhausted. Please reload CAPTCHA.

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