next »

[ThemsAllTook]

Choose an encounter. Equip your champions. Make a battle plan. Test it out. Iterate. Achieve victory. Use the spoils of victory to win the next encounter.



Foresight Fight is a true complete information game. Every encounter shows the full stats, equipment, and behavior of the enemy team. There are no random numbers. There are no moment to moment decisions. There's no way to get stuck. There's no way to grind. The battle plan you formulate for each encounter entirely determines your success or failure.

If an encounter is insurmountable, you may need to choose a different one and earn more equipment or champions before taking it on. Finding a viable route through the encounter list is part of the puzzle. Once a reward is earned from an encounter, you keep it forever. Health, energy, and consumable items are fully replenished after every battle.

I started work on this project in late 2018, and I've been steadily chipping away at it every day since then. It's been entirely a solo effort - everything that's gone into the game is my own original work. Realistically, it's still pretty far from being finished, and I'm not close enough to give any estimate. It'll be done when it's done. I'll be posting regular updates here, both in text and video format.

[QOG]

This is a really interesting concept, I'm curious to see how it scales with more fighters on each side.

Are you envisioning players planning out the whole combat and then just watching it play out or going through step-by-step reactively?

[ThemsAllTook]

Thanks! I'll try and demo some larger encounters soon.

I figure combat planning will be a heavily iterative process. Although all of the numbers and formulas are fully visible, it's probably going to be quicker to make a guess at a party configuration, and just play out the battle to see what happens and adjust from there, rather than calculating it all out up front. There isn't a way to make any changes mid-combat, so you'll be coming back to the encounter setup screen each time you want to try something different - the actual battle screen is mostly a way to inspect your attempted solution and diagnose any problems with it. All of the decisions are made during setup.

[ThemsAllTook]

I'm going to try to do these weekly and see how it works out...

Targeting is an aspect of my game design that I've always felt was a little bit shaky. In battles with multiple champions on each team, the way it works right now is that only the frontmost champion on the opposing team can be specifically targeted. The only way to hit the ones farther back is with spells that target the entire opposing team all at once. This isn't necessarily wrong from a puzzle design perspective, but it seemed a little bit weird.

While I was occupied with yard work and my mind was free to wander, an idea came to me for something better. I now have a partially-implemented system where each champion is assigned to a row on the battlefield, so you could have a formation of, say, three warriors next to each other up front, and two mages behind them, out of reach of melee weapons. Each attacking ability would have a range parameter, so that maybe a bow and arrow user could hit the mages, but a sword user would only be able to target one of the warriors up front. Once all champions in a particular row are defeated, that team loses ground, and the rows shift forward by one so that melee attackers can reach the ones that were previously farther back.



This is a major design change, and will necessitate redoing all of the puzzles I've constructed so far, but I think it's worth it. A lot of interesting possibilities will be opened up by this, particularly if I also add an ability that allows a champion to change their position during battle. There's a lot of work to do to make this all happen, but I'm pretty sure it's the direction I'm going to go. Best to get things like this done now before I've gone too deep in constructing the game's main scenario.

Since this will invalidate all of my current test puzzles, I'm playing through all of them as they are today in this week's video:

[ThemsAllTook]

Let's talk about graphics technology and visual style.

Early on in this project, I knew how I wanted the core game mechanics to work, but I didn't have anything in mind for how to make it look. I put some really basic stuff on screen just to let me interact with the systems. Here's what the UI looked like in the first build I ever showed anyone:



For comparison, here's how the same situation looks in the current build:



(remind me to edit in another version of this once the UI is finalized so we can see how much more ends up changing)

The text was drawn with a bitmap dump of some random system font I chose. Some of the icons you can see are still around, and the background color has persisted (so far), but basically everything else has changed. Although I wasn't even sure at this point if I wanted a pixel art style or what, I had chosen a canvas size of 640x360, which conveniently scales to both 1280x720 at 2x and 1920x1080 at 3x.

The icons you see here and in newer screenshots are all 15x15, black and white with alpha. 15x15 seemed like a decent guess at a good size for the amount of information I'd want to show at once, and I chose an odd number so that it would have a center. The strict two-color black and white palette put the focus on using strong shapes to communicate each icon's purpose. The plan has always been to do a second pass on my icon collection to add shading and some sort of color, though I'll probably still stick with a pretty limited palette once I get to that step.

