Jump to content


Alpha Tester
  • Content Count

  • Joined

  • Last visited

Everything posted by SandoMutt

  1. Still half a year (at least) to the Alpha phase start, and forum trolling and griefing is floundering . Boys, we need to restrain ourselves, or this community can become as corrosive as EVE fellas... But to remain on topic, surely tier 3 will be only part of the ladder; to build and use hyper-reinforced bricks will need you to learn to use tier 4 superalloys, tier 4 construction skill to add it to your construct, etc etc... Obviously all of this will require about a full college grade, roughly 3-4 years. Not bad to use hyper-reinforced bricks... I hope constructing high tier bricks will scale exponentially, so hyper-reinforced bricks will need about a day to build in an specialised tier 4 supealloy fab complex about the size of a big football stadium...
  2. My two cents on this topic: As we do not know how the voxel system interacts with game engine is nigh to impossible to estimate the overhead that collision coordinate computation (first step to implement any collision damage) adds. We know that the engine computes voxel collisions, but there are algorithms that do that and do not compute the intersecting coordinates. That said, if the engine computes by itself that coordinates, implementing a simple damage model in the line of weapon damage is only moderately difficult (in terms of overhead) and completely doable. Regarding all the fuss about the pertinence or not of allowing collision damage, I am all in the wagon of its pertinence. Because without collision damage flying near structures has near to no significance. And too many immersion is lost without them. For the issues given against this mechanic: Griefing is natural to MMOs. We can think about that what we want, but because most griefing conducts are not absolutes one action that will be considered to some griefing, others will see it as permitted (even if esteemed unfair) play. Ramming will be very difficult if Newtonian physics are implemented in flight. IF IT IS the case, I expect that most ships will have enough thrust to accelerate to at least to 1G (otherwise, flight can become something very very boring), and some Km/s relative speeds will be common in most combats. Combat ranges will be in this case in the order of hundreds of kilometres, if not in the few thousands. Even if you are able to achieve a low relative speed to your target to make feasible to start a ramming maneuver, in the majority of cases target will be able to avoid you, or will have enough time to pour a hell of fire on your ship. I think that most of you are underestimating the total costs of building anything greater than a few tens of meters. A ramming ship big enough to do any sizeable damage (with maneuvering and flight capabilities that will make ramming something achievable) is going to be no more cheaper than a combat ship of the same tonnage. Mostly because hull cost in big ships are going to be a big part of the final cost. Add this to the above point, and ramming will be only the last maneuver of an already dying ship to try take someone with him to the tomb.
  3. I have no doubt that you will be able to see that, either in built ships or blueprints. The question still remains of which significance that information will have. And, from what appears at this stage of our knowledge of what developers are doing with DU, the answer is that probably little to less than little. Of course that information can filter the most obvious scams (such a publicised surface capable ship with engine thrust incapable to lift off), but will be of no help to assess its real performance. Nor will help to compare with other ships; if you have some experience with EVE, DU ships will not have anything as shield, armour and hull stats, capacitator size, engineering points for rigs, etc etc; from that stats, plus the stats added by modules, one can have a good idea of the performance of an EVE ship. DU will be a total different beast, as long as developers stated intention of making ship handling related to the physics engine and scripting of elements holds. For example, in space, if they maintain Newtonian physics, ship speed will be not bounded (well, leaving aside Relativity, of course). Thus acceleration will be determinant, and acceleration performance of a ship will be determined by how well placed the thrusters are on a given design. Even for linear acceleration, because a body accelerated at a point with a direction not in line with its centre of mass will develop some moment, and depending in their amount, stabilising the tendency to rotate under acceleration could be quite a difficult task for maneuver thrusters, not to count that if you want to make that stabilisation automatic with some script, it can be a truly headache. P.S. And talking about Newtonian physics.... I hope it will be the "background of space". Battles with ships buzzing at some kilometres per second will be a total different thing from anything we have seen before . Alpha stricking will be of paramount importance in such a kind of combat.
  4. The question is, are attributes going to be of any significance? Total mass, yes, but total mass will be influenced by cargo. Dry total mass can be an attribute that DU will be able to compute, but little else of any true significance. Real answer is: you are going to test yourself any ship to really know its real attributes and performance. And I'm going to put you an example that I think will give a lot of light to this question. Ok, imagine that Mutt Design Bureau, in partnership with a big alliance, designs and builds an Armored Cruiser (by dry tonnage) vessel (call it Armadillo class) for long range fleet combat. One of the main characteristics of the Armadillo Class is an highly optimised distribution of hull thickness to allow Armadillos to withstand as much damage as possible when they fight in its intended combat position, performing at that situation as battleships. To that goal, MDB, with help of FCs of the alliance, analyses possible ship hull configurations to maximise active weapon batteries in combat, and after arriving to an ideal configuration, MDB computes a probability distribution of enemy fire impacts on the projected hull; hull thickness then is incremented following that distribution. Problem is, in some zones, hull be 2m thick, in others 3m, in the most compromised positions will be 4.5m; in combat shadow positions just 50cm. The average hull thickness is 1.8m, for example, and possibly DU can compute that, but, of what usefulness is such value? Now after a period of embargo from the alliance, MDB is allowed to sell Armadillos in the free market, and you come and purchase one of them, because of their 10 double heavy cannon batteries, because of its max acceleration, because is nice, because its 1.8m average armour... In your first combat, alone, you get surrounded by a swarm of heavy fighters that know previously Armadillos and wipe you out of the sky in 2 embarrassing and quick minutes. You come to me citing the 1.8m average hull thickness and yelling "SCAM!!"; but the reality is that Armadillos are designed only for fleet combat, to fight at long range, and need a fighter cover to address the vulnerability of their low armour in parts of their hulls.
  5. Titanis, I have a lot of experience with KSP, programming, and RL performance estimations of designs. Heliomance is right. A list of basic characteristics of an spaceship that can be calculated automatically by DU will give little to no information about its real performance. He gives a really good example with thrusters pointing in diferent directions to add manoeuvrability. Simply adding thrust will not give you the total forward thrust of that design. Also, to judge manoeuvrability, is not the same if the main thrusters have some vectoring capability or not. I can imagine an autopilot script in a fighter that makes random changes of course, to try to confuse autotargeting weapons. How good such a feature will be can only be judged by a tester. The solution is obvious, although I understand that is not totally satisfactory to you: you must really on other people judgement, just as in real life. For mass produced ships the obvious solution is to have people testing them and certifying builder supplied characteristics, and giving its proper ratings. For unique or low production designs the reputation of the builder will be of paramount importance.
  6. mmmm... I don't want script driven mining, because, in that case, you do not need in reality any supermachine to break a planet. All you need is good swarm programs and lots of small autominers. The megascale mining operation using gigantic machines is a waste of resources. The same can be accomplished with a big enough swarm of small machines. Also, such a mechanic is a very powerful weapon: go to your enemy planet, drop on it with a big army of autominers and a portable autominer factory. Use exponential growth of your autominer army to reduce the enemy planet to nothing in less time than the enemy response time. That said, large scale mining should be possible to allow the construction of very big structures with a reasonable period of time for the material gathering.
  7. SandoMutt


    As some have stated, a general public bounty will not work. Is too easily avoidable: go with a buddy to your nearest Resurrection Node, ask him to kill you. Collect bounty, split proceedings and profit!. In EVE such general bounties were a laugh for a lot of time. That said, it can be done mediated by private contracts. That is, you pick a third party, put up a contract with it that is payable under the assumption of a probable kill report of the target. Done. Of course this means that the target do not knows that his head has a price. But well, organisations can be created to tackle that aspect. For example: a federation of criminal hunters with a public board to delegate contract completion. Surely criminals will be happy to have an eye on such a public board.
  8. Perhaps we have a great opportunity to make something really unique in the field of game economics. Regarding the problem of game currency, economy initial bootstrap, and control of the currency, there is a way, a very unconventional one, sure, to do things in a different mode. First, I want to point that, in any form that DU economic system is finally implemented one thing will be the same surely: DACs will be the de facto MONEY. I call in this context MONEY an economic asset that fulfils this three properties: Is a tradable asset in the system Is ubiquitous and "easy" to obtain (in the sense that everybody can find it). Is the most liquid asset of the economy We can think about it all we want, but experience is the mother of knowledge, and DU economy is going to have enough similitude to EVE Online economy, where PLEX is the de facto MONEY in the sense expressed above. But DACs are simply game time. That is, a DAC will represent 30 days (720 hours, or 2,592,000 seconds) of an avatar game "life". So the unconventional proposition is simply: make avatar game "life" the currency of game. For example, make 1 credit equal to one millisecond of game subscription time. Or count prices directly in milliseconds, and deduct or increase the final price of any trade from the "life" time counters of each part in a trade. Just equal to the idea behind the film "In Time". To not distort the in game currency, free game time from trial periods will be non tradable, so it will be not part of the currency base. So when you use a DAC to enlarge your remaining game "life", 2.592B of credits (or milliseconds) will be added to your "account"; you can use it to purchase things or pay for services, the first of all and unavoidable will be "game life" at 1000 credits per second. If in any moment your account reach 0, well, you die. After resubscription or reDAC, you resurrect in the nearby Resurrection Node and can continue to play... Problems I see: This model can be quite deflationary regarding prices. People that use subscription to play can be left with no life before end of subscription cycle. Scamming and economic warfare will be especially punishing One way I see to tackle the first two problems is to make that DACs and subscriptions add more than 30 days of "life" time, for example, 33 days. For the third one we can see it as "works as intended", making DU a quite punishing game for people with thin skin, or a very clear and active antiscam policy must be implemented from game moderators to reduce this. Other way to address the problem of "end of life" for people with active subscriptions is to make tradable only the added "life time" and the subscription term time non tradable; "life time" added by DACs will be fully tradable. This way the quantity of currency in circulation is more or less proportional to the number of subscribed players, because fine tuning sinks will accomplish that quite easily. Additionally no bootstrap is need to start economy nor currency distribution; at the start of the game, people will have plenty of currency in their hands, and even NPCs will be not necessary. The last problem I see regarding this currency model is that from wealth accumulation in the form of assets, the general trend will be for a slow deflation, which if goes out of control can stagnate commerce greatly. I think that the only solution to this is to put some mechanism of decay by time to most of the assets in game, which in effect will function as an asset sink mechanism, making the deflationary trend more controllable (or reverting totally it, if the decay rate is too high). I know that the idea is quite crazy, but, hey, will not be incredible interesting to see such thing?
  • Create New...