Pondering a Strategy for Battle

No build posted today.  Been spending some time getting the task list for Daleth in order, and thinking about how to tackle the framework for combat encounters (henceforth likely referred to as simply “Battles”).

The Way Things Are

A bit of background on roughly how things are implemented at the moment.  Aui is the custom UI system that all the screens and other interactive bits are built using.  This has a bunch of generic widgets, like buttons, labels, scroll bars, etc.  Within the Tako package, I have all the Tako custom widgets (for things like the agent icon buttons and the codex mantle list), as well as all the screens and popups, which themselves are just widgets.

The component which glues all of this together is the ScreenController.  ScreenController does a bunch of unique stuff.  It is the root widget in the widget family tree.  The Tako game class (Slick-derived) calls ScreenController’s update(), render() and resize() methods directly.  ScreenController also does a bunch of currently-pretty-nasty event handling such that any screen call do something like triggerEvent(widget, “screen MainMenu”) to open the main menu, or triggerEvent(widget, “popup mantleInfo <mantle Id>”).  It’s a little bit gross, but it’s functional.

ScreenController allows a single screen to be visible, but maintains a popup stack.  This means that while you’re in the Codex, for example, you can keep clicking on links that pop up more mantle info popups and it keeps something of a history as you keep hitting back.  This will require a bit of reworking in the long run, because you can theoretically get into a situation where you’re running out of memory due to so many popups being in the stack.

The actual game logic is contained in a separate widget-derived component that exists outside of this system, Campaign.  This Campaign widget is always rendered underneath the currently active screen and popup, and drives the game logic for things like the avatar traveling and triggering encounters, and also responds to events requesting mantle/party changes.

The Conundrum

This is all well and good, and everything is working quite well at the moment.  However, it does pose a bit of a strange issue now that I’m starting to look at battles.  See, the Campaign widget functions like the back-end for gameplay, and there’s another widget that functions as the front-end: the CampaignScreen widget.  All of the user interaction happens within CampaignScreen.  There are widgets in Campaign that are used for rendering encounters and parties and stuff, and their tooltip displaying is actually handled by CampaignScreen, but nothing on the world map is actually interactive.

So I’m stuck in a position where I still want to continue keeping the front-end/back-end separation in place — it actually looks great having the game render in behind the menus without the clutter of the game UI after all — but if the Battle component is going to be maintaining the queue of agent events, and BattleScreen is maintaining the graphical/interactive representation of that…  Well, it just gets even uglier, I find.  I have to end up doing a bunch of agent lookups to ensure that the visual timeline aligns with the actual timeline.  Especially when you consider that some agents may from time-to-time disappear altogether from the timeline, it’s just especially ugly.  Gross!

The Solution

Okay, so it’s really not that big of a deal.  I’ll keep a queue of battle events in Battle, which will be a bunch of elements containing agent + event (command or action) + optional ability (for active wait or normal action).  Since this queue only updates infrequently, I can make use of the “refresh” functionality I have in place with Aui — essentially I can allow Battle to trigger a ‘refresh’ event which will ultimately cause the visual timeline to repopulate.  This will also allow the BattleScreen (which will be responsible for things like selecting abilities and targeting) to update based on whose action is available.

I’m not entirely sure why this was making my head spin so much, but it doesn’t matter!  I have a plan of attack, and hopefully Tako will have some playable battles before too long.  🙂

Advertisement

Layout Improvement and Leveling Up!

Build: Gimel 25-September-2011 11:47

I revamped the Codex window, and all the other list-of-mantle windows while I was at it.  I needed to do so because I wanted the following for leveling up:

Not only did I manage to get that done, but I also (perhaps inadvertently) introduced the basic metagame.  It’s currently possible to spam the skill check in first visible encounter to award a whole bunch of experience and cap out your agents, and this will actually result in the Codex opening up too.  Now, there aren’t any flashing lights or effects or anything to tell you that you’ve unlocked new mantles, but the functionality works!

So, the last remaining tasks for Tako-Gimel are:

• Validate Daleth task breakdown.  I first did the task breakdown for the next milestone (combat encounters) at the beginning of this milestone.  I think I might have to stop doing these breakdowns a milestone ahead, judging by the amount of learning and revamping I’ve been doing while working.  This means that the next task…
• He task breakdown… is no longer needed for this milestone.  That’s “He” the Phoenician letter (according to wikipedia) rather than the pronoun.
• And a few miscellaneous development tasks that are either feature-creepy or things I don’t really need.
• Tilesheet improvements.
• Seasons.
• Trading.  (This is something that I don’t really need a ‘system’ for, since I can just whip up something specific to any given encounter.)
• Agent AI.  (This will almost certainly end up becoming its own milestone later on — giving agents personalities and having them react to the things the player does.  Or, it’ll just end up getting cut!  Dunno!)

…and then it’s on to combat encounters!  Whole new feature, should be interesting.

Class Tree

Build: Gimel 23-September-2011 12:15