For the technology behind all of this, I'm actually using a pretty robust renderer that I've been writing over the last several years. It might look unassuming as it is now, but I could load and draw a full 3D scene in the game with about 20 lines of code. Everything is drawn first into a 640x360 framebuffer, then transferred to the screen using an area scale filter. This allows for arbitrary scaling outside integer multiple sizes with a minimum of blurring or aliasing.

My expectation is that the released game will look pretty different from what you see here, but will still be recognizable as an evolution of where it is now. The bottom-up iterative process I'm using to develop this game has me building out a lot of stuff that's just good enough to work, then adding an item to my to-do list later to revisit and improve it. These don't just sit on the list forever - I've already picked several of those items off and fixed them up. As this project goes on, these things will get done one by one, and it'll end up where it needs to be for me to consider it finished.

[ThemsAllTook]

Unit tests. Some programmers roll their eyes at them, some programmers are filled with dread at the thought, some programmers see them as a useful tool. I've been in all three positions at different times.

While I was working on my battlefield layout, I needed to implement a search function to find the nearest valid target to a chosen position, with some pretty complicated logic for the search order. This would have been a major pain to test manually, and doing that wouldn't have given me confidence that I'd handled every edge case correctly, so it was a perfect candidate for a unit test. I have a capable unit test runner built into my framework and build system, but I hadn't been using it on this project so far. Taking inventory of my code, I found quite a few other files that would also benefit from a thorough test suite.

I once tried writing a game using the model-view-controller design pattern for everything. This project is using an evolution of that pattern, which roughly breaks down into these components:

• Record: An immutable struct describing a master copy of something in the game world and various data about it. Example: ItemRecord describes the icon, sounds, visuals, and combat effects of a consumable that can be used in battle.
  
  
• State: A mutable object containing an instance of something described by a record, and its the current state information. Example: ChampionStateModel tracks the current health/energy values, position, status effects, and next planned action of a battle participant, with a reference to a ChampionRecord that contains information about its identity. It has functions for taking damage, adding status effects, querying its next action, etc.
  
  
• View: References one or more state objects, and acts as the interface between the object and the player by drawing graphics, playing sounds, and handling input events. Instructs state objects to do things in response to user input. Strictly below State objects hierarchically; a View can refer to a State, but a State cannot refer to a View. This ensures that all the core game logic can be run in a non-interactive non-visual mode.
  
  
• Wiring: The glue that binds all of the other pieces together. Includes main program entry point, loading Records from data on disk, instantiation of States and Views, and all of the other associative tasks that don't fit into the other categories.
  
  

Everything that fits into the State category is what I'm interested in unit testing (as well as a couple of utility helpers I had around). There was a lot of game logic that I had implemented while I was figuring out what I was doing with this game. I'm normally a proponent of test-driven development: Write the tests first, see them fail, implement the tested functionality afterward, see the tests pass, and know for sure that the tests correctly verify what they're supposed to test. This doesn't really work for prototyping, though, and when a prototype is developed enough to be considered the real thing, it's left in the awkward position of having been developed without tests. Writing tests after the fact lacks a few of the benefits of writing them beforehand, but it's still worthwhile.

I decided that in order to test the battlefield positioning function I mentioned at the beginning of this post, I would want to write tests for every component upstream from it first. The battlefield layout is pretty deep in the hierarchy, so this has put a lot of work between here and there. It's all important and useful, but it does feel like a slog sometimes. I've written almost 5000 lines of test code in the last week, and there's still a bunch more to go yet. It's already revealed several bugs and oversights, including some potential crashes, so it's doing its job.

I'm on pace to be done with all of the tests I feel are necessary by next week. Hoping I'll be able to share something more visible by then.

[ThemsAllTook]

Unit tests are largely wrapped up, at least the ones that I felt were most important to the features I'm working on. Since these recent changes touched a huge amount of stuff, I'm still working on putting the pieces back together. My new targeting system appears to be working. The UI for it is only partially wired up, but the parts that are there appear to mostly work. Another week of tying up loose ends should have this all rock solid.

