PopsiclePete
Mission programmer
Of course, I meant making WC1&2 in 3D.
Gauging interest in a remaster
- Thread starter Pedro
- Start date
Pedro
Admiral
My bad, from the way it was written I was thinking you meant something like Wings of St Nazaire - which does to be fair look amazing.
PopsiclePete
Mission programmer
Well, if it was only up to me, if we'd redo WC4 it would most likely be cockpit-less because 1) it's easier to adapt to widescreen and 2) we'd want to be faithful to the original and since we've never seen the original cockpit art for most of the playable ships in WC4, we'd have to create new stuff.
Pedro
Admiral
I'm inclined to agree.
Again it will be open source so people will be free make add-ons and mods, but the use of two colored versions of one HUD makes WCIV an easier endeavor. That said if I did add cockpits (which I won't) I'd opt for 3D models so widescreen wouldn't be a huge issue.
Easier to do than for WCIII as they started to add nebulas to the FMV. Should be possible to make it look more WCP style. One concern is they kept using the same color nebula...
DefianceIndustries
Rear Admiral
Don't forget the Vindicator.
FekLeyrTarg
Rear Admiral
Hmmm.... didn't we also see part of a Banshee's cockpit in the scene in which "Moose" gets shot down in Peleus?
(I also recall that Scooby built one for his high detailed Bearcat)
While I agree that for a first release, rebuilding the original HUDs (which can be done easily in any vector graphics program like Illustrator) makes sense, I'd love to have full 360° 3D cockpits with support for both TrackIR/FreeTrack and Virtual Reality at a later point, be it as part of a later release or as a mod.
What I also like to see, is some rebalancing, especially by nerfing the overpowered missiles back to WC3-standards.
Just to give you guys some inspiration, I'll link here a video of the aforementioned "X-Wing Virtual Machine", which is basically a project similar to what you're proposing.
(I also recall that Scooby built one for his high detailed Bearcat)
While I agree that for a first release, rebuilding the original HUDs (which can be done easily in any vector graphics program like Illustrator) makes sense, I'd love to have full 360° 3D cockpits with support for both TrackIR/FreeTrack and Virtual Reality at a later point, be it as part of a later release or as a mod.
What I also like to see, is some rebalancing, especially by nerfing the overpowered missiles back to WC3-standards.
Just to give you guys some inspiration, I'll link here a video of the aforementioned "X-Wing Virtual Machine", which is basically a project similar to what you're proposing.
Bitterman
Commodore
Last edited by a moderator:
Quarto
Unknown Enemy
Some very quick thoughts, as I really shouldn't be spending time even visiting the CZ at this point, let alone commenting interesting topics like this one 
.
1. Which game is, for the moment, irrelevant. All WC titles share the same basic structure. You'll still be preparing a basic spaceflight engine, and a basic gameflow engine. Only once you've got the basics does the question of "which game" really become relevant. The details that differ between games are just that - details.
2. When you do get to that point, you'll probably find that the choice of game has already been made. As you've said, there's a lot of assets that need to be remade, and this is contingent on having graphics artists willing to do the job. As you develop the engine, you'll see that in the meantime, some people are indeed gathering resources for particular games - and not for others. Choice made
.
3. All that having been said, it's very clear that you're going to wind up with WC3 or WC4 as the remake in the first instance, because those are the ones that are most likely to find enough people willing to do the assets. I mean, WC1/2 is not just about ships. Somebody's gotta do the people, too - which means modelling them, animating them, etc. For that, you'd need... you know, nutcases like us, willing to slog along for a decade making a whole complete game. And chances are, if you do find those nutcases like us (it may well be us!), they actually won't be as interested in a WC1/2 remake as in a WC1/2-inspired game. Like, ahem, Standoff. Clearly, though, that's something that can only happen at a later stage. Oh, and also - since WC4 has DVD-quality footage while WC3 does not, I'd say you already know who wins.
So.... after the three points above, this last one may seem like it's coming out of nowhere, but...
4. The game you should be aiming to remake is, of course, WCP/Secret Ops. Of all the WC games, it's got the most well-developed structure. If you re-create the gameflow and spaceflight functionality of Secret Ops, you can build any WC game at all on top of that. For additional inspiration, look to StarCraft II, which has a very nice, modern implementation of WC-style gameflow with hotspots that activate cutscenes and the like (but with 3d models instead of pre-rendered).
So, my recommendation is that you start working with SO in order to develop the basics of the game engine, and then as you get closer to the point where you've got all that, start working on whichever game is most likely to actually have the assets - and then adjust the basic engine to imitate as closely as possible the gameplay of the original, while retaining the flexibility for other types of gameplay.
Incidentally, if it wasn't for the fact that I cannot foresee a near-term or even medium-term future where I have time for WC modding, I'd totally go for a WC4-inspired game (but not for WC4 as such, which is... blah).
.1. Which game is, for the moment, irrelevant. All WC titles share the same basic structure. You'll still be preparing a basic spaceflight engine, and a basic gameflow engine. Only once you've got the basics does the question of "which game" really become relevant. The details that differ between games are just that - details.
2. When you do get to that point, you'll probably find that the choice of game has already been made. As you've said, there's a lot of assets that need to be remade, and this is contingent on having graphics artists willing to do the job. As you develop the engine, you'll see that in the meantime, some people are indeed gathering resources for particular games - and not for others. Choice made
.3. All that having been said, it's very clear that you're going to wind up with WC3 or WC4 as the remake in the first instance, because those are the ones that are most likely to find enough people willing to do the assets. I mean, WC1/2 is not just about ships. Somebody's gotta do the people, too - which means modelling them, animating them, etc. For that, you'd need... you know, nutcases like us, willing to slog along for a decade making a whole complete game. And chances are, if you do find those nutcases like us (it may well be us!), they actually won't be as interested in a WC1/2 remake as in a WC1/2-inspired game. Like, ahem, Standoff. Clearly, though, that's something that can only happen at a later stage. Oh, and also - since WC4 has DVD-quality footage while WC3 does not, I'd say you already know who wins.
So.... after the three points above, this last one may seem like it's coming out of nowhere, but...
4. The game you should be aiming to remake is, of course, WCP/Secret Ops. Of all the WC games, it's got the most well-developed structure. If you re-create the gameflow and spaceflight functionality of Secret Ops, you can build any WC game at all on top of that. For additional inspiration, look to StarCraft II, which has a very nice, modern implementation of WC-style gameflow with hotspots that activate cutscenes and the like (but with 3d models instead of pre-rendered).
So, my recommendation is that you start working with SO in order to develop the basics of the game engine, and then as you get closer to the point where you've got all that, start working on whichever game is most likely to actually have the assets - and then adjust the basic engine to imitate as closely as possible the gameplay of the original, while retaining the flexibility for other types of gameplay.
Incidentally, if it wasn't for the fact that I cannot foresee a near-term or even medium-term future where I have time for WC modding, I'd totally go for a WC4-inspired game (but not for WC4 as such, which is... blah).
Pedro
Admiral
Some very quick thoughts, as I really shouldn't be spending time even visiting the CZ at this point, let alone commenting interesting topics like this one
....
1. My biggest task with the engine right now is actually removing things that can't be made public. The level editor is in real need of an overhaul but that's not relevant for a task like this. The UI and model formats as they were built on proprietary tools so they have to be taken out. The UI obviously won't be needed if supporting the original formats (atleast temporarily). I do need to make a new model exporter but since the aim is to use the original assets the question of which game is going to come up incredibly quickly.
The design of the engine was to minimize code - behaviour is driven by data as much as possible. For example I don't think there was a projectile system, just components like Trasform, Matrix, Lifetime, MaxLifeTime, PhysicsComponent, CollisionSphere, DamageOnCollision, ConstantForce and the various systems which made use of them. There was perhaps a projectile component but I think it was just used for the OnCollision result, no systems made use of it.
Those are all basic components located in the engine so lasers and missiles would be largely code free.
I could press ahead and get some basic functionality in place without deciding on a game but I definitely don't think I *need* to, or even would be well served by doing so. Even the AI, there was nothing game specific about our behaviour trees, although I would perhaps need to tweak it to handle flight.
2. I'll come back to this for point 4
3. I agree with the points here, except I'm not convinced there is less interest in WC1 and 2, just not the additional interest required to offset the additional work.
so as a result I'm not to sure about point number...
4. I take the point, but I would find it very hard to get motivated about such a project for almost the same reasons you suggest doing it - those are the most well developed games (and the most modded). It's also worth noting that whilst WCP/SO were smoother engines in some ways it was less ambitious (no ground missions, flying inside nebulas, tractor beams, jamming, or getting drunk). There are additional features (components and targeting of them immediately springing to mind) but I'm reasonably confident baring those in mind would be sufficient to ensure they can be implemented at a later date.
3D hotspots are a nice idea for Secret Ops and WC1/2 but for the rest of the titles the low res images have to stay as I wouldn't want jarring transitions from dodgy 3D models to FMV. I think the file formats will drive a lot of this, there will be core systems but there will be common code but that's just good design.
Quarto
Unknown Enemy
I suspect we have different definitions of what basics are in this case, which undoubtedly stems from our different dev backgrounds. From a programmer's perspective, you may well already have everything except the game-specific stuff. From a designer's perspective, you've got... Unity. A designer sits down to Unity, and breaks down in tears, because it turns out that he's got all this functionality, but needs to write a ton of code to unlock it. And when he says this to the programmer, the programmer gets angry and says that there's no code whatsoever to be written, because it's all just Java or C# or whatever, and that's not really programming. But to the designer... it is
.What I, as a designer, have in mind when I talk about having basic spaceflight and basic gameflow, is a complete structure that's basically ready for assets and tweaking. In other words, I can already insert gameflow rooms with some sort of hotspot system to activate videos, I can already build a sophisticated mission tree with variable-based branching, I've got basic killboard and object viewer systems, and I've got a working spaceflight where I can fly a ship, I can define a set of guns, a set of missiles, a set of ships, and script a mission (note: when I say "script", I don't necessarily mean it must be written in script like in the original WC games - I'm not hostile to innovations like Kismet-style visual scripting and the like). So basically, I have everything I need to make a generic WC game - and I have the possibility of tweaking all the data I would need to tweak in order to make a particular WC game. The tweaking actually involves surprisingly little - most of the time it's just stats and such, but there's also other things like how collisions work (do ships bounce off each other WCP-style, or crash into each other like earlier games?), how capships work (torps/shields/etc.), and all that.
To be clear, I think there's a lot more interest in playing a WC1/2 remake than in a WC3/4 remake. It's just the interest in making it that's a problem. And even there, the problem is only partial. I think even now, if we wanted to, we could easily find at least Standoff-quality models (which aren't quite what we should be aiming for, but it's a start) for all WC1/2 ships, and for many of them we'll find Klavs-level or Howard Day-level quality models. But when we start talking about who can make us a bunch of really good 3D people with really good animations, the response will come in the sound that crickets make out in the middle of nowhere.
Yes, well, this brings us back to programmer vs. designer thinking, I think. I'm certainly not saying literally you should remake WCP/SO - that would be indeed boring, and indeed a waste of your time. What I'm saying is that you should aim to develop the game on top of your engine to the point where it can match all the functionality of WCP/SO. And not even so much in terms of what's exactly in there, but in terms of what a designer can do. Like, in WCP, as a designer I get a bunch of really sophisticated tools that enable me to build the specific game I want to build without having to code anything. I get files with missile/gun/ship/pilot/etc. data, without ever having to sit down and write
Absolutely. Being able to use either 3D models in the background or 2D images is vital for WC remakes. Without visual consistency, you got nothing.
Pedro
Admiral
I suspect we have different definitions of what basics are in this case, which undoubtedly stems from our different dev backgrounds. From a programmer's perspective, you may well already have everything except the game-specific stuff. From a designer's perspective, you've got... Unity. A designer sits down to Unity, and breaks down in tears, because it turns out that he's got all this functionality, but needs to write a ton of code to unlock it. And when he says this to the programmer, the programmer gets angry and says that there's no code whatsoever to be written, because it's all just Java or C# or whatever, and that's not really programming. But to the designer... it is
What I, as a designer, have in mind when I talk about having basic spaceflight and basic gameflow, is a complete structure that's basically ready for assets and tweaking. In other words, I can already insert gameflow rooms with some sort of hotspot system to activate videos, I can already build a sophisticated mission tree with variable-based branching, I've got basic killboard and object viewer systems, and I've got a working spaceflight where I can fly a ship, I can define a set of guns, a set of missiles, a set of ships, and script a mission (note: when I say "script", I don't necessarily mean it must be written in script like in the original WC games - I'm not hostile to innovations like Kismet-style visual scripting and the like). So basically, I have everything I need to make a generic WC game - and I have the possibility of tweaking all the data I would need to tweak in order to make a particular WC game. The tweaking actually involves surprisingly little - most of the time it's just stats and such, but there's also other things like how collisions work (do ships bounce off each other WCP-style, or crash into each other like earlier games?), how capships work (torps/shields/etc.), and all that.
Oh believe you me I understand that difference in viewpoint - it's one we wrestled with for years. The last two projects - one was internal engine, one was Unity. The Unity one had funding pulled in no small part due to performance issues. The internal engine one was released but not without the designers practically mutinying because they wanted Unity (and we intentionally constrained what the designers could do, we only let them place objects, edit data and code *missions*, not gameplay code. They hated it but our debug period was 1/3rd as long as the previous title as a result. There is bitterness on both sides there - they never realized we spent three times as long fixing what they wrote than they ever spent writing it (longer when you factor in the consequences of the spaghetti code) on the previous project and seemed to be of the view we were tying their hands for some ulterior motive.
Still it's a conversation I'm bored of, and stressed out by... which is precisely why I picked a remake. If you want to make a brand spanking new game from scratch with a full tool set, you have options, and you have my blessing, but it's not what I'm proposing.
My motivations for this project aren't just to do a Wing Commander project, but also to have a game in progress to ensure I'm not breaking code as I move towards open sourcing the engine. I want to open source in order to demonstrate a new coding paradigm - not to offer a unity replacement. A remake is a great option for that purpose as I don't have to devote my life to tools. A custom engine is good for a remake as it's much easier to use the existing assets rather trying to put a square peg into a round hole.
All of the options you mentioned are ofcourse tweakable in data - but with the aim to use existing data I don't intend to use the level editor which is where they were designed to be edited (which like Unreal does formats them to be more human readable), the editor is a big slab of code that isn't necessary (and was the most incomplete aspect) - I know this is going to cause a designer to scream, but that means they'll have to be edited in text. For example collision detection and response components look like:
RigidBody:
bDynamic: true
bEnableCCD: true
fDensity: 5
bDisableGravity: true
fLinearDamping: 0.0
fAngularDamping: 2
BoxCollider:
vCenter: {x: 0.0, y: 0.4, z: 0.0}
vExtents: {x: 0.5, y: 0.4, z: 1.0}
material:
fDynamicFriction: 0.500
fStaticFriction: 0.50
fBounciness: 0.025
eRestitutionCombineMode: <%= Usg::CombineMode::MIN %>
I could separate out the code for modifiying entities into a separate tool, but to be honest as a remake I didn't envision there being enough tweaking work to get anyone to help me out with that side of the project, I was just going to do it myself.
Internally we switched over to using PhysX so in terms of physics there is plenty more we can expose.
Now I'm not thinking about making a new game, it's not what I'm proposing, which is why there is no task on my list about a hotspot editor. I am going to use the original definitions whereever possible. So beyond the programmer designer divide I feel like you're also keen to see original content?
Again - all of those files already exist. We do have from one of the WCP dev CDs in the CIC archieve which had a number of those tools (including the level editor) - but even if we could edit that data, I'd feel uncomfortable doing so for a remaster.
Last edited:
Quarto
Unknown Enemy
Quite honestly, I'm trying to look at this as an innocent bystander, because that's ultimately all I can be on this project. I wish I had time to be actually involved in projects like this, but all I can do is stand on the sidelines and offer advice. So, in that sense, I'm not really keen to see original content or unoriginal content - though I do hope that we will end up seeing both.
It doesn't seem like we're understanding each other, though. I'm not saying you need to develop tools. I would actually be very happy with text-based editing for most things - if anything, I was expecting you to say that this would be an outdated, 1990s approach, and you want to do something more than that. But if you don't, that's fine - as I've said before, I'm open to things like Kismet-style visual editing... but I will add that I don't see the point of it, because it feels like you need fifty thousand clicks just to do the equivalent of three lines of script. That having been said, I think you'll find that some simple tools will prove worthwhile, because they'll save you time. As a rule, the more programmer-friendly a game is, the more work it demands from programmers by making life harder for others.
What does concern me is precisely the kind of data dump you post above. It's ugly, it's nasty, it's hard to understand, and a lot of it is not relevant to a designer. This is why I think WCP/SO is such a great game to look at when you're thinking of remakes: because it had wonderful, beautiful data structures, where all that the designer needs to be able to change is accessible - while all the rest is tucked away out of harm's way. Most of the stuff you showed above would have been in the executable (although it'd probably be better in a big ini file of some sort). Only those items that actually differ between individual objects in the game were editable on the designer's end. I think this is good, because it allows the programmer to shift work onto designers, without getting in return the kind of horrible debugging you mentioned.
I suspect that overall, given your comments about designers favouring Unity, we actually agree more than we disagree. What bothers me about Unity is precisely what bothers you - that designers end up coding stuff, which is frustrating for both sides. Unity is an engine on which a game (or game engine) can be built, but it is not a game engine in and of itself.
So, let me reiterate again - it's not the files I care about, it's their structure - which data we have access to, and how. They are really well designed precisely in the context of the programmer/designer divide. With the exception of a few really silly things (i.e. the hardcoded limits on number of ship types and the like), working with WCP/SO I always felt like I've got access to absolutely everything I could need to implement content - and at the same time, I don't have to deal with anything unnecessary that could lead to needless screw-ups.
Pedro
Admiral
Interesting.
As for the variables not being designer friendly or not being necessary to edit I think it's worth mentioning that it uses an inheritance based system. You don't need to override *any* values. Typically what would happen is a programmer would fill out a few common base definitions.
Designers and artists would make a new file which inherited all of those values and only overrode the values they cared about.
So I might make BaseFighter with those values and then a designer would make another file, call it LightFighter that just
[Inherits BaseFighter]
They could then just change say the mass, and leave everything else the same
RigidBody:
fMass: 2.0
Then another file Hellcat that only edits the model
[Inherits LightFighter]
ModelComponent:
name: Hellcat/WingIVVariant
Also I apologise, the forums are losing the formatting, the original file is all indented and its a format called yaml with highlighting in most good text editors. They would never touch the BaseFighter file, just override the things they care about.
The one thing that made it not friendly to designers was the hungarian notation (prefix of data type), which the editor automatically would remove. Given that those yaml files did get edited by artists and designers more than intended I wish we hadn't used hungarian notion for the variables. There was also support for tooltips (in both English and Japanese) but we kept forgetting to fill them out.
I still plan to use the original formats, but they'll need to be supplemented.
Blueprints - the replacement to Kismet... yeah. Sometimes they work well, sometimes they are a hinderance.
For things like anim graphs which would normally be data they work well, but for code... it just seems to make everything more convoluted. The one nice thing kismet does is hide how hideous and old-school UE4's internal code is.
Now that I understand what you're saying it's an interesting point, and yes we are in sync. Hiding what isn't needed. It's not something I've ever been *asked* to do before, hence why you took me by surprise. All the designers wanted more control, but it is something I push for to reduce the introduction of bugs.
I'll give some thought about if there is any way to force hiding data.
I suppose the ideal from a designers perspective would be presets well suited to the game, such as "LowBounce", "HighBounce", hiding the specific values from the designer?
As for the variables not being designer friendly or not being necessary to edit I think it's worth mentioning that it uses an inheritance based system. You don't need to override *any* values. Typically what would happen is a programmer would fill out a few common base definitions.
Designers and artists would make a new file which inherited all of those values and only overrode the values they cared about.
So I might make BaseFighter with those values and then a designer would make another file, call it LightFighter that just
[Inherits BaseFighter]
They could then just change say the mass, and leave everything else the same
RigidBody:
fMass: 2.0
Then another file Hellcat that only edits the model
[Inherits LightFighter]
ModelComponent:
name: Hellcat/WingIVVariant
Also I apologise, the forums are losing the formatting, the original file is all indented and its a format called yaml with highlighting in most good text editors. They would never touch the BaseFighter file, just override the things they care about.
The one thing that made it not friendly to designers was the hungarian notation (prefix of data type), which the editor automatically would remove. Given that those yaml files did get edited by artists and designers more than intended I wish we hadn't used hungarian notion for the variables. There was also support for tooltips (in both English and Japanese) but we kept forgetting to fill them out.
I still plan to use the original formats, but they'll need to be supplemented.
Blueprints - the replacement to Kismet... yeah. Sometimes they work well, sometimes they are a hinderance.
For things like anim graphs which would normally be data they work well, but for code... it just seems to make everything more convoluted. The one nice thing kismet does is hide how hideous and old-school UE4's internal code is.
Now that I understand what you're saying it's an interesting point, and yes we are in sync. Hiding what isn't needed. It's not something I've ever been *asked* to do before, hence why you took me by surprise. All the designers wanted more control, but it is something I push for to reduce the introduction of bugs.
I'll give some thought about if there is any way to force hiding data.
I suppose the ideal from a designers perspective would be presets well suited to the game, such as "LowBounce", "HighBounce", hiding the specific values from the designer?
Last edited:
Hah, Quarto just laid out exactly why Vegastrike failed. The game had a great engine with lots of features, but absolutely no gameflow/design assistance tools worth a damn. You had to be a programmer to unlock any of the functionality of that engine. Editing tools are king. It's why there's thousands of mods for freespace 2, and only a few dozen for Wing Commander.
DefianceIndustries
Rear Admiral
Well sometimes Mods drive tools. The Model Upgrade pack project has been the genesis of several new tools including a much improved collision tree maker over the older "C" series of tools. I do follow your point, FRED makes mission design easier than hand-coding it in Pascal, and nobody truly knows how MED actually works (though I'm trying to piece it together). However there's also a false comparison here, FS is open source (now), and FS was distributed with FRED by Volition - everything done in Prophecy/Secret Ops is hacked into the closed source engine by hook or by crook. It's a hell of alot easier to build tools when you can see the code underneath.
Tools do make the game more accessible, no doubt.
Pedro
Admiral
To be fair there are tools based on Sony's open source ATF framework and associated level editor. There's also scripting based in LUA which is more powerful than what SO had available, but when I proposed the system I was heavily thinking about the kind of missions we made for UE and Standoff and what was needed.
As DefianceIndustries says, I'd love to see that side of the engine picked up - and that becomes more likely after a successful project. I'm not incapable in tools (although it's not my strong point), I'm just trying to be realistic and not bite off more than I can chew.
I don't want to try and recruit too many people before I can convince others (and myself, I still worry about the time I can find) that this is all feasible. I atleast want to tackle up to the end of the first mission with as little outside help as possible.
As DefianceIndustries says, I'd love to see that side of the engine picked up - and that becomes more likely after a successful project. I'm not incapable in tools (although it's not my strong point), I'm just trying to be realistic and not bite off more than I can chew.
I don't want to try and recruit too many people before I can convince others (and myself, I still worry about the time I can find) that this is all feasible. I atleast want to tackle up to the end of the first mission with as little outside help as possible.