A lot of thing$ would be nice.
Question for @INovaeGene or other INovae Staff will there be Electronic Warfare in Infinity battlescape?
I do not believe that this was asked before.
Assuming a very optimistic amount of funding, how many features in the OP can we expect to have?
I recall a size for B:S in astronomical units. Here would be a good place for that number.
I donāt recall any I:B specific sizes, but back on the old website IA mentioned that he was mapping locations with a minimum accuracy of 1mm using double-precision floating point variables. If the Sun was the Origin of a system that size the game would include Neptune and possibly* Pluto.
Since INE will likely be based on the same data types, and I:B is based on INE, weāre likely to see systems of that size, that is, 27000-216000 AU^3 depending on the implementation (with essentially infinite space beyond mapped at gradually decreasing precision, possibly bordered by an invisible wall).
Speaking of: Any news on how speeds/distances are going to be measured? (Saying this now as I fear I may not have mentioned my utter disdain for an AU based system since the old forums went down.)
Would love to see a ātime taken by lightā for distance and āspeed relative to lightā system for the larger/faster scales. That way youād be 0.1c for 10% light-speed rather than 29979km/s or 0.02AU/s.
Distances are a lot easier to think about too, a human brain doesnāt immediately register just how much further 132,426,745km is from 13,268,352km and only gets worse at the larger scale distances; but 7 minutes vs 44 seconds? Much more like it. 
Gives a nice basis for working out how long a tripās going to take in your head once you get the distance and time your ship covers/takes to get up to a reasonable cruising speed.
I oppose time based distance representation. It combines both speed and distance and is thus misleading.
Have speed in meters per second (350 m/s) and fractions of light speed (0.05 c) [c = 299.792458 Mm/s] and distances in meters (600 m) and light seconds (1.3 Ls) [Ls = 299.792458 Mm]
Also. Use unit prefixes ⦠they are useful.
132Gm and 13Gm
Pretty much how Elite:Dangerous did it.
ED did a pretty good job of the distance/velocity/time indicators, you have a velocity indicator, a time estimate and distance to target, all scaled to the closest unit.
I know that serious gamers tend to love numbers, but I do not. Iād prefer that I have the ability to play with as few of them as possible because I prefer to rely on my view of the game environment instead of numeric displays.
When I built the warp prototype, I left out velocity and distance indicators because I donāt use them. I need to slow down before I slam into the planet, and I can get to closer planets sooner than farther planets. I accomplish those things by relying on my view of the game environment. Naturally, as soon as I showed the prototype, I was asked for numeric displays.
I feel the same way about HUDs. Keep them as minimal as is humanly possible. If thereās a way for me to look at the game world to understand whatās going on, then let me do that. Certainly donāt show me stuff that I really donāt need to see - even if it follows the ārule of coolā. One manās cool is another manās rubbish.
So consider this a vote for UI minimalism. Subtlety. Cues and hints. Instead of a screen full of icons and flashing lines.
I think both could be done. EQ allows nothing to all kinds of windows.
If I recall correctly, the warp prototype was a top down view of an entire solar system?
In a first-person perspective, correctly anticipating when to slow down to avoid smacking into a planet becomes somewhat harder as it may have to be done when said planet changes from the size of 0.5 pixels to 0.7 pixels. Of course putting up a map would be an option⦠but then youāre replacing a relatively unobtrusive 3 digits and 2 letters with a map view taking up a good portion if not all of the screen.
Alternatively a system of flashing lines could be used to visually indicate the optimal timing for a suicide burn (and when to just try to pass around the planet this time)⦠but yeah, thatās not going to reduce the HUD complexity, at least for new players.
[quote=āRuniat, post:31, topic:847ā]
In a first-person perspective, correctly anticipating when to slow down to avoid smacking into a planet becomes somewhat harder as it may have to be done when said planet changes from the size of 0.5 pixels to 0.7 pixels.[/quote]
There are no such critical maneuvering decisions to be made while a planet is still a pixel. If there are, then the movement system is busted.
[quote=āRuniat, post:31, topic:847ā]
Of course putting up a map would be an option⦠but then youāre replacing a relatively unobtrusive 3 digits and 2 letters with a map view taking up a good portion if not all of the screen.[/quote]
I can replace those 3 digits and 2 letters with balls representing the planets where the opacity of each ball indicates its relative distance. Thatās even more unobtrusive because Iām expecting the planets to be there. Or the balls are color coded near and far. Perhaps my favorite: red for approaching and green for receding. Or how about adding a trail to show the orbit of the planet? There are piles of data visualizations that can be tried in order to help players navigate a system, and presenting the distance may well not suffice.
Something that Iād like to see is a way of holding down a key to show an overlay of information. When I release the key, the overlay goes away. If I double-tap the key, the overlay stays up. Double-tap again to dismiss it. If an overlay is staying up and I hold down the key, the overlay goes away - until I release the key.
So if I want my targeting overlay up for a momentary check, I hold down the T key for a second, then release it. If I get into combat, I double-tap the T key. If there are consequences to bringing up an overlay (showing the targeting overlay involves powering the weapon systems) then the decision to look at such displays, and the timing of them being up and active could make for some interesting gameplay consequences.
Properly implemented, the game would allow configuration of overlays. I may want to define a combat overlay. Or a maneuvering overlay. Or a mining overlay. And so on. Then I can use subsets on keys to turn other things on and off, or temporary display or dismiss them.
We were wrong, Battlescape is a First Person Shooter.
[EDIT] Note not the reason I posted this, just that Battlescape is getting its own page on moddb/indiedb
Gah! First person shooter! Dear god⦠what have I done⦠goes to ModDB⦠grumbles
Edit: Combat Sim probably fits best⦠eeeeh, categories are limited. Wheres the Genre that blends SpaceSim with Epic scaled first person combat mechanicsā¦
@cybercritic Donāt think thereās any new stuff to add to the OP from this recent Flavien statement, perhaps cities? It could be used as additional confirmation for some of the features listed though.
I can not edit the OP, it has been over 6 months and editing is disabled.
@INovaeKeith, can you please change that single number in the settings file @hrobertson pointed out and allow longer edits?
/edit
Since editing is fixed, I added a few more recent facts, including stuff from that post you quoted.
A question for @INovaeFlavien / @INovaeKeith : if a procedural planet bobble head (really love the idea btw) can be different every time, why not do the same thing for the BattleScape solar system? Iāve got the impression the solar system in BattleScape will always look the same. It seems like a big strength of the engine isnāt being used this way.
The reason is artist placed assets on the planets in the solar system. There is an element of level design to the planets for optimal gameplay vs. the planetary bobble head, which just cycles through seeds where no structures will be placed etc.
Will anything actually change between Battlescape rounds? I expected structure and objective placement would have been one of those things.
Thanks for your really quick answer!
Iām guessing level design is only about placement of man-made structures such as buildings on the ground and spaceports. Am I correct in that assumption? Isnāt it possible to also procedurally place such structures? Level design can be described as a set of rules (spaceports spawn close to grond structures for example). Of course hand made levels look and feel better, but variety in planets and moons also adds too look and feel.
An other idea would be to only change textures of planets and moons but keep structure placement the same.
Iām sure you have already considered these options, but Iām not sure on what grounds you decided for a solar system thatās always the same. Could you elaborate on that decision?