Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1391886 Posts in 66873 Topics- by 59646 Members - Latest Member: BMB

May 11, 2021, 08:59:19 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsForesight Fight - A puzzle game with tactical RPG combat
Pages: 1 2 [3]
Print
Author Topic: Foresight Fight - A puzzle game with tactical RPG combat  (Read 6389 times)
bayersglassey
Level 0
**



View Profile
« Reply #40 on: December 11, 2020, 10:13:18 PM »

Wow. :O
This seems like a game designed for programmers!

The game is like a pure function: Tuple<Encounter, Party, Tactics> -> Stream<EncounterState>
You have a party, you choose an encounter, you choose your tactics, then play them to see the resulting stream of states. If the stream terminates, the final state can be inspected to see if you won/lost/drawed.

I do like the graphics and sound, but I can only imagine playing this at a REPL.
Something like:


ffight run encounters/1.json party.json tactics.json >results.json


And aside from "run", ffight takes other commands for listing enemies and party members, listing available actions for a given party member, etc.

And for instance tactics.json is something like:
Code:
{
    "party": [
        {
            "type": "warrior",
            "equip": [
                "head": "item.5",
                "left_hand": "item.8"
            ],
            "actions": [
                {
                    "type": "attack",
                    "with": "left_hand",
                    "target": "enemy.0"
                },
                {
                    "type": "attack",
                    "target": "enemy.0"
                },
                {
                    "type": "use",
                    "target": "item.3"
                }
            ]
        }
    ]
}

*Mind drifts away...*
Logged
ThemsAllTook
Global Moderator
Level 10
******



View Profile WWW
« Reply #41 on: December 12, 2020, 06:40:16 AM »

Yup, that JSON is preeeeetty close to how the game represents its internal state. Including a command line interface like that isn't something I had thought of before, but it's a super interesting idea! I'll definitely make a note of that and see if it would make sense to do. Like, it fits perfectly, and I'd love to be able use my work to encourage learning about this way of thinking.

Also, whoops, I didn't get around to writing a post for this week...

The scenario editor grind has steadily continued. I decided to take on the most complicated part of it to get it out of the way: The formula editor.



Every aspect of a formula can be fully edited now inside the game, and it's actually a lot of fun to play around with it. I've only wired up the scenario editor screen enough for the two formulas that determine champion resource capacity and change per turn to be edited, but the formula editor code is finished and will work the same way for everything else in the formula once they become accessible from the editor screen. I have a lot of things to think about as far as user friendliness and documentation, but it's more than good enough for my purposes, and actually feels a bit friendlier to use than editing the JSON directly. As partial as I am to text editors, it's a lot of syntax to remember, and not having to look up bits of it each time I want to make an edit lets me focus entirely on the math.

Now that the formula editor is done, I'm back to wiring up the rest of the editor categories. Champions can now be fully edited:



The remaining editor screen work is small enough that it's plausible I'll have it all there by my next update. Going to push through and see if I can make this happen.



Logged

ThemsAllTook
Global Moderator
Level 10
******



View Profile WWW
« Reply #42 on: December 30, 2020, 08:58:26 PM »

Editor progress. Equipment can now be fully edited, and I finally got around to implementing a save system so that changes can be written to disk.



After checking this off my list, I wanted to move swiftly through all of the other categories of data I can edit. However, things took a turn when I started working on an encounter editor... I'd been accumulating a bunch of notes on aspects of my data structure that needed reworking, and this seemed like the perfect time to do it. I ended up making some pretty sweeping changes that took up most of my time since last update.

Gameplay used to take place in either an "encounter", or a "puzzle". Both of these contained a battlefield with enemies placed on it and actions assigned to them, and rewards potentially earned for clearing, with the only difference being that a "puzzle" came with its own fixed inventory instead of using the player's accumulated collection over the course of the scenario. There were also "challenges", which were alternate starting and unlock conditions for the entire scenario, and I always felt they were kind of half-baked.

I changed all this so that there are now "battles", which are just battlefield and enemy layouts. A puzzle now simply references a battle and has its inventory attached. "Encounter" changed meaning somewhat, and now refers to a location on the map which can reference either a battle or a puzzle, and lists rewards to completing its attached content. This allows puzzles to potentially reuse battle layouts with different starting conditions without having to create additional copies of the data. Challenges are now called "campaigns", and are non-optional - instead of there being one main starting inventory with optional alternates, the main starting conditions are now just the first campaign in the scenario, and alternate ones are on equal footing with their own starting conditions.

