Faltergeist: FOSS Fallout Engine


klapse

Central Scrutinizer
Joined
Aug 30, 2012
Messages
1,932
Location
Germany
Alexeevdv, author of Faltergeist (the foss Fallout engine) is still plugging away at the project and dersveses some respekt, methinks.

I never played these. Might be nice to have a place to chat about it - maybe generate some interest and patches to Faltergeist itself?

https://falltergeist.org/
https://github.com/falltergeist

Kind of retro-sperging on Fallout stuff lately...

The making of Fallout 1 & 2: Tales from the early days of Black Isle Studio

Watching the following vid made me realize how important it is to have a FOSS Fallout engine - since there seem to be some serious UI annoyances!

A critical Fallout2 review
Turn-Based Combat ickyness: ~13:00
Inventory: 15:20

A not-very critical Fallout 1 retrospective
 
Last edited:
I played them back when they were released (more or less) and enjoyed them a lot. I'd be really glad to have a FOSS engine for them. Fallout 1 can more or less run on the Pandora either with Dosbox or with Exagear, but neither are perfect.

The only 3D Fallout I've played is New Vegas. It was fun as well, though I enjoyed it less than 1 and 2.
 
I'm thinking that combat might be 'parallelizable'.
Namely: The sequence of actions/attacks etc progresses linearly in the same order as original fallout with same ruleset (as far as can be determined) - but the animations for all combatants in each round are played in parallel. Player could pause, issue new commands, or let attacks progress automatically as in Baldur's Gate. This would avoid the horribly drawn-out combat that occurs with many enemies on-screen.

Does someone who knows Fallout better think this is possible without significantly affecting the underlying combat mechanics?

-----
On the inventory side, a mod exists to show how full your inventory is; in addition it might be worth binding sets of equipped armor into 'outfits' that could be swapped without individually equipping/removing stuff.
 
Fallout Tactics, which was quite similar to Fallout 1 and 2 offered a real time combat option. So it probably did parallelize.
Another option would be to parallelize IA actions. Everything would still be turn-based but AI characters who act in a row would all take their actions simultaneously (or might have them computed in a row but displayed simultaneously). This would fix the problem without changing much to the way the game work.
 
Fallout Tactics, which was quite similar to Fallout 1 and 2 offered a real time combat option. So it probably did parallelize.
Another option would be to parallelize IA actions. Everything would still be turn-based but AI characters who act in a row would all take their actions simultaneously (or might have them computed in a row but displayed simultaneously). This would fix the problem without changing much to the way the game work.
Yes, parallelizing the display of (sequential) combat actions would include those of the AI.
 
