Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: ScottFreeCapital on April 13, 2015, 08:21:54 am
-
Hey all,
I'm a developer during my normal job and over the weekend I got curious enough about FSO to checkout the code from SVN (or for those not familiar with code: I just downloaded the code to see it). Honestly, there are a million questions that I was not able to immediately answer from looking at it, and some of it was vaguely explained just because I know the game. I was most curious about the AI so I took a look and found it's over 15.5 thousand lines long. :lol:
To the point: have we given any serious consideration to converting the C++ of the FS engine into a form that functions well within Unity or Unreal Engine 4? Unity, in particular, I've been working with for over 2 months with a side project and I've grown to love it, primarily because of the way everything works with components. Granted, you would have a lot of significant challenges, you'd immediately lose FRED2, and C++ does not necessarily just "translate" to C# right away.
But there are a number of huge gains too. Since I'm more familiar with Unity, I'll speak to those advantages:
- Unity, especially with its newest version 5, is available totally free to non-commercial pursuits
- Unity has a constantly evolving graphics capability and extreme extensibility (with custom shaders and such) at no cost of time or money, it just comes with upgraded versions
- Unity can do pretty much anything. I'm designing an RTS (real time strategy) game with it and if the code is efficient enough it can handle a pretty heavy workload (it can at least calculate physics on thousands of primitives simultaneously and not lose much frames per second on most modern systems). It does FPS genre games particularly well, and easily, which means the option of having genre-mixing in FS related projects
- It has a powerful new UI system - if anyone wanted, they could fairly easily redesign HUDs or make custom cockpit views with a low learning curve using the engine's editor
- Testing is super quick and easy - it can all happen in Unity's editor. Code compiles between every save and all metadata is maintained by Unity's software.
- This community has a giant library of existing assets (models, sprites, textures, and so on) to choose from and those can all be pretty easily imported into Unity. Blender/3dsmax/Maya, and other tools and their native formats all work well when importing into Unity.
- Super powerful cross platform support - you could potentially design stuff related to FreeSpace for iPad/other tablets, consoles, and so on. I realize this may not be appealing to a lot of PC gamers out there but it's certainly one option.
- The FS engine is old, really old, and as awesome as this community has been - FSO will continue to show its age over time despite the best efforts of good people who haven't been kept on a salary. At least, that's what I see as a likely scenario. Again, Unity is well maintained and is a widely adopted platform which will continue to evolve without any effort, etc. etc...
Having said that, there are a number of disadvantages I could acknowledge right away:
- Converting thousands and thousands of lines of C++ code into C# is no easy or straightforward task, and Unity/UE4 work totally different than the FSO engine
- C++ is probably more efficient at the end of the day, but losing a little bit of CPU related efficiency might be a worthy trade off when considering the larger benefits
- I realize this might be a hugely overambitious project - considering the number of mods that have died along with how long it takes to implement even "simple" looking features in FSO, there might just be too much work to really get this done
- FSO is already super mod friendly, and always has been. Switching to Unity or UE4 would immediately toss that out the window, requiring an entirely custom mod support solution to be built
- FS2's veteran modders and FSO participants would probably have a learning curve for Unity or UE4, and that's a lot of time within itself.
There are probably other things I'm not thinking of as well but considering that Unity/UE4 are totally free and they're both very powerful - I don't think there has ever been a better time to consider such an idea.
-
Hi. Yes, I have considered this idea. It's technically possible, but infeasible on the time and money budget that a small hobby project like ours has.
Thing is, FSO is really good at what it does. It has a comprehensive toolset for content creators, it is easy to work with (most of the time, anyway), and there's tons and tons of institutional knowledge of and about it. Switching engines entirely would invalidate all of it, and I wouldn't blame anyone for jumping ship if we did such a thing. Unless, of course, we would produce something that follows the spirit of FSO and can work as a drop-in replacement executable the same way FSO executables do now, but the amount of work required to produce something that can seamlessly and losslessly convert between FSO and Unity/UE is prohbitive.
-
It's technically possible, but infeasible on the time and money budget that a small hobby project like ours has.
:doubt: Oh.
So, what you're telling me is - if I want it to happen I'll have to start on it myself and probably end up making a brand new game in the process. And perhaps spend years on such a project. I might be cool to do that. Maybe.
-
Unfortunately, yes.
-
Fred 2 is a major asset. It really can't be overstated what a loss that would be to the modding community. Many Freders can script game events more efficiently than, I've heard, developers with many modern games.
-
Fred 2 is a major asset. It really can't be overstated what a loss that would be to the modding community. Many Freders can script game events more efficiently than, I've heard, developers with many modern games.
I'm certainly not suggesting getting rid of having a tool like FRED. But it wouldn't be the FRED most people know, I guess, and would be a brand new level design tool built from the ground up (most likely). Or, as E mentioned: you might have a lot of work to do to make everything compatible from older FSO files and things like that.
-
I don't think it's worth it. We use Unity at the studio I work at and if you're making a brand new game from scratch, it makes absolute sense to go to Unity.
But Freespace is what it is. It's a game engine with story-driven space combat as it's laser focus. There's no point in using it if you want something else out of it, especially when UE4 and Unity are available for free.
-
I don't think it's worth it. We use Unity at the studio I work at and if you're making a brand new game from scratch, it makes absolute sense to go to Unity.
Yeah, I guess thinking about it a bit more it's kind of like saying "let's make a new space sim in UE4 or Unity" just because FreeSpace is as much its engine as it is its IP, in a way.
Having said that, I think the next thing I'd want to build would be a Unity based space sim game, perhaps as a spiritual successor to FS or something similar. But one project at a time for me, gotta finish this prototype I'm working on first!
-
I also found that Unity has been really difficult to work with for large projects. Unity likes to arbitrarily mess with a lot of the variables saved in a scene file so all of a sudden a simple value change in one script component involves like 50 different lines in a scene file being affected. Merge conflicts end up being very frequent the larger your team size gets, not to mention merge conflicts with scene files are very difficult to resolve. At our studio, we had to resort to writing locking/unlocking plugins for Unity. Perhaps they fixed this in Unity 5 but our projects are still on 4 so we have yet to find out.
But yeah, I've thought about making my own commercial space sim with it's own game mechanic twists that couldn't be quickly implemented in Freespace Open because it would break a lot of assumptions the engine is expected to have (Mostly involving mission structure and meta game UI state). At that point, it very well be quicker to just look at the Freespace source for inspiration and code something much more leaner.
-
But yeah, I've thought about making my own commercial space sim with it's own game mechanic twists that couldn't be quickly implemented in Freespace Open because it would break a lot of assumptions the engine is expected to have (Mostly involving mission structure and meta game UI state). At that point, it very well be quicker to just look at the Freespace source for inspiration and code something much more leaner.
Could you elaborate on what you mean by "meta game UI state?"
Honestly, some of the biggest challenges I see being done in an FS like space sim created in Unity and then recreating a bunch of the AI / commanding wingmen, and so on.
And does anyone have any guesses on whether or not UE4 would work easier for larger projects? I know that EVE: Valkyrie, for example, was quickly switched to UE4 from Unity, perhaps because of some of the same reasons.
-
When I talk about meta game UI state, I'm talking about main halls, briefing windows, options menus, player select screens. That's all required to have a working Freespace mod. Like say you want to make like a space sim where the missions can be selected with an overworld map like Mass Effect or Destiny. Something like that is braindead simple in Unity or UE4. If you're coding this in Freespace, you have to worry about coding UI state systems that won't screw with the underlying assumptions the engine is expecting about which UI systems and assets need to be resident.
-
I would imagine for Unity and large projects it probably also depends on what kind of game you're actually building. Volition ( :v-old:) in particular has a video on their YouTube channel about constructing good AI that functions efficiently and one of their best tricks is reducing dependency as much as possible. This can be tricky and depending on the gameplay mechanics it can sometimes be downright impossible. With my own RTS design, I actually don't see a way to avoid a fairly thick level of dependency: resource economy, navigation/pathfinding, combat/population levels are all interlinked with each other to form the game itself - damaging one damages everything.
On the other hand - if you have a more modular sort of design and set of gameplay mechanics, this could probably work out well, FreeSpace included. For example, when ships actually have their own mechanisms of navigating instead of a "manager" type code that iterates through objects in the game world to make decisions. This is also easier said than done at times, though, as it usually involves fun things like making raycasts all over the place for each object. If you have a lot going on, that could mean requiring multi-threading to make it efficient. Some of the AI in Saint's Row works this way.
Come to think of it, perhaps such a thing could be used for collision avoidance in FSO. But that's beside the point.
The TLDR of it all: whether Unity works for large projects depends on those individual projects, I'd imagine.
-
When I talk about meta game UI state, I'm talking about main halls, briefing windows, options menus, player select screens. That's all required to have a working Freespace mod. Like say you want to make like a space sim where the missions can be selected with an overworld map like Mass Effect or Destiny. Something like that is braindead simple in Unity or UE4. If you're coding this in Freespace, you have to worry about coding UI state systems that won't screw with the underlying assumptions the engine is expecting about which UI systems and assets need to be resident.
On the other hand...
-
Does anyone know who did this? This is using FreeSpace assets in a space sim prototype.
-
have you tried actually looking at the profile of the user that uploaded that video
-
As far as all of this looks beautiful and Quite optimistic... Won't Interplay rampage on any attempt about FREE game based on their (owned) game?
-
They haven't done so to date and we're already undercutting their sales of FS1 with FSPort, so who knows.
-
As far as all of this looks beautiful and Quite optimistic... Won't Interplay rampage on any attempt about FREE game based on their (owned) game?
From the video description "...all the ship models and most of the sounds are borrowed from the FS2 SCP Media VPs. I'm using them as placeholders until I get to an advanced enough place where I need to start using my own original placeholders."
-
have you tried actually looking at the profile of the user that uploaded that video
:lol: :mad2:
I was kind of wondering if it was someone obvious on this forum.
Kind of curious, that's all. I guess if the guy (or gal, I dunno) is making a different game then they're making a different game.
-
in case anyone maybe still watching this thread. Im currently working on an ambitious project, part freespace, part 1st person shooter. using unity. i am using freespace as a starting off point, using the space combat kit from the unity asset store. its relatively cheap for what it provides. im working on a way to import freespace mission files right now. then parsing that data to connect to the kits code, like mission objectives and such. not sure if it will work seamlessly (hopeful), but its a start.
-
Although the frewspace engine was released as open source, the game assets are definitely still retail property.
-
i know the assets are not free. im testing out using the retail mission files as to make it easier for say anyone that has mods to import or just anyone that wants to use FRED to make missions. as well its also a learning experience for me.