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

Login with username, password and session length

 
Advanced search

1369261 Posts in 64328 Topics- by 56328 Members - Latest Member: CarlaDoyle

November 15, 2019, 10:17:07 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsForesight Fight - A puzzle game with tactical RPG combat
Pages: [1]
Print
Author Topic: Foresight Fight - A puzzle game with tactical RPG combat  (Read 493 times)
ThemsAllTook
Global Moderator
Level 10
******



View Profile WWW
« on: October 21, 2019, 02:59:02 PM »

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.



« Last Edit: October 22, 2019, 07:01:37 PM by ThemsAllTook » Logged

QOG
Level 3
***



View Profile WWW
« Reply #1 on: October 22, 2019, 12:18:16 PM »

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?
Logged
ThemsAllTook
Global Moderator
Level 10
******



View Profile WWW
« Reply #2 on: October 22, 2019, 04:10:20 PM »

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.
Logged

ThemsAllTook
Global Moderator
Level 10
******



View Profile WWW
« Reply #3 on: October 28, 2019, 03:00:10 PM »

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:



Logged

ThemsAllTook
Global Moderator
Level 10
******



View Profile WWW
« Reply #4 on: November 04, 2019, 04:00:09 PM »

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.



Logged

ThemsAllTook
Global Moderator
Level 10
******



View Profile WWW
« Reply #5 on: November 11, 2019, 04:04:16 PM »

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.



Logged

Pages: [1]
Print
Jump to:  

Theme orange-lt created by panic