Took a little bit of time tonight to toss in some utility methods for getting agent gender (the current plan is to have the gender tied to race, so you’d have both male and female races when appropriate), and to fix up the “Travel” button ingame.  It was a bit flaky before, and it feels a lot more solid now.

Aside from that, as shown in the screenshot above, I am beginning to work on the leveling system!  Here’s how leveling is going to roughly work…  After each encounter, all agents in your party (not in the squad) will receive X amount of experience, based roughly on the difficulty of the encounter.  Once an agent gets a total of, say, N experience, they gain an “Upgrade Point”.  The player can then spend that point to upgrade any one of that agent’s mantles (race, class or artifact) if that mantle has any upgrades available in its “upgrade path”.  Looking at the screenshot there, you can see that the Warrior class can upgrade into Warrior II, then Warrior III, and then finally into one of two completely different classes which haven’t yet been unlocked.  These would become visible once the agent reached Warrior III.

Each additional upgrade point for a specific agent will cost more than the last.  I expect that by doing this, and by having new agents ‘collected’ over the course of a campaign, it should hopefully space out gaining these upgrade points pretty evenly without being totally even.  It does create some interesting gameplay twists — like being able to level up an artifact quickly with a newly-acquired agent to then return to your avatar for whatever reason.

It’s My Party and I’ll Squad If I Want To

Build: Gimel 21-September-2011 08:59

After a bit of discussion, I’ve decided to handle agents in pretty much the same way as artifacts.  You essentially have an ‘inventory’ of agents that you can draw from to fill up your party.  If the party is full (currently four members), you have to remove a member first.  I also spent some time reorganizing the party frame to show the agent’s icon, but I’m not sure I like it.  Well, I do like the icon being there, but now when you open the member details panel, it’s REALLY big.  I’m considering taking the details panel out, and instead using the agent info popup for agent interactions.  That’s something I’ll tackle later during revisions, though.

Next up: leveling!  Once I get the leveling system in place, it’ll be time to move onto combat encounters.  I’m stoked!

Winning and Winning Better

Build: Gimel 17-September-2011 11:37

I have put in a system for campaign scenarios, including being able to finish a scenario.  In the example I have in place right now, there’s only a very rudimentary win/loss script set up, but it should be pretty easy to extent the system to allow for a whole range of greys versus black-and-white winning-or-losing.  The nice thing about how the demo scenario is set up is that the encounters in the world aren’t specifically hard-linked to the scenario.  This particular scenario has ‘fame’ as a measure of victory, and the encounters simply boost your fame.  This type of relationship will hopefully allow many encounters to ‘plug in’ to scenarios without too much effort.

I also have designed a leveling system that I’m hoping will work, but I’ll talk about that a little later when I have it in place.

Evil Zombies

Build: Gimel 16-September-2011 01:21

I have added traits to the mantles, and added the functionality to prevent conflicting traits from being put together during avatar creation.  Still have to do the same for ingame equipping, but I’m happy to have done a bit of Tako work tonight at all!

Refactoring, Part Two

Build: Gimel 14-September-2011 10:45

Have finished changing things over to the slightly-refactored aui, and also added in auto-scaling functionality, so as the window resizes, the game scales up or down properly.  This means that it will no longer be possible to have a UI that overflows the window (unless your window is smaller than 320×240, of course).  You can still decide whether you prefer a larger or smaller scale, and Tako will try its best to accommodate.

There are a couple more things I want to refactor before I can really get cracking again on development, but they’re not major things.  Specifically, I want to add getLeft/Top/Right/Bottom() methods to Widget, and possibly add in some static factory/builder methods for creating widgets.  I’m not so sure about that last one, though.  Will have to give it a shot and see how the code ends up looking!

Oh, and three weeks until Dark Souls!  😀

Refactoring, Part One

Build: Gimel 10-September-2011 01:09

There’s not really anything new to see in this build, but under the hood, the code is a lot cleaner.  🙂  Putting my Effective Java reading to work!

Resizing

Build: Gimel 8-September-2011 12:23

I am able to circumvent the ‘hacky boxes’ issue (mentioned here) by using a JFrame, which also allows me to have a nicely-resizable window.  However, I have a new issue now where the application is initially blank, until you either resize it larger or move it.  It will become blank again if you resize the window smaller.  I’ve been digging and am having a lot of trouble figuring out why this is the case.  Have yet to try it on another machine, though.  Maybe it’s just a problem with my video card or something.

I’ve also finished reading Effective Java, and will likely being doing a bit cleanup of Tako — most specifically of aui, which is supposed to be the go-to library for me for UI now and in the future.

Tutorial: Creating a New Project With Slick in Eclipse

Slick is a 2D library for Java written on top of LWJGL (itself written on top of OpenGL).  Eclipse is the IDE I use for developing in Java.  I love Slick for being able to get up and running quickly, but I’m fairly new to Eclipse, so setting things up has proven to be a bit of a repeated pain for me.  This tutorial will describe how I set up Eclipse for my Java projects, to serve mostly as a reference for myself when I next start a new project.

The source for this tutorial is available at Bitbucket (https://bitbucket.org/apocriva/tutorials).  Full tutorial after the break!