Frontier: Deadly, aka "Never Go Full Newtonian"

[Armour]

We are well on our way to having Elite: Dangerous to play. However, there is a sizeable contingent of hardcore fans of Frontier: Elite 2 and it's sequel Frontier: First Encounters that seems to be disappointed that the new game doesn't have a fully Newtonian flight model.

(I propose calling such a flight model an "NFM" in future posts, to save fingers).

Given those facts, let's discuss the idea of how to implement an NFM in a new game, one using the same multiplayer P2P architecture that Elite: Dangerous relies upon.

This already-existing thread offers a good starting point, but this new thread isn't lobbying for changes to any existing game.

Here, we can discuss (and maybe even have a go at implementing) a possible new game, without any of the baggage.

Ideas?

 

[QuantumTron]

I propose we call this new game "Final Frontier" - at least as a project name

 

[Philip Coutts]

I think this thread is a great idea. It's clear that ED is not going to have a fully Newtonian flight model so discussing it is probably futile. What isn't futile is coming up with a game that is fully Newtonian. Good luck.

 

[Mike Evans]

To be honest I would rather the game didn't use a p2p network structure nor be aimed at being massively multiplayer. I would think a game that you can invite people to play with you in that you then become the host server and ultimate authority would give you all the multiplayer you could want with none of the downsides of p2p.

In that way you could perhaps have your own servers for like minded people to join and play ran by someone else.

Either way a think a lot of problems with matching real people together can be mitigated if people are prepared to accept the AI could be used to always create nearby stuff where it's appropriate like in Frontier. Bumping into someone in deep space seems very unlikely unless you can detect them from much much farther away in the first place. Either way a solid AI and AI manager would be needed to ensure a good experience regardless of real player count.

 

[laforge]

Nice idea to have such a thread, but I think in regards of the gameplay nearly everything is already said

I propose we call this new game "Final Frontier" - at least as a project name

That would be an awesome name!

 

[QuantumTron]

Regarding networking, there's a very informative series of articles here .

Edit : It seems that a good method is to use client-side prediction, with a central server as a final deciding "judge", should game clients differ in opinion on What Just Happened.

You might be able to take Mike's suggestion of a P2P server, and having a "best node" be the server and the final arbiter between other client's predictions.

 

[Fenris Wolf]

I propose we call this new game "Final Frontier" - at least as a project name

That would be an awesome name!

Very doubtful that you would be allowed to use it due to the Star Trek connection... pity though

 

[QuantumTron]

Very doubtful that you would be allowed to use it due to the Star Trek connection... pity though

IANAL, but I reckon just using "Final Frontier" wouldn't be infringing on anyone's trademarks or copyright.

 

[Mike Evans]

IANAL, but I reckon just using "Final Frontier" wouldn't be infringing on anyone's trademarks or copyright.

"Frontier Final" has a kind of Japanese translated into English ring to it.

 

[wstephenson]

What about "Frontier: Not Invited To Those Sorts Of Parties"? As ED's serious, wire-rimmed cousin.

 

[QuantumTron]

"Frontier Final" has a kind of Japanese translated into English ring to it.

Given that my wife is Japanese, and that I lived in Japan for 6 years (yes I went through the M9 quake in 2011 and lived in ***ushima [*]) , I kinda like your thinking

edit: Oh c'mon! The forum software can't even recognise a Prefecture in Japan isn't a swearword
edit2: lol it even censors the edit reason


[*] Pronounced "Foo"-"Koo"shima

 

[Philip Coutts]

Shouldn't this thread be about how and who is going to do the programming and such like rather than about what to call it? Just call it "Project Newton" as a working title and get down to the nitty gritty!

 

[QuantumTron]

Again, with regards to the networking...

How often does a "typical" games client send update packets?

I know the current iteration of ED's client seems to swamp my pathetic ADSL connection - and is still in development - but a thought occurred to me...

Does the game client really need to send a packet constantly, or could it work something more like;

