Introducing RedAlert++

[CCHyper]

We see the goals in a simple order;

 

First is to recreate Red Alert as accurate as possible, and only adding features that extend the overall game but do not effect gameplay (A keyboards controls dialog for example).

 

The second, and only once the project is close to complete, will be where we can focus on adding many features. Though all these features will be disabled by defualt, so the end user decides if he wants to use them in the scenario or mod they are creating.

[Allen262]

Right-click scrolling not bad but not something I miss when playing as I'm singleplayer person and most missions don't get to the full Mega Map 128x128. Replay missions feature also not bad but using a auto save like RA2 dose at the start of a new mission during campaigns may work just fine.

 

The saving of unit and buldings from Allied 2 to Allied 4 is done by something but what I do not know. I'm sure CCHyper will have somthing worked out for it.

 

Red Alert has whats called a "Carryover" logic, it saves the the houses objects with the strength and location on the map so they can be replaced in the next scenario.

 

I know about the Carryover so let me re-word what I said. I don't where it saves the data it need to carryover all of the units and buildings that need to be saved from Allied 2 and applied to Allied 4.

 

We see the goals in a simple order;

 

First is to recreate Red Alert as accurate as possible, and only adding features that extend the overall game but do not effect gameplay (A keyboards controls dialog for example).

 

The second, and only once the project is close to complete, will be where we can focus on adding many features. Though all these features will be disabled by defualt, so the end user decides if he wants to use them in the scenario or mod they are creating.

 

Sounds fine to me!

[CCHyper]

Red Alert has whats called a "Carryover" logic, it saves the the houses objects with the strength and location on the map so they can be replaced in the next scenario.

I know about the Carryover so let me re-word what I said. I don't where it saves the data it need to carryover all of the units and buildings that need to be saved from Allied 2 and applied to Allied 4.

 

The only other way I can see the game transfering player objects from a previous scenario would be the using the [bases] section in the scenario.

[Allen262]

I know of the ToCarryOver=yes that saves the units and buildings and ToInherit=yes tha loads the units and buildings but how it saves the data I don know. Dose it save the data to a reg or make a file some place on the computer? 

[Blade]

Although I've not actually looked at the code that handles carryover I can say with some certainty that it will be part of the game state held in memory and will be written to the save game. No secret files or reg keys.

[LavenderMoon]

Speaking of, will original RA1 savegames be compatible with RedAlert++?

[CCHyper]

I know of the ToCarryOver=yes that saves the units and buildings and ToInherit=yes tha loads the units and buildings but how it saves the data I don know. Dose it save the data to a reg or make a file some place on the computer?

 

Just as Blade mentioned. The Carryover handler is a global object that stores the information, to be retreived at any time using ToInherit.

 

 

Speaking of, will original RA1 savegames be compatible with RedAlert++?

 

Legacy Savegame support will not be included. It would hold us back from taking advantage of modern features just to support a save game file, but we will allow game saving in a newer format, and the resulting file will be smaller too.

[LavenderMoon]

What features would allowing you to load original RA1 games hold you back from implementing?

[Allen262]

Blade and CCHyper.

Thanks for the info. I'll quit SPAMing up your intoduction thread with crap now.

[Blade]

Can you load the DOS save games in the Win95 version? No you can't, so why would a completely rewritten exe be able to load old ones? From what little I've seen, the save games look like binary state dumps of the game minus the stuff it can reload from disk. Loading them makes assumptions about the word size and of object sizes in the game in general, most of which we won't go out of our way to guarantee between platforms for performance reasons and we won't be going out of our way to make them match the original objects exactly.

 

In general, supporting the old saves is way down on the priority list, it wouldn't be impossible to write a parser that translated the old saves to a newer format, but I don't think either myself or CCHyper is going to invest much time investigating it.

[FunkyFr3sh]

I think irans patch doesn't support old saves anymore either.

 

In dune 2000 I added all the new stuff to a additional file to keep the saves compatible with the original version

[Nyerguds]

Dune Dynasty can load original Dune II savegames. Frankly, knowing the structure of C&C1 savegames, expanding them while keeping legacy support seems like peanuts. All you need to do is store a value somewhere in your new format savegames that indicates that an additional part should be read.

 

And file size? Really? Come on, this is 2015. People download games of over 15 gigabytes through online distribution platforms. A couple of kilobytes won't make the difference.

 

Though, I guess if you're seriously remodelling the heaps it's probably unavoidable, since that changes the actual saved/loaded data structure 

[CCHyper]

Blade and CCHyper.

Thanks for the info. I'll quit SPAMing up your intoduction thread with crap now.

 

Not a problem, these are all questions related to the project, and I have no problem discussing them here

 

Just to settle the discussion regarding save games. We will not be support them at all. It is not possible for us to due to the way Red Alert stores the information.

[fir3w0rx]

It'll be hard to make this compatible with modern hardware and software, while at the same time staying true to the original source code. Imo, for this to be true to the original, you guys will have to make sure that the finished product runs on the following:

 

-Pentium

-Windows '95

-64 MB of RAM (I think I had even less)

-VGA monitor, oh sorry... SUPER VGA monitor (those big box looking things)

-and your mom in the background telling you to do your homework every 5 fkn minutes

 

[LavenderMoon]

From what little I've seen, the save games look like binary state dumps of the game minus the stuff it can reload from disk. Loading them makes assumptions about the word size and of object sizes in the game in general, most of which we won't go out of our way to guarantee between platforms for performance reasons and we won't be going out of our way to make them match the original objects exactly.

I disagree that being able to load original Red Alert save games would require your in-memory formats for the objects be the same. You said yourself later in the post that it wouldn't be impossible to write a parser for the old saves that converted them to RedAlert++'s native format, so calling that converter at runtime when loading a legacy save game would also not be impossible.