I used to think a lot (I used to dream I'd make games, of course ;)) and wonder why the system You propose wasn't used so often in older crpgs.

It'd add fun visuals and a feeling of all-around battle chaos- imho no matter how long would it take to plan a turn, it'd feel more fast-paced than paused real-time in the style of Baldur's Gate.

I wonder if "sequential" turn-based started as means to overcome technical difficulties (we can only hold so and so many frames, a computer can redraw so and so many pixels at a reasonable speed etc.), but became the norm so thoroughly that it became a convention, and not discussed/experimented with much.

Simplicity as compared to normal turn-based: "Synchronous" turn-based combat also could allow for more interesting tactical risk decisions to make, but could also confusing to the novice. I don't mind, if we make games for fun and not mass-sales, then not every game genre/mechanic has to be super-inclusive.

Balancing: We can issue commands at once and execute them immediately- every 2 guys who shoot at each other get hit, but if someone shoots at a moving target, he never hits- that's one hard to balance option. On the other hand, if we issue commands simultaneously but someone is faster (so "roll for initiative" considered), we have two guys shooting at each other but only will be faster. But do we let know the player about what did he and his enemy roll, before issuing the command? Or we don't let the player know at all? Or we let him estimate how much a chance does he stand (eg. let him know that the enemy is really much faster than the player)?

Sorry for the confusion, I might clear this up later. Those are just some of my thoughts about potential issues when balancing.
 
Thanks for sharing your thoughts; I think I can contribute a few worthwhile comments.

It'd add fun visuals and a feeling of all-around battle chaos- imho no matter how long would it take to plan a turn, it'd feel more fast-paced than paused real-time in the style of Baldur's Gate.
Of course someone adding new visuals is fine, but allowing multiple battle actions to display in parallel doesn't require new visuals.

I wonder if "sequential" turn-based started as means to overcome technical difficulties (we can only hold so and so many frames, a computer can redraw so and so many pixels at a reasonable speed etc.), but became the norm so thoroughly that it became a convention, and not discussed/experimented with much.
Maybe, but all except the very earliest games for 8-bit computers and consoles managed to animate multiple (>10) sprites on screen at once - so it wasn't technically impossible to animate several fighting characters. It's just that with limited one-programmer budgets, the first cRPGs focused on innovating in the RPG aspects like stats and places to explore.
I think the Baldur's Gate 'pausable mayhem' was just a brilliant innovation that is so superior that it's painful to go back to sequential turn-based combat, at least with large numbers of opponents. JRPGs of the 1980s which used sequential combat avoided that problem by limiting the number of enemies per encounter to a handful.

Balancing: We can issue commands at once and execute them immediately- every 2 guys who shoot at each other get hit, but if someone shoots at a moving target, he never hits- that's one hard to balance option.
I might be wrong, but I think you're imagining some kind of change to game mechanic that isn't necessary in order to play combat animations in parallel. The Interview by Eurogamer gives a bit of an idea how the combat engine works. It's really modular, which let them substitute the GURPS ruleset with their in-house ACELIPS system.
The game tells the combat module something like: "ok here's this character, with this cover, shooting that character with that cover, give me the % chance of him hitting this target this round." IIRC it just iterates through each combatant with a decision what to do and then asks the game engine for the %hit.
My proposal is to not change any of that stuff. The combat mechanic stays the same. The ruleset stays the same. The sequence of attacks and actions stays the same. We just run through all combatants and start an animation appropriate to what happens as the result of that round. Loop that, round for round, until combat is over.
So for example the question "who hits a moving target, where" is answered by the sequence of actions processed by the combat engine. If the enemy began his movement before the player fires at him, then the player is targeting the enemy at the new position - despite the animation lagging this fact.
Sure you might need to change-up the order of animations a bit - e.g. tack-on the death animation after the character is done walking to the new position... but i'd take that over slogging through 70 hours of tedious combat.....
There is one change which this implies which necessarily impacts gameplay; namely the case where within 'one round' the battlefield situation changes, for example a death, or incapacitating disability etc. to which the player reacts and changes tactics. Losing this ability means losing some degree of fine control of the combat. Only a real Fallout 1 and 2 expert could tell us whether this would break any game situations. If it did, the old combat could be toggle-able as an option.

On the other hand, if we issue commands simultaneously but someone is faster (so "roll for initiative" considered), we have two guys shooting at each other but only will be faster. But do we let know the player about what did he and his enemy roll, before issuing the command? Or we don't let the player know at all? Or we let him estimate how much a chance does he stand (eg. let him know that the enemy is really much faster than the player)?
I don't think this is a problem, since I don't envison changing initiative or the underlying sequential combat model. But not having actually understood the code, there could be hugely wrong assumptions operative here.
Erm. Now i reread that. Yes the change of battlefield situation within a round is something the player can no-longer react to - so you might end-up wasting a shot on an already-dead enemy, for example. Still if the Faltergeist player could turn on parallel combat at will, it'd be quite welcome, i think.
 
Last edited:
If one player combatant strikes one enemy in their turn, and in the enemy's turn, that enemy strikes the original combatant, how do you animate that to work at the same time?

I've more experience with JRPGs really, and I remember the Grandia system whereby all characters would take a certain amount of time to rest between moves, and the game would animate that sequence of all characters until it came to the player's turn, when it would pause the action to allow the player to navigate the battle menus. Most of the times required between actions were the same, or I assume integer fractions of the whole, and each character sync was tweaked by some small fraction, so their animations always played out one after the other. I believe the game Valyria Tear on Pandora used a similar system as well, and I believe the recent Final Fantasy games have had some kind of real time thing, but I've not played those.
 
Back
Top