1) My ship's vector/speed is <blah> - SEND
(and/or)
2) RECEIVE - Their ship's vector/speed

3) Both clients now calculate positions based on last updated vectors/speed, nothing more needs to be sent...
4) Repeat (3) if nothing has changed
5) IF my ship's vector has been changed, go to (1)
6) IF other client has signalled a change then go to (2)

Obviously that primitive loop merely accounts for vector & speed changes - doesn't take into account ship orientation, collision detection, weapons firing, but you get the general idea.

The game clients also send their updates to the central game server which is acting as an arbiter such that if the clients disagree, then the central arbiter makes the final decision on a final situation.

Now someone is probably going to reply here saying "That's more or less how ED's client works" or "That already gets done in <some other game>", but it seems to me that that would be a way of reducing the amount of status update packets a game client sends. If I were a game client developer I'd certainly be starting a basic skeleton client with that as the beginning strategy.

 

[graham.reeds]

I could start a GitHub project on it.

I think P2P is the way to go for multiplayer.

As Mike might know, I did interview at FDev for a job in the server side. I thought it went well but obviously not well enough.

I have said in another thread how I would envisage P2P working (a hybrid between Donnybrook and VON).

 

[Armour]

To be honest I would rather the game didn't use a p2p network structure nor be aimed at being massively multiplayer.

Sounds like a good idea to me, gets rid of a lot of work and infrastructure.

Perhaps a standalone server could be made available by doing a build without any of the client-specific code? That way, people who wanted to could set up their own servers with the pipes and power to scale up to hundreds of players simultaneously.

problems with matching real people together can be mitigated if people are prepared to accept the AI could be used to always create nearby stuff where it's appropriate like in Frontier

