Cornflakes
-
Posts
384 -
Joined
-
Last visited
Posts posted by Cornflakes
-
-
Simple solution: ignore relativistic effects and signal delay.
Explaining why some things are affected by it and others not is harder than just dropping the issue altogether.
Related to that sensors could have limited time resolution, though.
Like a short range targetting sensor gives "real time" data (image frequency = server tick rate) but a long range system scanner gives only one scan every 5 minutes (arbitary number is arbitary, "long").
So the long range awacs ship would maybe be incapable of hitting anything close to it because its scan rate is too low to give usable targetting solutions for moving, maneuvering targets
-
I know that NQ have been very informative on how markets will work, and how products are bought and sold, however, has there been any thought or information thrown around about the actual financial system? How will the financial system run - similarly to real life? What would be the role of banks (if they even existed as the game mechanics allowed)? What about loans, or investments, to people who don't have the funds to undertake large projects. Could banks store people's money (or would that even be necessary)? What about groups or companies that could go public, and have people buy stakes in them in order to raise funds, just as in real life?
I just figured this was all food for thought as it doesn't seem to be something that's been explored yet.
What prevents you from building a bank?
Banking is player-player interaction, it doesnt need explicit mechanics for it.
Want a loan? Ask a player.
-
essentially really smooth mirrored surfaces that can pick up anything.
because mirrors are sooo good at absorbing radiation
an ideal sensor is perfectly black in the spectrum it wants to detect in, not mirrored
how would it detect radiation if its not by absorbing it?
Those lights do seem to resemble optic sensors.
why would an optic sensor glow? its a receiver, not a sender, any emission its creating flow directly back into the readout as noise
It is a generic term. Even a TV remotes work using RF sensors. At least the older ones. I also don't see the Devs adding in really complicated calculations for them either. That's why it will have to work on a volume around it.
if at all its new remotes using RF, old ones were wired, IR or ultrasonic.
i'd personally just scrap all this "thats infrared! thats radar! thats blah!" stuff and just abstract it to emissions and detection sensibilities (maybe with some abstracted spectrum mechanic to introduce another dimension)
sum of all emissions gets distance attenuated and compared to the sensors (spectrum modified) sensitivity.
unify all the emissions (and reflections from active scanners, they look the same anyway in this simplified model) instead of saying "thats this very special narrow area of EM and this is this completely different narrow EM band!" ....
-
-
Actually, a smooth steering mechanism like that (the circle) would be pretty neat!
Like a mouse?
-
I would seriously buy two or three ipads or kindle fires (or whatever works really) and set them up as an actual ship consoles in front of me. I love this idea. NQ this should be a STRETCH GOAL!
P.S. And where did the color option for text posts go?
Take any adroid device, install droidpad, profit
¯\_(ツ)_/¯
-
so cornflakes, can you understand how proud we are that game is a french game ? (you have google microsoft apple....disney, De Niro, RSI
;) ) yes we could hope a forum write in french for a french game, and may be thats would be you turn to make the effort, to learn. But im not sure if the novak team had make this choice in a first place a lot of american or english paid for that. Make the effort. You dont have the habit. for u its easy ! All is in english.Please can u just imagine how good it is for the brain to stop searching always the translation...
The only development studio that "i" have and i can recall from the top of my head is jowood, and they died half a decade ago
(And googling just told me that THQ nordic is an austrian company! Woot! i should go over there and annoy them into giving someone a supreme commander license!)
In my opinion as native german speaker its easier to learn english and have all the confort it gives than to annoy people into making translations for me
-
I'd prefer if theres no explicit ID system but instead something thats built on LUA communication.
Like a few standard communication tags with assorted data sectors (like xml or json tags).
For example vessel name and affiliation.
Security features atop that could be handled by player made LUA code.
i'd also make it hard to impossible to intercept such communications.
Transport layer security should be hard to circumvent
-
I'd personally go further and allow (sandboxed) remote code execution.
Kinda like html5 programming, you get a "screen", a few processing resources and a link back to the "server" dpu and can execute code on the client DPU.
For example for remote interaction interfaces which work on any construct without people having to build complex protocols manually.
Say theres a big trade station with automatic dock management.
You ping the station and you get a request for remote computing.
You allow the station a screen and some computing resources and it opens up the dock interface on the screen in your ship, through which you ask for a dock and the station replies by giving you a waypoint for docking through the interface.
Then it closes the link again and the interaction is over.
Basically a system to draw GUI elements on cooperating computer systems/screens to allow easy access to automated functions without the community having to build complex communications protocols and software
-
i'd find it interesting to see a game its not just about blowing up stuff.
assuming the other things that /arent/ blowing shit up get proportionally more love.
maybe it is boring, maybe it sucks. or maybe its awesome and doesnt need combat.we dont know, so we can as well just sit and wait ¯\_(ツ)_/¯
instead of jumping and screaming "the game will fail without combat!"
-
There have been some topics around this area, particularly with building ships, but I feel that the this is a concept valid for the entire game. In a huge civilization-building, player-interactions-driven game, I feel that having people skilled in just certain areas will eventually lead to a more enjoyable experience for players. And this is something that many people may disagree with upon first hearing it, but find in the long run that they think it works really well. Or maybe they'll hate it! I want to share my opinion on it though, and I ask that those reading, who may think it's stupid, give it a chance. Also remember that there are two sides to this, neither are correct, and both are valid. It's just opinion based.
If anyone is familiar with the game series LittleBigPlanet, the first and second iterations for the PS3 played a huge role in a season of my life. They were the main games I played for months, and I had a friend who was into it as I was. Anyway if you don't know the game, it's not important. Basically, you use some basic tools to make little minigame-ish things (I'll refer to them as levels).
Anyway, in the first game, there were a few levels and creators that stood out significantly from all the rest, because they were fantastic (anyone that knows the name "Lockstitch" off the top of their head is a freaking awesome person). Me and my friend, we knew exactly what tools were available, and what you could and "couldn't" do. But some few levels stood out to us because, as people who knew the game inside and out, we had no clue how they some of these things were accomplished. A fair few levels were outstanding and amazing due to their mechanics and visuals.
When LittleBigPlanet 2 arrived, there were tons and tons of new tools added. These were fun and great to be sure, but they made everything that made the old levels special, not special. Because, all of the fantastic things that had been done before (in the first game) were now basic and easy because there were tools to do them (in the second game). This made a lot of great content a lot more common. Which of course was a good thing. And there were certainly levels that still pushed the boundaries. But overall, by making cool and unique things easy, it made great content a lot more common and thereby a lot less special.
If Dual Universe makes building easy, and mining easy, and combat easy, and exploration easy... Well, then there are going to be lots of amazing ships, and lots of miners, and lots of warriors and lots of explorers. You may say, "that sounds great!" But, remember my exceedingly dramatic and emotional story. When you make it easy, it stops being special.
In a game like Dual Universe, where player interactions and jobs and organizations are such a key factor, it shouldn't be easy to do anything. It shouldn't be easy to switch from a being an efficient miner working for a large corporation to a stupendous explorer finding rare resources on hostile worlds at the edge of the known galaxy. Sure, you can switch job titles and do whatever you want whenever you want, because it's a game! I'm just saying you shouldn't be able to switch from being outstanding at one thing, to suddenly outstanding at another. This allows individuals the opportunity to stand out, and be known for something. "Hey he's that guy that makes that line of super efficient yet powerful ships. I don't know how he comes up with that stuff." "What, you want to send Xx_M8_SLAYR_xX to go hunting for that anomaly? He's an architect, someone else will find it way sooner!" If someone wants to be known for something, then they go for that something and only that and they end up being great at it, and known for it. Lots of people will choose to not do this, which allows the few that do to stand out.
I can't really say much else that I haven't said already. I believe I've gotten my point across. Regarding designing ships or stations, it's easier to see how an individual could be better at it than most others. Mining or exploration expertise could be accomplished, not just by having better equipment or skills, but also by there being hidden techniques that people just have to learn by doing it. Thank you for reading and please try and be civil in your response, as, once again, both opinions are valid!
When everyone's special, no one is...
And if you're good at something, never do it for free!
I agree with the really cool things being hard to archieve but i certainly dont want it archieved by limiting the tools available to players.
The hard thing should be finding out /how/ to do it, not executing it.
If building is hard to execute its just frustrating.
-
If two Objects are within sensor range, you would need a method to distinguish between "blip 1" and "blip 2" That's why the ObjectID would need to be returned. You're not getting any "intelligence" information. You're just getting the assigned unique identifier.
thats the intention
you shouldnt be able to tell two identical blips apart without extra data.
or even if the blip in question is anything at all (think sensor confusing environment conditions).
with better and better sensor data you should have an easier time telling what it is, but not magically gain unique identifiers.
cause how can your sensor say that the thing its detecting is core unit fb5cdeff883c2 and not fb5cdeff883d2 ?
all your system knows is "blip 1" (with emission signature 1) and "blip 2" (with emission signature 2) or however you name them in your code and what other data your system gains through other game ways.
-
A basic sensor could detect only the ObjectID within the "Area of Influence". An omnidirectional sensor would essentially say an object is near you. A directional sensor, could respond that an object was detected off your starboard side.
Sensor 1.0 - ObjectID
Sensor 2.0 - ObjectID, XYZCoordinates
Sensor 3.0 - ObjectID, XYZCoordinates, Distance
etc...
I DO very much like your emission strength, and counter measures.
i think a sensor should /never/ just provide the ObjectID.
determining an object ID is the job of the computer behind the sensor.
a sensor should provide "theres a signal", and the player has to figure out the rest with DPU magic.
the sensor doesnt know /what/ it is in first iteration.
it could be a single generator generating heat and nothing else, it could be a ship with a generator, it could be a group of ships close together.
the "object" the sensor detects is only some generic radiation, the DPU has to make sense of that itself.
if you add some ID to that signature its fine, thats your thing.
but the sensor just tells you that theres /something/.
-
Here i outlined some basic ways to define actual detection.
NovaQuark has not provided details on how sensors work. Everything mentioned in this thread is speculative.
Here's my IDEA, and reason for the thread.
Allow for "sensor dimming" by adjusting input power to the sensor. This reduces the size of the "Area of Influence".
In the previous sensors thread, I suggested the following:
===== Sensor Elements =====
Sensor Elements do NOT have to be omnidirectional. Hemispheres, cones, cubes, and beams are possible.
Sensor Elements ARE different than Display Elements
Sensor Elements detect all core units or avatars within a defined 3D "Area of Influence"
Sensor Elements ONLY need to return the "ObjectID" from the core unit or the player's Avatar.
Advanced Sensor Elements can return more information than the ObjectID, depending upon how NQ codes them.
===== Display Elements =====
Display Elements (radar display) will only need to know the ObjectID
Display Elements will be hard coded by NQ, to display the XYZ position of known ObjectIDs
Advanced Display Elements may take additional attributes such as "Friend or Foe" designation
Advanced Display Elements may take additional "Color" attributes
Advanced Display Elements may have the ability to provide different icons "on screen"
===== The DPU =====
The DPU can be used for filtering ObjectIDs provided by the sensor to the Display
The DPU can be programmed by the player to filter however they like.
===== Flow of Data to the Display =====
Information is passed from the Sensor --> to the DPU --> to the Display
===== Weapon Elements =====
Weapon Elements have their own hard coded sensor
Weapon Elements attack ALL ObjectIDs passed to them by a DPU
===== Flow of Data for Weapons =====
Information is passed from a DPU --> to a Weapon Element
The DPU obtains that list of ObjectIDs however the player decides, including from a sensor.
i like the idea of just needing the object ID to identify a located target in the computer system, but it also seems slightly limited in what the player can do with software to locate/identify/track targets.
maybe replace it with a more generic "point/vector" primitive to which characteristics can be added by the player?
the primitive would contain an origin, a direction and optionally a distance.
so its denoting "somewhere in that direction" or "exactly there".
those primitives can be handed over to other systems (like turrets) and the game engine handles all necessary coordinate transformations.
(cause thats a pain)
the primitives would be reusable for other purposes other than detection as well, for example for general navigation and communication of directions.
(hell, the direction vector could directly be utilised for target designation by the player "the first ship that intersects with my pointing vector", a raycast)
so, now to actual gameplay and not programming details.
a passive sensor cant determine the distance to an object on its own. it either needs a reference emission strength (it receives x watts/m² object radiates y watts so the distance has to be r away x=y/r²) or a second passive measurement which has to be some distance away to cross the vectors and to determine the distance that way.
active sensors provide their own reference emissions and thus can pinpoint targets on their own, but they are very visible over great distances (the square of their detecion range assuming identical ships)
again the vector math should be done by the game engine
the vector headings shouldnt be perfectly precise but have some imprecision in their heading.
so one sensor might have an angular resolution of 0.5° which gives good enough data at short ranges but isnt suitable for long range fire
and another sensor might have an angular resolution of 0.025° which is suited for much longer range pinpointing but the sensor also has balance defined drawbacks.
this would enable confusion plays with multiple ships flying close to each other. appearing like a bigger target or a different target than whats searched for.
player programming skill should come from choosing which vectors to analyse more closely and which vectors to "cross" to determine pinpoint coordinates.
the rate at which vectors can be compared could be game mechanics limited ( x comparisons/second per DPU) so that good programmers would have an edge in terms of target detection by smart choice of the vectors to analyse and cross for coordinates.
so one could run target identification by brute force and a large amount of DPUs or by smart checking and using the resources they have optimally.
with a way to have DPUs communicate even across constructs (linky) would encourage having specialised sensor and processing ships, which weave their com nets through the fleet and supply the less sensor focused ships with targetting data.
so for large battles dedicated C4 ships would be highly useful to keep all the targetting data organised, precise and distributed to the combat ships.
this also opens the gates for player made countermeasures.
have an emitter randomly switch on and off to confuse the distance assesments of active sensors.
throw out flares to confuse passive sensors.
randomly toggle emitters distributed over the surface of you ship to obfuscate your position and velocity vector.
edit:
after posting i noticed a small gap in my explanations:
sensors on their own dont provide pinpoint coordinates, the player has to process data in DPU's to get pinpoint data.
the sensors directly only provide directions and emission strengths
-
ich bin doch kein preuße! (im no prussian!)
daheim im großartigen Kaiserreich Österreich! (im at home in the great Austrian Empire!)
'd surely be fun having a few people to talk in a language thats a bit easier on the tongue
-
If there is no limit, what prevents people from building a death star out of thousands of power units? (overplayed)
practicality, fuel consumption, terrible TWR, "putting all your eggs in one basket" .....
-
Not according to how the voxel engine and physics design for DU currently stands. As of right now, a floating city is as simple as build it out of a mountain, then dig/cut the bottom of the mountain out. Voila! Floating city.
true dat
-
Because ship building is a major element of the game!
I think the most people who will play Dual Universe would not consider this suggestion as a "wierd system"
I mean you will be able to build a turret onto your space station and programm it! Hello?!?
----------------------------------------------------------------------------------------------------------------------------------------------------
Okay! Going on with my ideas:
If you want to implement a second core into a "one seater" (space ship built for one person)
you would need a higher ship crafting level (or however it will be named)
Example:
Ship with 1 power core - Crafting Level 0
Ship with 2 power cores - Crafting Level 10
Ship with 3 power cores - Crafting Level 35
There should be a natural limit for the one seated ships like 3 cores per ship. So you would be able to design a ship which is incredibly fast (300 % max) or can use heavy weapons on your small ship. Weapons that need at least 200 % power.
This idea could be expanded to space stations which have bigger power cores and could use bigger canons and better shields.
And you could add ultra rare power cores in all classes/dimensions which perform 150 % of a normal power core. But the rare cores should not be craftable. They should be more like rewards for finding/solving a secret in the Universe.
still.... why use a weird ruleset around "power cores" and "200% power" instead of just "this generator produces 15megawatt" and "this cannon needs 5 megawatt"?
KISS
-
Fuel, lift, and weight aren't as much of an issue if your shipyard is in space.
but it matters a whole lot if you want the city to float in the atmosphere
-
I havent yet seen anyone else using that joke, only myself a couple of timesFirst, that turing joke is old, you copycat
thats fine, that doesnt make it the only playstyle that should even be considered validSecondly, call me an elitist, but I don't like being pampered. I plan on ultra paranoia and keeping myself safe with manual means.
I never said "everyone".If everyone has a personal field of protection, there's no need for large cities and the protection they provide.
What im thinking about is that small-ish groups at least get a chance to react when something happens.
Like 10-20 people that build a small ish something out in the wild.
They shouldnt be casually curbstompable without them having time to even try to fight back.
I dont say that the protection should enable to prevent the impending doom, it should just delay it long enough that they can get back to their computers and do something about the apocalypse.
-
Well, the Devs said that exiting the safe-zone would be something risky.
I rest my case at that. People can wait for you to log in and destroy you when your personal "afk magic bubble" is not there.
I guess that would be fair if 50 guys were to blow your shack off the map so they can mine the area around you. -shrug-
The game's selling point is congregation in one place. Large cities should be the ones having access to force fields, cause they got resources.
If everyone has magical space field around them for 24 hours, that defuses the point of the game's main social feature. Everyone will build on their own.
You find a guy who went offline in a heavily pirated area? Nah, 24 hours magical force field. Seems legit :V
Also, EVE had this mechanic, because EVE had to deal with queues of people hopping into a server-system.
What's next? Time Dilation because carebears can't use keybinds and can only click with their mouse? :V
you just failed the turing test.
who said everyone?
who said that it could work without setup time in a moving object?
you could /read/ what other people write for a start.
hard limits on where and when the protection is usable at all.
setup times, recharge times, whatever.
but the point is to level the playing ground between people in different time zones.
being concentrated in a specific region of the real life world shouldnt produce an inherent disadvantage against groups who are localised in other areas.
if theres a bunch of eurodudes they shouldnt lose against a bunch of murika dudes just because the US dudes are awake (and can organise /something/) during the euro play time and the US can play when all the euro gamers are asleep.
and what do reinforcement timers have to do with system transition queues?
-
I agree, there cannot be game mechanics that punish people for not being online. Nor should it be possible to destroy someone's things without them having the opportunity to do anything about it.
But to remove the ability to damage someone's things when they're not online not only ruins the sandbox, but presents potentially game breaking exploit opportunities.
absolutely, hence why i'd say its hard limited as to how and when you can use that invulnerability to prevent the aforementioned exploits.
time limits, traversal limits, other drawbacks you have to take for using the system.
-
It's a tactic to catch someone off-guard. If they only recruit X timezone players, they are risking having particular downtimes.
sooooo... its their fault for having a life besides the game?
(or for making a corp with only RL friends, or similar craziness....)
sounds like fair game design
-
The thing is, they want to be building shiny things, but not having any risk in a game advertised for its emergent gameplay. If a guy builds a factory and I have to take the factory out in a small time-frame due to travel-times and that person's timezone faction's limitations, I should not be limited.
so you say you explicitly dont want to play fair game by outsmarting them or anything but by abusing their real-life limitations and attack them when they cant fight back?
Wireless LUA/Software
in Idea Box
Posted
a script really is just a dynamically compiled/interpreted piece of software that runs inside/as a part of another (bigger) piece of software.
It says /nothing/ about the size and/or complexity of the script.
A script can be any size and complexity.
(I have a buddy who wrote stellar dynamics simulations in python in uni... sooo)