[Modding] Multiplayer

[massivebacon]

Hello!

My friend and I, both now zealous FTL players, were tossing around ideas for what we think could make the game better and the idea of multiplayer came up. I see there has been some discussion in that regard on the forums but nothing substantial has come out of it. I'm pretty good at coding but have never actually dealt with programming outside of something that runs locally, so if anyone could point me in the right direction for where I could figure out how to implement this I would be super grateful.

As far as what kind of multi, I think right now simple crew control would be the first step (maybe implement WASD), and if it works it could become more robust.

Thanks for the help!

[swixel]

Given the game lacks native support for almost any of that (okay, crew movement is plausible), you'll need a few things.

1. Sigscanning libraries/code (detours is great if you don't mind it being opensource, but it's also not crossplatform).
2. Signatures of scan.
3. A point of injection which isn't going to cause the game to freak out.

For networking, you might want to look at boost::asio or QtNetwork.

[Tysonclyde]

You should check this mod out. This is a Torchlight 1 MOD, but it will give you a base for you FTL multiplayer mod. http://code.google.com/p/tlmp/downloads/list

[Tysonclyde]

MULTIPLAYER

[HelloLion]

I approve of this idea and wish you the best of luck in it.

[swixel]

You should check this mod out. This is a Torchlight 1 MOD, but it will give you a base for you FTL multiplayer mod. http://code.google.com/p/tlmp/downloads/list

I can't see how making that crossplatform would be easy/fun ... though I guess stdlib is used by the gcc/g++ versions of this game. Still, as much as that sort of trampoline is nice, he's going to have to understand the data within the game, and I don't think it needs to be pointed out to most people who've done this before: this is a late-game style request, and not really particularly well suited to roguelikes.

For starters, you'll either need to turn one into a listen server, or you'll need to reverse the ship + system + crew information (minimally). Given how weird the data acts as it's loaded, you'd end up almost rewriting the client.

[sududai]

Well, I wish you good luck.
I found myself staring into the mirror hypnotizing myself and trying to think of a way this could work
After all those creepy looks and thoughts, I suggest you better make it from a scratch with standards.
It looks less nightmare, than falling deep into the darkness of foreign work.

This is kinda great load for a simple mod.

What kinda multiplayer are you trying to make?
Turns? Realtime whitout stopping? Double-side stopping (wtf)?
Cooperative (paralel traveling - jump=turn)?
Cooperative (traveling together)?
Deathmatch (this could be easy start for a remake)?

[Vhati]

Even the WASD would be problematic.

Crew sprites (as stored in saved games probably similar in memory) have both a current coordinate position and a goal square they are moving toward. Both are offset/limited by the SHIP.xml and SHIP.txt resources of whatever ship that sprite hapens to be on board. When the goal is reached, a new goal is set to the lowest-indexed unoccupied square in the room (left-to-right, wrapped).

You could change that goal square to move to adjacent spaces, fighting the default room positioning after each square, but it really wouldn't be worth the effort for the questionable gameplay benefit you get. While you're distracted driving that one crew member around, there's a ship outside shooting at yours.

A first step would be writing essentially a memory-cheating trainer with the saved game format as a reference. When you can can consistently dump the state of the game by reading memory, the next step is to either find safe ways to change values directly, or catalog all the official functions that modify a given value so you can intercept them and use your own funcs. If you're lucky, you might be able to pass the values from one FTL instance to another (creating a passive observer player). Then you can move onto having a headless server that distributes values of a canonical game state to all trainers (making them all observers) and accepts requests to modify it (which it can choose to ignore, FIFO, etc) when a client's intercepted func fires or a polled value changes in a way the trainer didn't cause.

But this isn't Grand Theft Auto. There's no need for a Multi Theft Auto project to do an end run around engine complexity. Just contribute to Overdrive (or fork) and reimplement the whole thing it from scratch with the features you want. Even turning the saved game editor into a standalone game would be easier than poking at and synchronizing memory.

[shark]