On a separate topic, I wanted to talk about the target platforms for Foresight Fight. The potential platforms that my framework allows me to build for are macOS, Windows, Linux, Android, and iOS. Each of these requires some individual attention to make it work nicely, and I'm only actively maintaining macOS and Windows at the moment. However, things will look a bit different once the game's release gets closer. This is all subject to change, but here are my current priorities:

• Windows: This is my primary release platform. It gets first priority for polishing up the game and making sure it plays nice. This is probably a surprise to no one.
  
  
• Linux: Definitely will be supported. I don't use it every day, and I haven't done some of the necessary work to build this particular game on it, but it's a pretty safe bet and shouldn't pose any real problems.
  
  
• Android: With some work to make my UI more usable on a touchscreen, I think this would make a lot of sense. I've had the game running on my phone before, so I know it works - other than UI, the only missing component is some glue code to talk to whatever the native Android audio API is, so whenever I find the time to write an interface layer for that, I should be able to build and deploy it again.
  
  
• macOS: This one is complicated. It's my development platform at the moment, so I know everything works. However, Apple has been steadily encroaching on the openness of their platform in ways that threaten to push me out of its ecosystem entirely. My cross-platform development methodology isn't compatible with their prescribed way of writing and distributing software, and every major version of their operating system has tightened restrictions on anything done outside the walled garden they've built. My current plan is to release an unsigned executable for the game, which will require users to disable Gatekeeper's heavy-handed refusal to run anything that hasn't been blessed by Apple. It's either this, or not release for the Mac in any form at all.
  
  
• iOS: This is in the same situation as macOS, but somehow even worse. Since there's no distribution channel for unsigned applications, or anything outside Apple's official storefront for that matter, I'm not going to be able to support it. Non-Android users who want to run this game on a phone will just be out of luck I guess.
  
  

I know other platforms exist, but I don't know anything about writing or distributing software for them. It might be fun to have this run on some sort of game console somehow. I feel like that would be a huge headache and come with a lot of the same problems as macOS and iOS, though. Not particularly planning to look into it at the moment.

[oldblood]

Very cool concept, and I like the details devlog vids. Nicely done. Will be following.

[ThemsAllTook]

Very cool concept, and I like the details devlog vids. Nicely done. Will be following.

Thanks! Glad to have you here.

I had a lot of stuff going on over the past week, and not as much time to work on this game as I'd like. I still managed to implement partial support for choosing your champion's position on the battlefield, and tied up a few other loose ends. I've shown about all I can in my existing test scenario, so I think it's time to build a new one to demonstrate some of the other things the game can do. I thought it might be fun to show the entire process of building it, so I'm starting on that in this week's video:

[ThemsAllTook]

Another super busy week for me, but I managed to get at least a few things done. Although there isn't much to write about here, a continuation of showcase scenario building happens on video:

[ThemsAllTook]

A somewhat unique concern with this particular game design is making sure that every mechanic is fully visible to the player. I'm committing entirely to making this a true complete information game, which means that hidden information is not allowed in any form. There were a few omissions in what the player could inspect: The formula for adjusting received damage, and the formula that determines the speed of each champion in battle. I've now added a "Mechanics" button on the map screen that allows these things to be inspected in detail.



Other than that, the video for this week has a live bugfix, some more scenario building, and the beginning of some real puzzle design:

[ThemsAllTook]

Something I mentioned during last week's video planted a seed of an idea in my head, and I felt the need to see it through to its logical conclusion before moving on. I had been doing work on a pop-up list of resources, stats, abilities, and properties for a champion, which looked something like this:



There were a few things I didn't like about it. Smashing all of these different types of things together in one list didn't feel great. I made a change that splits them out into separate lists for each category, which now looks something like this:



However, the idea I had in mind was that I wanted to be able to point at any champion stat (for example, strength), and have the game show me every calculation that involves that stat in some way and how it plays into it. This is now fully implemented. No more uncertainty about exactly what a number means; the formula for all damage calculations and the variables that play into them can be viewed in-game at any time.



All formulas are data, and can potentially work completely differently in custom scenarios. The human readable description is auto-generated, and can show arbitrary formulas with any level of complexity. I'll probably end up tweaking it for readability, but all of the information is there.

Since I was so focused on this stuff and hadn't gotten to some other important things needed for my showcase scenario, I don't do any level design on video this week. Hopefully I'll be in a better place to be able to do that next week.

[ThemsAllTook]

