Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Phaserbank on June 06, 2010, 02:06:14 pm
-
I'm not sure how far along 3.6.13 is, but how about making the player a person that can climb into fighters or bombers, manuely dock with capital ships, can carry handheld weapons, and move, run jump ect, around larger vessels. I know this would mean almost redoing freespace, but what do ya'll think?
Basicly combining Freespace, which is the best simulator, with an fps like wolfenstein et, which is the most fun fps.
-
I'm not sure how far along 3.6.13 is, but how about making the player a person that can climb into fighters or bombers, manuely dock with capital ships, can carry handheld weapons, and move, run jump ect, around larger vessels. I know this would mean almost redoing freespace, but what do ya'll think?
Basicly combining Freespace, which is the best simulator, with an fps like wolfenstein et, which is the most fun fps.
Sorry, it's a nice dream, but it will never be feasible and definitely not in 3.6.13.
Not only is the code required impossible to easily achieve in the FS engine, but you're talking about creating new assets as well.
-
FPS emulation was planned at some point, but never implemented by anybody and is most likely completely forgotten now.
You can try to use LUA scripting to do that, but you'd need to be either as good as Nuke, or ask him if he plans on doing that (I recall that he might have mentioned it, but I'm unsure).
-
FSO is definitely the wrong engine to do FPS stuff in.
-
For that matter, what part of "Unless you are an SCP coder you should not post on this thread" confused you? :p
Thread split.
-
Rudimentary FPS emulation (emphasis on rudimentary) is on the nebulous list of "wouldn't it be cool" ideas that might possibly be experimented with at some point. But at the very least, it would depend on Bobboau's animation code being fixed.
Also, I can't quite comprehend the confusion of ideas that could produce this juxtaposition...
I'm not sure how far along 3.6.13 is
...
I know this would mean almost redoing freespace
-
Oh sure, we can do that. And let's make it compatible with Team Fortress 2, that's a good game and lots of people play it.
-
In fact, FPS emulation would basically require three things: expanded animation code (this can also be done with LUA scripts) and system that allows to make an object "stick" to the surface (which would also be usefull for things like tanks) and AI capable of handling that sort of gameplay (the biggest problem with most similar innovations). I'd also like to add that if we had those things, it would allow introdution of proper tanks, walkers and infantry, which, combined with atmospheric flight script, would in turn allow for some very interesting atmospheric mission scenarios.
In other words, it may become possible when other improvements are being made (since everybody knows that animation code needs an overhaul, gravity system is also something that may be implemented and AI problems may not be as severe as they seem, since I made some hover tanks and they worked).
Also, in case of 0-G FPS, the only thing needed may be the improved animation code and some AI improvements to stop them from bumping into walls all the time. (of course, that's from the coding POV, making assets for it is a different can of worms).
-
I would advise to forget about this as fast as possible. We do NOT have the coders to pull something like this off.
-
all it would take to accomplish this is a skilled and motivated scripter and a couple weeks.
unfortunately the only one who could pull it off is currently taking an extended break from reality.
-
Weren't you already working or something like FPS emulation?
(Heh, I knew that you'll post here sonner or later. :) )
Anyway, improwing animation code to allow such things as complex movement for mechs would be really usefull (heck, I think that just expanding it to enable triggering on movement would allow for basic human of mecha models to work, although it'd most likely look fake at first).
-
The Unreal SDK already has what you want.
-
I would advise to forget about this as fast as possible. We do NOT have the coders to pull something like this off.
It seems that most of the "big" features added in FSO have been made by single programmers rather than "the team". AFAIK OpenGL support was pretty much single-handedly added by Bobboau, shader support almost single-handedly by Taylor, and Lua scripting almost single-handedly by WMCoolmon.
All of those features have of course been improved and expanded upon over time. Working alone, it would only take one person a few weeks to put a working in-engine prototype together. If they made sure to keep their code properly updated as they were working on it, merging the changes would take minimal additional work. Additional testing would be possible post-merge, and the feature could be improved and expanded upon once the modders know how to use it, and how they would like to be able to use it.
-
I am intrigued. I would very much like to see this weekly schedule you seem to have put together, with its accompanying testing/merging plan. Have you accounted for the integration with the existing code, as well as the need to plan around existing personal and work-related commitments?
And what OpenGL support have you uncovered that has been authored by Bobboau? I would like to see this code, as seems to be missing from SVN. We should remedy that as soon as possible.
-
:rolleyes:
-
the biggest problem with fps is probably going to be character models and the collision there of. pof specs are somewhat limited with the length of object chains you can use, also limitations with the bounding boxes and the way the game uses them. parent bounding boxes would need to contain all tier own geometry and the geometry of children. the result is larger than necessary radiuses and bounding boxes resulting in more collision tests per object, slowing the system down.
might be faster to radius test each subobject independently and if that check passes, then transform the projectile into each subobject's local space for the bounding box test and tree traversal. of course this requires more transforms. since its more efficient (for collision detection) to keep radiuses and bounding boxes as small as possible to avoid unnecessary tests, it is better to keep the geometric center as close to the actual center of the object (probibly requiring each independent subobject to have a 4x4 transform matrix) to allow for the smallest possible radius and bounding box.
you would then need to have at least an independent rotation center at most a complete skeletal system. every time an object moves about its joint, new transform for the subobject is calculated and children inherit the transform of their parents. then when something hits a subobject you have enough data to transform the colliding object into the colidee's space for bounding box and collision tree tests. important thing is you dont test every single subobject, merely the ones that are most likely to collide.
seems like a lot more math, but considering that there would be very few things such character models would need to be collide tested with, small weapons, the current room geometry or any other objects that are in the way (ships), it becomes faster. of course most of this is overkill if you dont mind an antique looking fps engine. something about on par with quake 2/3 would be adequate since it wouldnt be used primarily as an fps game. i could probably do something at about a quake 1 level with lua, if you dont mind that level of lameness.
i sorta wrote a doom-esque floorplan system in lua to confine the movement of a player to a planar object, however this system is currently external to freespace. you would need to model rooms of a ship in the same manor as cockpit models then kinda make a 2d map of all walkable areas so you wouldnt need to actually test collide against the ship geometry for general walking around. the test of the system is available here (http://nukedspace.fsmods.net/nuke2d.rar) in 2d form. every 2d object is assumed to be at a uniform elevation, but you can use groups of them to create stairs and ramps and whatnot. you can also do under/overlaping so you can create bridges and multiple levels (unlike doom). its still kinda quirky but i bet it will work better/faster in freespace.
-
The Unreal SDK already has what you want.
I was going to say the same. I've actually been working with the UDK for my University work this year (Games Design degree) and its pretty powerfull. Uses C# coding i think. You'd probably have better luck bringing the Freespace components you want into the SDK rather than attempting to put FPS into Freespace. There are aircraft in the game and i recall one of the UT2004 maps involved a fight in space fighters, so it should be able to support it. Was meaning to mention this to the Freespace FPS project too.
http://www.udk.com/
Alternatively, if they ever release the source code for it (which is sadly unlikely), an old game called 'Freelancer' could prove a good engine for implimenting your project idea, though in the original form you can't move around the player character.
-
Would it be theoretically possible to combine two engines into a single game? Such as, before each mission, the mission designer specifies wheter a mission is a FS2-type space flight mission or a UDK FPS mission, and the respective engine launches itself without exiting.
Or is the mainhall/briefing room inseperable from the flight engine?
-
Would it be theoretically possible to combine two engines into a single game? Such as, before each mission, the mission designer specifies wheter a mission is a FS2-type space flight mission or a UDK FPS mission, and the respective engine launches itself without exiting.
Or is the mainhall/briefing room inseperable from the flight engine?
ugh
-
In theory, it is possible.
In reality, it would mean creating an ugly, hackish mess.
Seriously, it's probably easier to transform the UDK into a flight sim than to try and hack together something like that.
-
The UDK has _already_ been transformed into a flight sim, so yes, it is easier.