I asserted to myself near the beginning of this project that I wanted to remain open to reinventing parts of it if they needed it, no matter how deep in I was. I think this helps me keep poor decisions from taking permanent root, and lets me make large refactors like this the with confidence that I'm improving the project rather than breaking it. It can't stay malleable forever, but it can definitely stay malleable for a while longer yet.



Logged

ThemsAllTook
Global Moderator
Level 10
******



View Profile WWW
« Reply #43 on: January 18, 2021, 05:12:24 PM »

My editor work is leading me to some unexpected new insights. It's forcing me to make real decisions about a lot of half-baked ideas that have been swirling around in my head. Something I'd been thinking about for a while was the idea of having multi-battle gauntlets where resources would carry over between battles, thereby making it meaningful to optimize earlier battles to set up winnable conditions for later ones. In the previous design, all resources would refill between each individual battle.

I feel like this idea has so much potential that it might end up being the primary way of playing the final game. It also helped me solve a problem that had been bugging me about how my game data is organized. I ended up once again redefining what "encounter" means. What I'd previously called a "puzzle" (a battle with fixed starting conditions) has now been rolled into the concept of an encounter, alongside gauntlets. Any encounter now has a list of one or more battles, with an optional inventory to use as the starting condition.

This allows four distinct flavors of gameplay:
  • Standalone campaign battles, where you can use all of your earned equipment and start at full strength.
  • Standalone puzzle battles, where equipment earned over the course of the campaign is unavailable, and there's just one unchanging set of starting equipment.
  • Battle gauntlets, where you bring your earned equipment to a series of fights, with non-replenishing resources.
  • Puzzle gauntlets, where you have fixed starting conditions for the first battle, and have to make them last for an entire series of fights.

In terms of the raw work to get the entire editor put together, I think I'm in the back half of it, though there's still a long way to go. I now have a fully-featured battlefield editor that I'm pretty happy with:





Logged

ThemsAllTook
Global Moderator
Level 10
******



View Profile WWW
« Reply #44 on: February 08, 2021, 05:06:48 PM »

So, you know this scenario editor I've been working on for the last several months? It's pretty much done now. With only a couple of small exceptions, every piece of data in a scenario can now be fully edited inside the game UI. The editor is definitely in "rough first draft" status, but it will get polished up a lot more as I use it to build puzzles for the game.





The code for the scenario editor involves a whole lot of nearly-identical code for invoking all the UI for editing similar-but-not-quite-the-same data structures, each in their own unique way. In order to get the second half of the editor finished so much more quickly than the first half, I made an aggressive effort to reduce code duplication, so that I'd only have to type out the unique portions of each section of the editor. This was a combination of a deeper class hierarchy so that common behavior could be inherited where appropriate, and some heavy C preprecessor macro usage where appropriate. Macros come with some tradeoffs; debugging becomes a bit harder and readability suffers a bit, but the benefits in consistency and implementation speed have been worth it.

I'm bumping the progress indicator on this thread up to 50%, because I feel like this was a major milestone. Game is getting there!



Logged

ThemsAllTook
Global Moderator
Level 10
******



View Profile WWW
« Reply #45 on: March 01, 2021, 05:08:25 PM »

Since the last update, I've been spending my time polishing off the rough edges in my hastily put-together scenario editor. My short-term goal is be able to comfortably use it for all of my work building puzzles without having to leave the application to write JSON in a text editor or anything like that.

On disk, scenario data in Foresight Fight used to consist of three files: A JSON file that lays out all of the game mechanics and encounters; a PNG containing a texture atlas of scenario-specific graphics; and another JSON file specifying regions within the texture atlas of each individual graphic along with its name. I didn't like having three files per scenario, and I wanted to be able to also include an arbitrary number of custom sound files, so I took the time to create a package format that bundles everything together into a single physical file. Using something like a zip or tar file would have been OK, but since I wanted something extremely lightweight and prefer to keep third-party dependencies to the absolute minimum, creating a custom format made more sense. Each package has a header listing file names, types, sizes, and offsets in the package, and then a blob of binary data at the end with all of the actual file contents in it. Easy to use, minimal overhead, does exactly what I want.