[Tore]

Even updating the games with a patch makes old save games incompatible. Like 1.04 to 1.08 for instance. For old save games to work on RA++ I guess they have to be converted somehow.

[LavenderMoon]

Hyper, you edited my post instead of replying.

 

Anyway, what I was getting at is that you're no longer assembly hacking old C&C executables; you could support loading old RA save games without having to structure RA++'s in-memory representations of those objects around them. I agree supporting old RA saves isn't worth the research and implementation effort, but I disagree that it's impossible. More to the point, I hope you don't stick with the RAM dump save format for RA++ native save games. I imagine writing INI format data and compressing it would work quite well.

[CCHyper]

Apolagies LavenderMoon , I was using my phone.

 

From what little I've seen, the save games look like binary state dumps of the game minus the stuff it can reload from disk. Loading them makes assumptions about the word size and of object sizes in the game in general, most of which we won't go out of our way to guarantee between platforms for performance reasons and we won't be going out of our way to make them match the original objects exactly.

I disagree that being able to load original Red Alert save games would require your in-memory formats for the objects be the same. You said yourself later in the post that it wouldn't be impossible to write a parser for the old saves that converted them to RedAlert++'s native format, so calling that converter at runtime when loading a legacy save game would also not be impossible.

The way C&C games work, they do. I had the same issue with HyperPatch, once I extended a class, previous save games are no longer supported, as the save game packs the information into the stream and the stream must match the allocated data by the game.

 

It is just not possible for us to do.

 

 

Hyper, you edited my post instead of replying.

 

Anyway, what I was getting at is that you're no longer assembly hacking old C&C executables; you could support loading old RA save games without having to structure RA++'s in-memory representations of those objects around them. I agree supporting old RA saves isn't worth the research and implementation effort, but I disagree that it's impossible. More to the point, I hope you don't stick with the RAM dump save format for RA++ native save games. I imagine writing INI format data and compressing it would work quite well.

 

It has nothing to do with 'hacking' the binary, Red Alert is coded in such a way that it is not possible for us to do so. We can not support save games.

[fir3w0rx]

Old save games? From the original RA1?... WHO THE HELL IS LOADING SAVE GAMES FROM 1996???!!! I probably wouldn't even remember WHY I saved it at that point. I'd understand fan-made missions that were made for the original; they should be made compatible... or maps, mods and things like that. I totally get the staying true to the original thing, but it's just weird how at this stage in development that this is already a hot topic

 

But I'm sure after this project is completed and released, someone here can make a third-party tool for converting old saves to whatever version you want anyway.

[SiRaLeX]

I agree with both CCHyper/Blade as well as LavenderMoon! Both make valid points. I don't doubt either of the guys competence. LavenderMoon has helped me find a function to redraw areas in RA2/YR.

 

 

More to the point, I hope you don't stick with the RAM dump save format for RA++ native save games. I imagine writing INI format data and compressing it would work quite well.

This is another good point by LavenderMoon. I just want to add, while INI might be a little clumsy (it's certainly possible) you guys can look into

Boost.Serialization.

It's an in typical boost manner template laden way to get your objects from your in memory representation to a xml/json/whatever represention that can be stored on disk which can be just as easily de-serialized again to your objects. 

 

I want to add that it is also portable, meaning that you won't have issues sharing "save games" between little-endian and big-endian machines. Sadly it also uses some C macros, AFAIK you can work around that, though, if you dislike it.

 

WARNING: Don't even think of abusing it for storing program setttings/options. I've done that once and I recall that it wasn't really pretty. It's for serializing objects, after all. Right?

 

[Nyerguds]

It'll be hard to make this compatible with modern hardware and software, while at the same time staying true to the original source code.

Why? Once they got it as source code, porting it to any system is peanuts. As I already mentioned, Dune Dynasty is a decompiled Dune II recompiled for Win32 and Linux.

 

Sure, graphics and sound output systems may differ a bit between systems... but once you got the source code, that's really not such a problem.

 

I imagine writing INI format data and compressing it would work quite well.

That doesn't seem very useful... O_o

 

Red Alert is coded in such a way that it is not possible for us to do so. We can not support save games.

Uh. You're gonna have to explain that one to me, Hyper. Unless you are drastically changing the internals, I really don't see why that wouldn't be possible.

[CCHyper]

Red Alert is coded in such a way that it is not possible for us to do so. We can not support save games.

Uh. You're gonna have to explain that one to me, Hyper. Unless you are drastically changing the internals, I really don't see why that wouldn't be possible.

 

It is just that, some internal classes will not be exactly the same size, and/or will not use the same storage type.

[fir3w0rx]

I'm surprised you guys haven't all gotten together yet and made your own rts game

[LavenderMoon]

I imagine writing INI format data and compressing it would work quite well.

That doesn't seem very useful... O_o

It would allow you to serialize the current game state in a format similar to the one used for initial map loading, and it would allow you to use the same logic for defaulting to initial values that the maps use. Storing only changed data would be a lot easier in a text-based format than using a binary format, though I suppose you could use Google's Protobuffer format or use a chunk-based format like Bethesda does for it's open-world games.

[SiRaLeX]

I concur with LavenderMoon. I'd still go with

Boost.Serialization,

though. If you want it to be noob-tamper safe, you could add a checksum or encrypt it.

 

Among other niceties it supports versioning (as does

ProtoBuf

). Sure

ProtoBuf

would work too but it's more a binary format for pushing messages over the network.  :ranting:

 

 

I'm surprised you guys haven't all gotten together yet and made your own rts game

Comedy!  :laugh: