After fleshing out the design document with all the new ideas, it was time to start looking into coding. My first port of call was the ToME engine as it had a promising glimpse of a realtime roguelike example module. Unfortunately the module didn't work out of the box, but finally a forum post cleared up the issue.
Spent a couple of hours setting up the dev environment and compiling the ToME source code, only to find out that the vast majority (if not all) of the module can be handled exclusively by the LUA module documents. First impressions of the system are great as it was pretty easy plugging in a bit of code from the ToME module and getting it working. I did have some issues trying to debug certain errors, but once I realised all output was going to the log file and not to the console, it made it a lot more straightforward to see what needed to be imported to get a certain piece of code working.
The development path is pretty much set for either the full game or along way into the prototyping phase with the wealth of extras that T-engine4 gives me.
Projected development:
- Recompile T-engine - Done, although not needed
- Set up a new module based off the realtime example - Done. 30 mins
- Bring in new entities that are on the player's side - Done. 4h. Pinched the summoning code. Bit messy as it used the party system that was non-existent in the example module. Lots of new code brought in that may or may not help.
- Bring in the party system - Done. 2h. After revisiting the ToME module it seems like the party system might work well for flipping control between the mercs on your side. I'm not sure whether I'll need the party display though.
- Have vision from all minions. 3h. 80%. Worked in the first 1/2 hr, but now it seems inconsistent. Hopefully it's only an incorrect assumption about the caching, but I've seen enough to know that it's definitely possible.
- Spawn in a hero and move it toward the player. Hopefully the minions are able to react and fend off the hero. Will need to open up state-based AI transitions.
- AI code to move hero toward arbitrary location.
- AI code to make hero explore.
- Build governor AI to swap between AI states depending on priorities.
- AI code to make hero retreat.
- Allow minions to retreat to arbitrary point
- Create a digging AI task for minions.
- Allow player to influence minion priorities.
- Build power system for player
- Tidy up minion influence interface to make it viable for realtime play. Goto X, stop, Fight, Flee, dig, transport.
- Create standard dungeon layout with initial home stone placement and initial Gemkeeper minion.
- Limit movement and appearance of player to home stone.
- Build Gem Detection spell
- Build Gem Linking spell
- Build Vision spell
- Build Communication spell
- Build Exert control spell (interface onto merc AI priorities?)
- Create 10-20 mercs and test.
- Build Merc selection interface
- Integrate merc happiness system into AI priorities
- Designation of ownership
- Designation of rooms (vault / prison / throneroom / retreats)
- Collect hourly payments from vault
- Design village raids
- Design rumour system
- Design village (?). allow swapping of interfaces to see village raids
- Design notoriety boards
- Design merchant
- Design Black market
- Link notoriety to power gain.
- Create more heroes / Mercs and play-balance notoriety.
- Release version 0.1
Monday, July 11, 2011
RSS