Also, how about not differentiating between NPCs and PCs (e.g. no way to identify which is which)? It might make players feel less like they are playing against "a calculator" (as I've seen people dismissively calling NPCs), and they may regard unusual behaviour as simply that, rather than an AI fault and a reason to start complaining.

 

[laforge]

As I said already in the post in my signature, I will gladly offer any advice when it comes to physical aspecs of spaceflight (even when I was never up there ) as good as I can.

Basically my suggestion involves the following ship features (which can be damaged). For a detailed explanation about the flight assist see the thread in my signature. I may update this list if necessary:

• The presence of certain necessary HUD features to guide the pilot.
  • An indication of what object your current reference frame is (star, planet, station, ship).
  • A (probably logarithmic scaled) speed indicator, starting from 1m/s upwards to maybe 1000m/s. (the scale depends alot on other aspects) showing your relative speed to the reference object you have set.
  • The indicator of your current velocity relative to the object you set, I call it VCROSS. It is similar as in FE2/FFE.
  • An indicator of your distance (and optional your radial speed) against your targets (each target may have a box showing these two basic numbers, for example)
  • A planetary/gravity-well mode which will automatically come in place near gravity sources. It will include at least an artificial horizon and (optional) angular horizons of various degrees above and below that horizon. What is also important for space flight is an indicator that you are in a stable orbit. This can be done in this mode via a bar perpendicular attached on that horizon, showing if your VCROSS will move away or towards the gravity-source, i.e. your radial acceleration. If that bar is not visible you are in a stable orbit (in this case your VCROSS also coincides with the horizon). Although real-time orbits can last very long, this is necessary for the pilot to find the right velocity to enter a stable orbit.
    
    The planetary mode will also show the external pressure and temperature (this of course dependent on your speed relative to the surroundings) in combination with the maximal tolerance levels. This is important for cargo scoops near stars and the situation that a ship dives into an ocean (hull breach due to pressure) for example.
  • (optional idea) the display of a radiation level which is draining shields.
  • other standard UI features (shields, weapons, systems, targeting, navigation, ...)
• A flight assist which works as described in my signature.
• Attitude control.
• Individual thrusters or thruster groups:
  • up/down/left/right
  • forward/backward
  • pitch/roll/yaw
  These thrusters come with default values for every ship class (which is for example defined as to provide a 'good' fly-by-wire experience with no cargo) and have various size, but can be exchanged and configured by the pilot within certain bounds to suit his needs. One can think about introducing an overal energy/fuel consumption (the main engine) which must then be distributed among the various groups. The pilot will get the option to fly around the shipyard and test his configurations.
• An aerodynamic modification of each chassis (wings etc.). It modifies the ship behavior in dependence of the atmosphere parameters and the speed in the atmosphere.
• Hull and temperature shielding (optional).
• Shields
• A frame shift drive which works basically as in E-D (i.e. automatic accelerating and decelerating when you have a target/flightpath), but can be used to exit at any velocity (below c) one likes, if no target is selected.

Many things sounds a bit dry, but with the proper graphics and game design it can be given a very good look.

 

[laforge]

I could start a GitHub project on it.

I think P2P is the way to go for multiplayer.

As Mike might know, I did interview at FDev for a job in the server side. I thought it went well but obviously not well enough.

I have said in another thread how I would envisage P2P working (a hybrid between Donnybrook and VON).

I am with you. Although I am no software developer, I am willing to plunge into the details and learn the stuff on the way The first step must be some sandbox model in order to demonstrate the possibility to handle 'arbitrary' speeds. All other features are of secondary importance. (If no one else has a better idea how to handle it, I suggest to start with the concept I presented.)

 

[graham.reeds]

Here's the Github page for ProjectNewton though I must say the 'inspiration' that Github provided was SpawnCampAvenger which is equally cool.

I am fairly language agnostic (I have worked professionally in C++, C#, VB.NET, VB6, PHP and Java) but would prefer to use C++.

To get a leg up and make it cross platform maybe something like Ogre, and for P2P base it on Casablanca. I do however detest CMake.

@laforge: Do you program and what languages are you comfortable in?

 

[QuantumTron]

Here's the Github page for ProjectNewton though I must say the 'inspiration' that Github provided was SpawnCampAvenger which is equally cool.

I am fairly language agnostic (I have worked professionally in C++, C#, VB.NET, VB6, PHP and Java) but would prefer to use C++.

To get a leg up and make it cross platform maybe something like Ogre, and for P2P base it on Casablanca. I do however detest CMake.

@laforge: Do you program and what languages are you comfortable in?

Okay, not wishing to start a controversy (begin eye-rolling all round )...

I see the collection of languages you've used and understand why you'd find C++ desirable, but seeing as this is an open source project, wouldn't it be better to base it on C? I also don't think any of the others would be suitable - VB.NET, VB6. You mentioned PHP, which would be for what, a website I presume? And I do not think Java would be at all suitable.

The task in hand kind of dictates the choice of language. In this case, a game with a newtonian-like flight model as well as physics, and fast and efficient networking is needed for that.

Now I'm with Linus Torvalds on C++ , and reckon plain C would give you the utmost benefit in speed and code efficiency, and might even attract additional people into helping with coding because of that.

Also could you point me to a link on this Casablanca you mention? Is this a P2P framework of some sort? I had it in my mind that netcode should be built from the ground-up rather than trying to force an existing thing to try and do what you want it to do and then finding it has limitations such that you can't accomplish what you want.

Something else just occurred to me. Now this is just a thought, and do with it as you wish, but Oolite is on Github, is open source, and an Elite-like game. It doesn't have multiplayer though.

I was thinking that with OOlite you already have Elite-like functionality and graphics and gameplay already done for you - what if instead of making something from the ground up, you forked that project on Github and used that as a base for implementing the newtonian and multiplayer aspects?

 

[laforge]

C/C++ is what I would prefer. I am not sure if we should take Oolite as starting point. I think it is better if we use a very simple but working P2P multiplayer game instead and begin to modify it towards a space flight simulation, maybe SimMud (?) or something similar.