Each scenario's texture atlas used to be packed at compile time by a command-line utility I wrote, but in order to allow importing of custom graphics in the editor, I needed to be able to do it at runtime. I extracted the relevant code from the build-time texture packer utility into a static library that the game now uses to repack texture atlases when modified. There was a lot of UI work to make this process feel good, so that was where most of my time went these last three weeks. There are still a few bugs to track down, but I can now import, export, and manage images inside the editor in a pretty satisfactory manner:



I might end up implementing a rudimentary image editor for small tweaks someday, so that I wouldn't have to go through an export/edit in GIMP/import cycle for everything. For now, image import will do the job OK.

If you want to see me doing some serious work in my own scenario editor for the first time, that's the main activity of this week's devlog video:



Logged

Alain
Level 4
****



View Profile WWW
« Reply #46 on: March 02, 2021, 09:49:01 AM »

Man, this is a really elaborate editor, I envy you for your patience! I have a tendency to dive into creating content too soon instead of building proper systems Wink
Logged

ThemsAllTook
Global Moderator
Level 10
******



View Profile WWW
« Reply #47 on: March 02, 2021, 10:38:48 AM »

Heh, I think I have the opposite problem - I enjoy building tools so much that it's sometimes hard to pull myself out of that loop and actually make something real with them. My hope is that making the process of building puzzles as frictionless as I can will help me get into a mindspace where I can do a whole bunch of puzzle design without feeling the need to interrupt it and tweak the technical side of things endlessly. If this also turns into a tool that other people will want to use to build levels, then that's a nice bonus!
Logged

Alain
Level 4
****



View Profile WWW
« Reply #48 on: March 02, 2021, 10:44:39 AM »

If this also turns into a tool that other people will want to use to build levels, then that's a nice bonus!

That's what I thought, too. It seems like your tools could easily be used by enthusiastic players.
Logged

ThemsAllTook
Global Moderator
Level 10
******



View Profile WWW
« Reply #49 on: March 22, 2021, 03:03:10 PM »

I keep to-do lists for a lot of things, and something I've noticed is that when I'm actively working on them, they have a tendency to grow a lot faster than they shrink. These last 3 weeks were one of those rare times when this game's to-do list actually got smaller. In addition to putting finishing touches on the scenario editor, I tackled three outstanding design issues with core game mechanics:

1. Previously, equippable items were split into three categories: Gear, items, and spells. Gear could only grant stat bonuses. Items were essentially spell invocations that could be used once each per battle. Spells had to be assigned to the party member who would be using them, and would grant a reusable ability that had some resource cost. Champions also had innate abilities, which were essentially spells that didn't need to be equipped.

It kept bothering me that abilities, items, and spells were almost the exact same thing. I came up with a new system that both simplifies everything and gives me some more flexibility. Spells and items no longer exist, and equipment can grant abilities usable in battle, potentially with a maximum number of uses. This covers all of the previous use cases, and additionally allows me to do things like have a potion that can be used twice before being depleted, or a weapon that can be swung with a different range while equipped, or consumable items that continue granting stat bonuses even after they're used up. More design space!

2. In addition to granting stat bonuses, a piece of equipment can require certain minumum stat values in order to be equipped. Implementing this required me to solve an interesting constraint problem, since one piece of equipment could grant the necessary stats to equip a different one, or potentially come with a penalty that would make something else no longer legal to equip. I've posted about how I solved it here: https://forums.tigsource.com/index.php?topic=4103.msg1436749#msg1436749

3. In combat situations with multiple enemies behind each other, I needed a way for farther back ones to be reachable with melee weapons after the front ones had been defeated. My previous attempt at solving this was a weird system where the tiles making up the front of the battlefield would disappear when they became unoccupied, collapsing the space and shifting everything toward the opposing team so it would be in reach. This didn't make a whole lot of sense, and restricted my design space around the idea of reviving downed champions, since the space they previously occupied might not exist anymore. I worked out a more reasonable system where empty spaces at the front of either team's battlefield are ignored for weapon range calculations. The tiles remain where they are, and everyone can reach each other when appropriate. Much better!



Logged

ThemsAllTook
Global Moderator
Level 10
******



View Profile WWW
« Reply #50 on: April 16, 2021, 07:44:12 AM »

A few posts ago, I mentioned the concept of gauntlets: A sequence of battles where resources aren't restored between each one, so that optimizations on earlier battles can have cascading effects on what's available for later ones. It was just a concept then, but I've been working on the implementation, and finding that there's a bit more to it than I expected.

