Outpost 2 1.3.7

[Vagabond]

How hard to add a map description to game selection screen for multiplayer? Especially for the multiplayer maps that require instructions? Like Fractures for instance

I'm a big second for adding a RTF text box somewhere to the multiplayer pre-game room screen. This would be pretty big to me. It would allow for:

• Explaining special use of check boxes. Like in Fractured Alliance, checking day/night actually creates another AI base instead of changing day/night.
• Explaining what vehicles are added when adding initial vehicles. In Caught in the crossfire I believe it gives you trucks, robo-miners, convecs, etc instead of laser/microwave lynx.
• Adding back-story to read. Sirbomber in particular usually writes a little briefing/story on what the scenario entails that would be nice to have available in game instead of just in the forums.
• Listing special in game instructions. If we every get Outpost Monopoly finished, it would be perfect to list the chat commands for trading property and stuff. Some multiplayer scenarios now allow your colonists to starve if you don't put your food in trucks when evacuating. Also some multiplayer scenarios allow you to transfer colonists using evacuation transports next to CCs. Caught In The Crossfire forces you to find ore deposits with scouts, which would be nice to explain before starting.
• Adding a link to the forum page where the scenario can be downloaded if it isn't included in the main Outpost 2 download. This way when random player doesn't have it, you don't have to dig around for the link or file.
• Scenarios using special tile sets (like Greenworld) could explain where/how to get the tiles before playing.

I think if would be great if we could just push a RTF file into the DLL via a resource/resource script like we do for Colony Game mission briefings (IE Cold War). Outpost 2 could just look for the resource when the text box changes which scenario is highlighted and display it if applicable.


Dave,

I'll put together the separate forum post for nominating the scenarios this weekend with thought out guidelines unless someone else wants to do it. Since I have a couple of scenarios that I want to see included it feels a little self-serving, so if someone else wants the job, I would be happy not doing it.

[dave_erald]

Dave,

I'll put together the separate forum post for nominating the scenarios this weekend with thought out guidelines unless someone else wants to do it. Since I have a couple of scenarios that I want to see included it feels a little self-serving, so if someone else wants the job, I would be happy not doing it.

Ha! Yeah that's fine, I can make it up tomorrow afternoon if someone doesn't beat me to it. In fact, I may end up adding two threads, one for community created content and nominations; and another about which maps are in the current download, what can stay or go, and how to go about adding refreshed map packages of the current stuff that seeks to more evenly balance multiplayer battles (see, I might be a bit self serving too)

[Hooman]

I like the idea of displaying custom mission instructions, both pre-game, and in-game. It would also be really cool if you could have custom settings for a map, rather than always the standard set of options. Add extra check boxes, or option buttons, label them all appropriately. I figure it's probably do-able, though I don't exactly look forward to such work to hack this into the game. Remake maybe?

[leeor_net]

Remake maybe?

You and I are clearly on the same page. Now it's just a matter of getting all the other developers on the forums together to make this a reality.

[dave_erald]

I am fully down with a modest rebuild of this game. Tweaks here and there but just a modern rebuild would be pimp. I'd help but not too sure where.

[leeor_net]

There'd be a lot to do... biggest thing would be interoperability between the new and the old game... I have no idea how most of the original game works or even how to work with DLL's to be honest but I can build the terrain engine, map editor and unit logic.

[Vagabond]

There'd be a lot to do... biggest thing would be interoperability between the new and the old game... I have no idea how most of the original game works or even how to work with DLL's to be honest but I can build the terrain engine, map editor and unit logic.

Leeor,

I was hoping to see OutpostHD finished before you moved on to other big projects.

[Arklon]

Rewriting the game from scratch would be simply too much work for how many developers we have. A more feasible approach would be to rewrite it incrementally from the disassembly. I believe that was how OpenTTD and OpenRCT were made.

[Hooman]

There'd be a lot to do... biggest thing would be interoperability between the new and the old game... I have no idea how most of the original game works or even how to work with DLL's to be honest but I can build the terrain engine, map editor and unit logic.

The DLLs would have to go. That's no way to make levels. It's also a huge security hazard when distributing levels.

I've been thinking maybe a fake game engine could be written with fake game export functions, that loads and calls the DLLs, and records what functions get called, and with what parameters. It's not exactly a perfect solution, but it's a way we could start converting things. Perhaps get working source for original levels as a start, and long term turning the DLLs into more of a data structure. Bloody lot of functions though. You'd probably want to auto-generate such a utility somehow, using the SDK header files as inputs, or perhaps the export table from Outpost2.exe as the input.

