Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags

Axu

An open-world graphical roguelike. Still in development. · By Cynapse

Coordinate References

A topic by flosincapite created Sep 28, 2017 Views: 432 Replies: 5
Viewing posts 1 to 4

Hey, all.

I'm working on a quest line involving the mutant villages, but I've run into a major issue: while it's possible to reference towns ("Coordinate": "Closest Town") in quests, it doesn't seem to be possible to reference mutant villages. Similarly, since static locations (cathedral, Ensis headquarters, Kin hideout, etc.) are hard-coded and not generated from the .json data, it's not possible to add new locations. Has anyone found ways to work around these restrictions?

Unfortunately, that part of the world generation is hard-coded at this time. I'll make a reference for both the closest and random mutant village if that helps? What other ways can I make it easier on you guys?

Awesome! That would help :).

I've thought of other things that might make quest development nice. The biggest one--and I admit it's a very tall order--would be some sort of control-flow primitives.  This might look like

"Events" : [
    {
        "If Block" :  {
            "Condition" :  {
                "Predicate" : "HasItem",
                "Arguments" : ["Player" , "poem" ]
            },
            "True Event" : ...,  # can be any event, including other if blocks
            "False Event" : ...  # likewise
    }
]

My current solution for this (which I still haven't tested) involves spawning multiple NPCs, having each give the player a quest with different conditions, and then despawning the other NPCs (if that's possible). This will leave the incomplete quests hanging around, but that's fine.

Less drastic, but still very helpful, would be some documentation about the semantics of the various JSON objects. Even just BNF grammars, e.g.

<QUEST> ::= <QNAME>, <QID>, <QTYPE>, <QGIVER>, ..., (optional) <QEND_DIALOGUE>, ...
<QNAME> ::= "Name" : /.*/
<QID> ::= "ID" : <REFERENCE>
...
<REFERENCE> ::= /[a-zA-Z0-9]+/
...
<FLAG> ::= "Flag" : ( "Can_Enter_Power_Plant" | "Can_Enter_Ensis" | "Break_Prisoner_Inhibitor" | ... )

Again, I'm asking for a lot--completely understandable if this stuff is infeasible.

I'll fix up some bugs and include that change in the next hotfix hopefully tomorrow. 

Yeah, thats quite a tall order, and something I was hoping to port over to Lua or some other runtime scripting language. I'll see what I can do though, even if it's not as flexible as you propose. It would be nice to create wholly new functions and logic statements without recompiling. 

As for the documentation, that I can do. I had that in older versions, But with sudden changes, it was quite the task to keep it updated. Now that things are more solid, I could certainly add that again. One of the changes I've been meaning to add was to swap the enums of quest flags, locations, etc to string values read from the json file itself. 

Oohhh, yeah, +1 to enums over/in addition to/as aliases for ints. Would that be viable for sprite numbers, tile references, etc., too?

Also, no pressure, but I'm currently an idle-handed programmer. Might be able to pitch in if you're looking for an extra set of hands.

I'm not sure how it'll work at this point. It's purely hypothetical while I focus on fixing bugs and adding features to the main game. Making new functionality for say, a progress flag, would require scripting to do anything outside what's already hard-coded. Either that, or the if block json objects to check if a certain one is present at any given step. 

It could be possible to also set function references that are called at various events. So if a weapon has a OnHit event, it will call that function with a set of parameters in the data file. That would require a little bit of busywork on my part, but could definitely add depth and flexibility. 

Sorry for my rambling! I'm not looking for an extra set of hands, but I would love to hear about systems to ease the modding community.