It's been a bit. I put up a short video basically saying "I have a lot to do that's not super visible, so it's going to be quiet for a little while" that I never bothered posting here. There was a tiny bit of other stuff in it, so for completeness, that one was here: https://youtube.com/watch?v=ps_MzflZmQI

Over the last couple of weeks, I've finally managed to finish the thing that's been blocking me from working on level design. Here's a shiny new target selection widget:



It's not very polished yet, but it's usable for inputting the necessary choices in combat. With this finer-grained control, I was able to set up a combat situation that's stacked a bit more heavily against the player, and still find a way to solve it. The game is in an awkward transitional state where a lot of stuff is broken or half-finished, but now that this thing is working, I think I'm past the worst of it. This whole detour was to address a major component of the game design that just never felt right to me, and although it's not 100% where it needs to be, I can feel that it's gotten significantly closer.

[Jasmine]

I just want to say that this game is insanely cool! After watching a couple of videos, I realized the gameplay is much more interesting than I thought!

(Hopefully that doesn't come off as insulting)

[ThemsAllTook]

Thanks! I totally get what you're saying - it's actually really useful feedback to know that I haven't quite nailed the presentation of my first impression yet. Definitely going to keep working on that.

[ThemsAllTook]

This past week was really nice. Now that I don't have a major rewrite or refactor in progress taking up all the space in the room, I've been able to knock off a whole lot of small-to-medium size tasks on my to-do list. Continuing to pursue my information completeness ideal, I've added a view that shows a detailed preview of what effects will take place on each target of multi-target abilities:



I also realized that there was no way to inspect the effects of the equipment enemies were using - the only way to view details on a piece of gear had been to look at it in your own inventory, and you won't necessarily have access to the same thing the enemy team has. It was a pretty simple fix to make the enemy equipment list interactive and pop up an inspector for each piece of gear they've brought:



Chipping away at small things like this is important, but I also need to keep my eye on the big picture. Building the main scenario for the game is going to take a long time, and I'll never finish if I don't start, so I've allocated some time to try and get that massive boulder rolling. I have an outline of the story and setting I want to use for it, and I'm now sketching out some characters and encounters to get an idea of what will work and what won't. This is something I won't be sharing publicly, so that the experience can be unspoiled once the game is released. The showcase scenario I've been working on during these videos helps me a lot by giving me a way to publicly mess with level design, so I can still share the concepts without having to reveal any of the specifics of what the main scenario will look like. It's a long way from being done, but I think it's going to be pretty great!

[ThemsAllTook]

Whoops, looks like I fell behind on updating this thread. I didn't put up a video this week, so I guess this post can be for last week. I took some time to work through a huge number of small-to-medium-sized UI polish and refinement tasks on my to-do list, including some pretty sweeping auto-layout changes for all of the list pop-ups in the game. No more huge amounts of wasted horizontal space everywhere:



Checking off this many items at once always feels great, especially when they've been waiting so long. I spent some time on video going over the state of my visual effects system, which I'm not quite satisfied with yet, in hopes it would help me see what needs to change about it:

[ThemsAllTook]

As great as it felt last time to knock out a whole bunch of small easy tasks, I've been focusing on some larger and much less straightforward things that needed to get done.

Throughout this devlog so far, my focus has largely been transitioning the battlefield from a flat list of champions to an actual spatial layout. A major component that was missing from this was a move command, so that positioning can mean something beyond initial setup. That's now implemented with all of the necessary UI and supporting code.



I've also made the battlefield terrain meaningful by giving the tiles their own graphics, and the ability to add properties to champions standing in them. Water can make you wet, increasing lightning vulnerability. A sigil on the ground can regenerate your energy when standing inside it. I have a lot of flexibility with this system, so a particular position can have pretty much arbitrary effects.

I did a bunch of UI work to support the new stuff, and as it turned out, introduced quite a few bugs I hadn't found until recording time. These videos continue to be super useful to me for revealing stuff like this.

[a-k-]

Everything here appears thoughtful! Are you targetting retro platforms? I'm asking because of the OOP-in-C you seem to be doing.

[ThemsAllTook]

Nah, C just happens to the language that jives with me the best. I've tried plenty of others, and they haven't had that same magic spark to them. It's a timeless classic that does everything I've ever needed.