[Arklon]

I've been thinking maybe a fake game engine could be written with fake game export functions, that loads and calls the DLLs, and records what functions get called, and with what parameters. It's not exactly a perfect solution, but it's a way we could start converting things. Perhaps get working source for original levels as a start, and long term turning the DLLs into more of a data structure. Bloody lot of functions though. You'd probably want to auto-generate such a utility somehow, using the SDK header files as inputs, or perhaps the export table from Outpost2.exe as the input.

That's exactly what BB was proposing. Though, you'd need to run it multiple times per mission using different random seeds or different results from TethysGame::GetRand() to deal with random resource placement, need to call all the trigger callbacks and record what they do, etc. This wouldn't really work for missions with AI, but the vast majority of the mission DLLs are simple MP ones.

[Hooman]

Yes. The GetRand calls will require multiple runs to catch differences from if statements and such. I was thinking you could record the number of calls to GetRand, always returning 0 the first time, then re-run, counting through to the randMax parameter. That could be a huge number of runs though if there are lots of calls and large randMax values. Would need to decide on that case after seeing how bad the problem is. I suspect it's not that bad in practice.

It'd also be nice to detect the simple cases where the result of GetRand is just passed directly to another exported function, with no other changes. Could simplify output in those cases.

Calling all the triggers is of courses needed. Most trigger callbacks I've seen are fairly simple. Most checks are done with the triggers themselves, rather than in the callback. No way to be certain of course, but I think the aim should be good enough, rather than perfect.

I'm not entirely sure why this wouldn't work for missions with AI. A lot of it is pre-recorded tasks setup in InitProc.

[leeor_net]

There'd be a lot to do... biggest thing would be interoperability between the new and the old game... I have no idea how most of the original game works or even how to work with DLL's to be honest but I can build the terrain engine, map editor and unit logic.

Leeor,

I was hoping to see OutpostHD finished before you moved on to other big projects.

I was planning on that. Hehe. I did the whole "I can work on 15 projects at once!" thing way back when and ... yeah... it didn't work out very well at all. Not going to repeat that mistake.


Out of curiousity, how do you incrementally rewrite a program? E.g., if we reimplemented each function individually, how do you then incorporate that into the compiled program?

Also, I'm not entirely convinced that's the best way to do it. In my mind the hardest part of this would be the network code... and that's primarily because I haven't delved much into network programming... nothing serious anyway.

The rest of it is simple enough. A terrain engine with unit selection, placement and movement isn't hard. Okay maybe it is but these are problems I've solved many many times so it seems very simple to me.

Structure connectedness is simple enough too -- OutpostHD has a simple solution that does the job.

The morale/population model has already been implemented by Hooman: https://svn.outpostuniverse.org:8443/!/#outpost2/view/head/GameEngineSimulations/PopulationSimulator

So between a terrain engine, unit selection/placement/pathing and the morale/population core, that leaves research, technology, combat and network. I'm pretty sure between the five developers that are here regularly (myself, hooman, vagabond, arklon and blackbox) we could put something together. It doesn't have to be perfect.

Anyway, that's my argument for it. I'm not going to say it will be easy -- it won't. I'm not going to say we can have something finished in less than a year -- we won't. Just saying that it's possible if we focused our efforts.

I think that's as far as I want to go on this subject. I think we should focus more on 1.3.7 and the things we can do with Outpost 2 as it stands.

[Vagabond]

Yes. The GetRand calls will require multiple runs to catch differences from if statements and such. I was thinking you could record the number of calls to GetRand, always returning 0 the first time, then re-run, counting through to the randMax parameter. That could be a huge number of runs though if there are lots of calls and large randMax values. Would need to decide on that case after seeing how bad the problem is. I suspect it's not that bad in practice.

It'd also be nice to detect the simple cases where the result of GetRand is just passed directly to another exported function, with no other changes. Could simplify output in those cases.

Calling all the triggers is of courses needed. Most trigger callbacks I've seen are fairly simple. Most checks are done with the triggers themselves, rather than in the callback. No way to be certain of course, but I think the aim should be good enough, rather than perfect.

I'm not entirely sure why this wouldn't work for missions with AI. A lot of it is pre-recorded tasks setup in InitProc.

Hooman and Arklon,

