LavenderMoon

Wow, that last one certainly looks nice! Good job on implementing them. Quick question: It's my understanding that C&C Gold, Westwood added files that contained precomputed bi-linear interpolations for each VQA. Does Red Alert do the same, or does it calculate the interpolation at run-time?

Not really. That format doesn't have any support for vehicles in motion situated in a certain specific position in between two cells. Not to mention their currently executing command and its specific properties.Oh, you'd definitely have to add in serialization information for those situations, but you could still use an extended version of the map loading format. From my understanding, a vehicle can't be in more than one cell at once, regardless of it's actual position on the map, so storing both a reference to it's current cell and a global map position or a X/Y offset in leptons from the current cell could both work. You can fake it with lists to other sections or by having a section that contains comma or semicolon separated values, but I agree that INI isn't as well suited to serializing a game state as other markup languages. I mainly suggested INI for the high code reuse it would allow. (Personally, my favorite markup language is a custom one I made, based off of the Universal Doom Map Format and ZDoom's DECORATE format, but I doubt it would get much adoption over YAML.)

I'm now another step closer to owning every* C&C game twice over. *Except Sole Survivor.

That doesn't seem very useful... O_oIt 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.

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.

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.

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

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

We're more trying to take the pulse of the project's goals.

My number one feature request would be right-click scrolling, like in TS and RA2. That's actually one of my biggest gripes with TD/RA1 (even more than lack of build queues) and with OpenRA's left-click orders mode. Another feature I'd like would be the replay missions feature from C&C64, where you could select any variant of any mission you'd completed (or unlocked?), making it useful for quickly booting up a mission or seeing the differences between variants. Of course, that mission where it loads your old base from another mission would throw a wrench into the works. How does that mission work if you somehow skip straight to it, anyway?

Why wouldn't it fit the bill for a ladder? Hello everyone, I'm Lavender Moon. I enjoy working on game engines (especially modular ones), and love programming in C#. I'm a huge fan of Command and Conquer, especially Tiberian Dawn and C&C3. I also love Dune 2000. I started playing C&C back on the N64, and it's easily one of my favorite series of all time.

I'm sorry you feel that way.

Smart plan. I'm looking forward to learning more about the more subtle differences between the two engines.

No one is saying that just because you can write a game in a language that it's a good idea. I'm saying writing games in C# is hardly a new thing, and that it's a proven platform. Have you heard of Xbox Live Indie Games on the Xbox 360? That used the .NET Framework and C#, on a platform that has less processing power and RAM than most computers in use today. Marshalling doesn't take up a significant amount of time in a well-designed real-time application. The more pertinent problem would be the cost of calling an unmanaged function from managed code, which is mostly safety checks. I'm hoping .NET Native will alleviate some of those problems in the future. So? It's good enough at it to not cause problems. C#'s strong suit is that it's a first-class citizen of the .NET Framework (arguably the first class citizen). It's strength is rapid application development without a significant amount of performance. You're right on that. I routinely hear MS's implementation referred to as ".NET" and Xamarin's as "Mono", so I assumed .NET was the name of the specific Microsoft implementation. My mistake. That reminds me, will this officially support Tiberian Dawn later down the line, or is this strictly Red Alert only?

Why? There's been quite a few games developed in C#, including Bastion, Transistor, Rogue Legacy, Apotheon, Dust: An Elysian Tail, etc. Additionally, games such as Guns of Icarus Online, Oddworld: New 'n' Tasty!, Pillars of Eternity, Shadowrun Returns, and Yooka-Laylee all use Unity, which uses Mono. I can't say for certain all those games were programmed in C#, but I'd say it's a 50% chance for each of them. We're not dying for raw speed anymore; the problem is that games are getting harder to maintain. Even the NES requires you to copy CHAR data from ROM to VRAM. What exactly are you getting at? PHP is slow, and optimized for generating web pages, not real-time interactive applications. It is also infamous for being so lax as to encourage hard-to-maintain code. Compare that to the tools that exist to help with refactoring C# code. No, they're forcing the CLR on their users, which is implemented by either .NET or Mono at the moment. That's good. Github has only been a blessing for C&C community projects in the past. Same here. Certainly going to enjoy playing Red Alert natively on Linux and FreeBSD. Is playing matches against players using the original .exes planned? I know that'd certainly be tough to do, but it'd be the ultimate proof of accuracy.