I can't see how making that crossplatform would be easy/fun ... though I guess stdlib is used by the gcc/g++ versions of this game. Still, as much as that sort of trampoline is nice, he's going to have to understand the data within the game, and I don't think it needs to be pointed out to most people who've done this before: this is a late-game style request, and not really particularly well suited to roguelikes.

Which brings another set of questions - which stdlib and compiled by which gcc, or to start simply with 'which gcc and companion libs'

For starters, you'll either need to turn one into a listen server, or you'll need to reverse the ship + system + crew information (minimally). Given how weird the data acts as it's loaded, you'd end up almost rewriting the client.

What if one guy is the fleet and the other guy is the rebel? they both play the game normally. but yea this requires patching the executable. maybe an IDA session is in order ..... ??

how about you start with a ramdisk and poke locations until you map some of them to concrete data (behaviours passing as features) so you actually have something to code/inject in the executable?

EDIT:
the way i see it, the game is randomly generated at start of each game. if both clients synchronize the seed used for this randomization, they would get the same "random" result, meaning being in a identical game. syncing both of these clients however would need to be written from scratch. using sockets and simple tcp

Even turning the saved game editor into a standalone game would be easier than poking at and synchronizing memory.

Disciples 2, HoMM3, MechWarrior 4 mods did it. A mod-unfriendly game is still perfectly moddable, you just have to rape it a bit harder. Remember, all you need to do is write a wrapper/loader so that when you fork() or CreateProcess() you don't get access violations for trying to piss all over it's memory. which gives me an idea for a tool, like something that greps /dev/mem but visually for the target process.

But, it's evident that this path demands more time, skills and effort.

[Vhati]

how about you start with a ramdisk and poke locations until you map some of them to concrete data (behaviours passing as features) so you actually have something to code/inject in the executable?

*squint* Are you describing the cheater/trainer type search through a process' memory for bytes that change at the same time (behavior) as when a given in-game feature (such as scrap count) changes (increasing/decreasing/equals), so a custom scrap function can be eventually injected (via patch or loader) that when called, locates and modifies those bytes as desired?

Linux is probably capable of assigning a region of memory already in-use by a process to a ram drive (which would allow hex editors to play with its contents), but generally this is the province of specalized processes like debuggers and cheaters/trainers.

if both clients synchronize the seed used for this randomization, they would get the same "random" result, meaning being in a identical game.

There's a seed that affects the sector tree (set once per game), and a seed that affects sector layout/events (changing each sector, possibly itself seeded/precalc'd with nodes of the tree). If the players never interacted to influence each other's states, synchronizing seeds would yield two players independently playing similar games. Beyond that, changes to individual values need to be tracked, queued, and forwarded for anything both players can see and change.

Disciples 2, HoMM3, MechWarrior 4 mods did it. A mod-unfriendly game is still perfectly moddable

I never said it was nigh impossible to do. I spelled out how it'd happen, which does sound more daunting than "all you need to do is write a wrapper". What I said was that it's not worth the effort in this case because there are easier options.

"But this isn't Grand Theft Auto. There's no need for a Multi Theft Auto project to do an end run around engine complexity."

When I said "Even turning the saved game editor into a standalone game would be easier" I meant that it's a codebase already capable of reading resources and interpreting/displaying a saved game state. It wasn't meant to be playable (UI would need reworking for animation and such) but, had Overdrive not existed, extending it would still less taxing than taming memory.

something that greps /dev/mem but visually for the target process.

Windows...
App: Process Explorer - Can essentially run the 'strings' command against a process' memory.
App: CheatEngine
App: HxD - A hex editor that can mess with RAM.
App: OllyDbg - Debugger, has a window showing the attached process' memory.
App: Immunity Debugger (OllyDbg + python)
Maybe Paimei + PyDbg, never tried 'em.

Lnux...
Article: ServerFault - Dump a linux process' memory to a file.
Article: Stackexchange - How to read /proc/$pid/mem on linux
Apps: AskUbuntu - Game real-time modification utility
There are gdb frontends to make things visual, but I'm not familiar with debuggers on linux.