If we are corporately serious about somehow translating all the scenarios into a new game engine someday in the future, I think it would helpful to have a small article with some guidelines on how to design scenarios right now to make them easier to translate in the future. I don't have a formal degree in math or software engineering so it is difficult for me to follow what you are talking about doing and how that impacts my current scenarios.

I would be happy to work in a way that makes someone else's life easier later on though.

[Arklon]

Out of curiousity, how do you incrementally rewrite a program? E.g., if we reimplemented each function individually, how do you then incorporate that into the compiled program?

We could fix up the disassembly to be recompilable, but I think a neater idea would be to modify an open-source linker to convert the exe to an obj that we can link against like anything else, using info dumped from OllyDbg/IDA to regenerate the symbol table. All the symbols in the obj would be defined as weak externals, meaning we can redefine those same symbols in our own code and they would seamlessly override the ones from the obj.

Also, I'm not entirely convinced that's the best way to do it. In my mind the hardest part of this would be the network code... and that's primarily because I haven't delved much into network programming... nothing serious anyway.

That'd be far from the hardest part. The pathfinder and movement code is probably the most painful, even Hooman gave up on reverse engineering that. However, quite a lot of the disassembly is documented in the OllyDbg comment file, including the network code, so there's a ton of stuff we could get to work on reimplementing without additional reverse engineering work.

If we are corporately serious about somehow translating all the scenarios into a new game engine someday in the future, I think it would helpful to have a small article with some guidelines on how to design scenarios right now to make them easier to translate in the future. I don't have a formal degree in math or software engineering so it is difficult for me to follow what you are talking about doing and how that impacts my current scenarios.

We'd transition to a scripting language for (most) missions, probably Python (if not additional ones like Lua as well), but keeping support for DLL missions may be desirable. The exported API would be kept the same for compatibility, so it'd pretty much just be a difference in language syntax.

I don't have a degree in computer science either, I actually did biochemistry. It's not necessary in order to learn this stuff, not to say there isn't a learning curve. Teaching yourself programming, etc. on your own time is probably gonna get you better results than a formal education for the most part, honestly. I know CS grads who couldn't program if their lives depended on it.

[leeor_net]

Also, I'm not entirely convinced that's the best way to do it. In my mind the hardest part of this would be the network code... and that's primarily because I haven't delved much into network programming... nothing serious anyway.

That'd be far from the hardest part. The pathfinder and movement code is probably the most painful, even Hooman gave up on reverse engineering that. However, quite a lot of the disassembly is documented in the OllyDbg comment file, including the network code, so there's a ton of stuff we could get to work on reimplementing without additional reverse engineering work.

Why would you try to reverse engineer their pathing code? I would just outright replace it with a well known pathing algorithm like A*. MicroPather is a well documented and easy to use (and small) A* pathing library. It would be trivial to implement pathing this way.

I guess I'm coming at this from a different point of view -- I'm not seeing it as reverse engineering the game and reimplementing it exactly as it was, I'm thinking about rewriting the game entirely from scratch and reimplementing it from the beginning without trying to emulate what the original game did. Granted it should behave very similarly but... I dunno. I think I'm beating a dead horse here.

[Arklon]

Why would you try to reverse engineer their pathing code? I would just outright replace it with a well known pathing algorithm like A*. MicroPather is a well documented and easy to use (and small) A* pathing library. It would be trivial to implement pathing this way.

The graph search algorithm is the easiest part of writing a complete pathfinder solution. There's plenty of other things to worry about, like optimizing it using a quad/octree and needing to keep that in sync with map changes, dealing with unreachable endpoints, figuring out how to make multiple units path nicely simultaneously, dealing with unit collisions, etc. I think OP2's pathfinder algorithm is just a badly neutered breadth-first search, which A* is simply a heuristically-optimized form of. Plus the code has to deal with actually moving the unit too.

I guess I'm coming at this from a different point of view -- I'm not seeing it as reverse engineering the game and reimplementing it exactly as it was, I'm thinking about rewriting the game entirely from scratch and reimplementing it from the beginning without trying to emulate what the original game did. Granted it should behave very similarly but... I dunno. I think I'm beating a dead horse here.

Well yeah I'd agree on not bothering to reverse engineer the graph search part of OP2's pathfinder, but the problem is doing the rest of it. I can't even really figure out what part of the disassembly is the graph search.

[Hooman]

If we are corporately serious about somehow translating all the scenarios into a new game engine someday in the future, I think it would helpful to have a small article with some guidelines on how to design scenarios right now to make them easier to translate in the future.

To make it easier: Publish the source!