Development Update!

I've taken a new approach to the game development I've been working on.  I'm building core gameplay prototypes to make sure the game is fun before I actually design and plan more than that.  I've been doing the opposite so far, and it hasn't really worked; I get huge designs (for not high difficulty games in terms of development, just a large quantity to work on overall) and then find out I'm heading in a direction I don't like.

So this should speed up the failure cycle - I try out some core mechanic, tweak it, mess with it, and move on.  Eventually I'll find something that inspires and fuels me, and then I'll design around it.

Other than that, I'm using the kivy app framework at work to make an app for the sales team to use internally.  We need a lot of information in a reliable, consistent form from our customers, so it's (mostly) a simple thing to develop, difficult to design.

That's pretty much it!  The story world of Guiding Iron is still waiting to be put into a form worthy of its quality and depth.

Game Design Direction

As I'm nearing the completion of the collision and interaction structure that's not related to battle, I'm starting to realize that I still don't have much gameplay etched in stone yet.  I'm not sure if it's just that I want to keep my options open or what it might be, but I'm still not sure what I'm doing with this game.  Is it just a normal hack n slash with my own little tweaks and story world?  Is it a turn-based jrpg that does little new?  What will all the items do?  What will be in the maps that the player explores, what gameplay functionality will be and what won't be?

It's easy for me to see how to implement the majority of the standard SNES era jrpg.  Easy to implement the majority of what RPG Maker does and build a framework for such an audience.  But is that my target?

I think it's time for some gameplay soul-searching before I go much farther.  For once, nothing is in my way, but I'm not sure which way to go, on a number of things in the game.  It could be anything.

It could be anything I want.  What do I want?

Revision

Starting to separate responsibilities of the Game Scene into their own methods.  Nothing much yet.  Cleaned up some other stuff in New Game.

New Game Method

Figured this part out today.  Made a solid method for creating a new game file for the player, and also made the menu for Load Game to find and list all the save files in a friendly manner.

It's probably not the most efficient, but I'm happy with it for now.

Status

just wrapping up two hours of working on the game, revamping a lot of my implementation for the map and db first.  The first test npc, Bob Johnson, is in my starting test map, ready to be loaded up and start acting like an npc (so I have test data in place).  Next will be confirming I have the new save file and load save file code working, and making an official create_seed_db method on the game object (which grabs all the map files and their objects and the objects' properties and throws everything into a "seed db" to start new games from).

After that will be working on updating all the db objects for the current map when the current map is unloaded.  Shouldn't be difficult, just time consuming.

Once that's done, NPC behavior and the start of the battle testing.  The game has been switched to a strategic hack n slash instead of the pseudo turn based thing I was going for.  hack n slash should be easier, since I have the cymunk library backing me up in the cocos2d game library's collision.

until tomorrow or whenever I feel like updating again!  

NPC Editor

In the last week I recently made a lot of progress on the npc editor!  

Now I'm going through the hard part, which is after someone adds an action to an action_set and then changing that action's type (from clicking on a dropdown that adds the appropriate buttons and boxes for that action type).

The next step after I get all the UI behavior down is making each interaction modify the xml string behind the scenes, then making the decision of whether or not this is just an xml generator to copy paste from, or something that allows you to save the xml directly to the npc's properties in the sqlite db (select a map name and then list all npc's in a dropdown, that sort of thing).  Of course, if db manipulation occurs, syncing object properties from the tmx file created in Tiled comes into question - I might just make an option to directly insert xml into the tmx files themselves...I dunno, we'll see.  The important part is easy xml generation and modification (being able to paste a given xml string into an input box, hit load and interact with it).

I have different widgets outlined in different colors, and the layout isn't finalized yet either.  

NPC Scripting

I've been working less on the game than I would like lately - well, I should say that I've been coding on the game less than I'd like.  The work amount has remained the same, if not actually increased since the last post.

NPC scripting has been my primary focus, as it has a lot of definition for the rest of the project.  It took me a long while to decide on a structure for the NPC scripting (and actions scripting in general in the game for other things, like doors, chests, etc - they all follow this structure under the hood), but I finally went with XML as a formal language for it.  I was juggling around the idea of JSON, and my own weird markup, but then I was finding myself trying to work around nesting things, duplicate things, which XML already handles without getting really ugly and hard to follow syntactically.

So here's an example K-Mart greeter NPC script, I hope it speaks for itself and shows some of the structure I've put into the game.

<npc display_name="Bob Johnson" id_name="bobJohnson">
    <action_set order="1" flag_required="-insulted_greeter, -impressed_greeter">
        <action order="1" type="talk" text="Welcome to K-Mart!"/>
        <action order="2" type="choice" text="Can I help you with anything?">
            <choice order="1" text="Go away!">
                <action order="1" type="talk" text="Well!"/>
                <action order="2" type="give_flag" flag="insulted_greeter"/>
                <action order="3" type="set_animation" animation="upset" target="bobJohnson"/>
            </choice>
            <choice order="2" text="Howdy!  You're an awesome greeter!">
                <action order="1" type="talk" text="You're an awesome customer!"/>
                <action order="2" type="give_flag" flag="impressed_greeter"/>
                <action order="3" type="set_animation" animation="dance" target="bobJohnson"/>
            </choice>
        </action>
    </action_set>
    <action_set order="2" flag_required="insulted_greeter" item_required="" equipped_required="">
        <action order="1" type="talk" text="I hope you have a nice dea- I mean day!"/>
    </action_set>
    <action_set order="3" flag_required="impressed_greeter">
        <action order="1" type="talk" text="You complete me!"/>
    </action_set>
</npc>

So the game will check to see if the NPC bobJohnson should even be loaded before all of this (maybe he won't show up until the last greeter got fired by one of your devious quests) but it also has requirement checks available for each set of actions as well.  Sometimes you might want an NPC to only say something to you about a quest if you're a particular character, or have a particular item, or have already talked to this other NPC about this other thing, or have this item equipped...etc.  So the action_sets are where the NPC parsing checks to see if they should do the nested actions in that action_set or not, or move on.  

I also put in an order field, not only for actions nested in the action_sets, but for the action_sets as well.  There are probably times that we're going to want one or more sets of actions to happen, and probably in a chronological sequence as well.  If the required flags weren't set for any of the action_sets in the example above, then the NPC would do all three of them:

NPC: Welcome to K-Mart!

NPC: Can I help you with anything?

1: Go away!

2: Howdy!  You're an awesome greeter!

(player would pick a choice, and the NPC would do the subsequent actions of course)

NPC: I hope you have a nice dea- I mean day!

NPC: You complete me!

And without any requirement checks in place, the same things would happen every time.  So, the person making the content would have to be diligent in their playtesting for each scenario they put in place.

Any thoughts?  I'm making a Kivy app right now to generate this xml from a nice interface/editor for the person that would make the content, and they'll copy paste that xml string into the script property of the npc from the Tiled editor.