To recap: An encounter is a single space on the map, which might give equipment rewards and/or unlock additional encounters when solved. A battle is a single arrangement within an encounter where a formation of enemies is placed. All battles within an encounter must be solved for the encounter to give its rewards. When an encounter has more than one battle, each one must be solved in order, and each battle following the first will carry over the state of player characters and resources at the end of the previous battle. Player resources always start full for the first battle in an encounter.

I first needed to define exactly what state is carried over between battles, and what can be changed per battle setup. Metaphorically, the battles in an encounter gauntlet happen one after the other with no time in between, so I thought it would make sense to lock each player champion's equipment once it was assigned in a battle. No time in between to change armor or anything. If you lose health, there's no time to heal back up. If you get a status effect, there's no time for it to wear off. So, equipment gets locked once assigned, resource levels carry over, and status effects start on the next battle as they had been when the previous one ended.

What can be changed every battle is formation and battle actions. Being able to change formation means that if you have a lot of champions available to be placed on the battlefield, you could potentially swap out one who's almost dead for another one who still has all of their health. The one who gets swapped out still has all of their equipment on, so the fresh one will have to pull from the pool of whatever else is available. If someone wasn't placed in a prior battle, their equipment doesn't get locked, so you always have the opportunity to set them up however you like in the first battle they appear in.

Each gauntlet has its own branching timeline, since the state of each battle depends on how the previous one ended, and it might be necessary to try out different endings to find a viable route for what comes next. What I'm working on right now is a UI for switching timelines, but the necessary data is already stored to make this possible. Each battle solution gets a unique ID, as well as the ID of the previous battle in the gauntlet where applicable, so I can walk upward in the solution graph to compute the state at any given branch. This all works, and survives scenario changes in the editor if progress is saved for a scenario still being modified - since it's pretty inexpensive to simulate each battle's outcome to derive the resulting state, I only need to store the inputs of equipment, formation, and battle actions. Editor changes could invalidate previously-achieved outcomes, and I don't yet have a way to mark saved solutions as no longer valid, but it should be a pretty simple extension of the current system to do so.

Since I needed to make a bunch of changes to the data format of saved solutions, it made sense to go ahead and implement another thing on my to-do list, which was to allow for multiple player profiles. There's now a single file per player which stores all progress and solution data in one container. If you wanted to have the experience of unlocking each encounter in a scenario again without erasing your previous progress, you could make a new player profile to have a separate set of save data. Player profiles can be exported for backup and reimported. The file is written atomically on the platforms where that's possible (thanks to this article) to reduce the likelihood of losing all progress due to a power failure or something while saving.

When I went to record the video below, I found that I don't really have a good testbed for gauntlets that shows what's interesting about them. After I've finished the UI for changing battle timelines, I'm planning to build a scenario specifically for this. Gauntlets deepen the puzzle potential of my game significantly, so it'd be good to have something that can demonstrate that. Working on it!



Logged

ThemsAllTook
Global Moderator
Level 10
******



View Profile WWW
« Reply #51 on: May 04, 2021, 07:50:12 AM »

I decided to take the last 3 weeks to focus on overall look and feel, doing an iterative process where I'd take the thing that bothered me most aesthetically, fix it, look for the next thing that bothered me, and repeat. Some of the changes I made:

Character sprites that were drawn from the front are now side-on, and I added a black border to make them stand out from the background a bit better:


I replaced a bunch of hastily-assigned placeholder graphics and effects for the scenario I'm building specifically for the purpose of being able to show something during development without spoiling anything in the main game campaign:


I created a new transition effect between the map screen and the encounter setup screen, which shows the relationship between the small preview of a battle and the way it looks during setup:


My goal was to build some puzzles to show off what's interesting about the gauntlet system, but it turned out that the mess of aesthetics I had left behind was bothering me too much to feel like it made sense to focus on puzzle design. Now that everything is smoother and more built out graphically, puzzles will be able to show a whole lot better. I know there are some core game mechanics that still need to change, so my near-term focus is going to be iterating on puzzle design and discovering what tweaks I still need to make for my mechanics to really shine. It took me a long time to get to this point, but I think I'm finally where I need to be for it. Should be exciting!



Logged

Alain
Level 4
****



View Profile WWW
« Reply #52 on: May 05, 2021, 10:29:53 PM »

Thanks for the update! Nice improvements, I'm getting a Windows 3.1 vibe from the sprites. And I think the transation between map and setup screen looks great.
Logged

Pages: 1 2 [3]
Print
Jump to:  

Theme orange-lt created by panic