Jump to content

Wallfacer

Alpha Tester
  • Posts

    141
  • Joined

  • Last visited

Everything posted by Wallfacer

  1. discordauth:F89Mr4AMiFete7V8o5U6g9MvRXsHl9af-e-yt1L1VdY=

  2. I heard that clouds will be handled in the cloud. Pretty sure that means the Amazon, so expect rain.
  3. There already is a small crater where the arkship landed. You can't mine in the safezone anyway.
  4. As an idle passenger? I can see transport. I guess I can see large multi-crew ships working well as war/transport ships as people will always want to explore/mine varying worlds and would like a safe way to and from outposts.
  5. Like you said, it's a game. How many players really want to sit idle for hours in a ship? I can actually see it working, in the sense that large multi-crew ships can sit at a space station waiting to be called into action for large scale conflicts. But it's a tough balance to make, because the conflicts need to start with solo ships, and as long as 5 ships can match the firepower of a 5 crew ship, the 5 solo ships will always have a big advantage.
  6. I just don't see 29 people wanting to sit idle in a ship that may or may not engage in a fight or be trapped in a ship for long time for 5 minutes of action. Hopefully there is someway to remote into turrets if you really need a person per turret.
  7. More seriously though, I think the idea of having a dynamic core unit is that anybody in a dynamic unit will be bound to the unit if they are logged off (intentionally or otherwise). I'm not sure a bed unit is actually a good fix to the problem you foresee. What if I'm inside a large ship flying across space (so not bound the cockpit or anything like that) and my cat turns off my router so I am accidentally logged off. Do I reappear in space or in the dynamic unit? What if I'm not even authorized to use the unit, I'm just a passanger? On the other hand, what if I log off standing near someone's ship not realizing that I'm in the dynamic unit box? If they fly off into space, will I appear in space outside the ship and be stranded when I log back in? More maliciously, can someone stand right next to my ship in a safezone and then log off while I'm away then log back in after I've flown to a non-safe zone and proceed to strip my ship if I'm away mining or something? Maybe there should be a way to find out if any unit you have access to has another player connected to it for login?
  8. I've been playing ED on the Rift. I can't imagine playing it any other way; without VR immersion I feel like ED would get very old very fast. I really hope they implement VR support in DU. It's getting hard for me to play non-VR games.
  9. In space, you don't have to deal with air. The best design, from an efficiency standpoint, will be to maximize interior space with as little weight as possible. Very different from vehicles meant to travel through an atmosphere. So the best design really would be a box -- like a skyscraper in space. It would be neat if the game simulated atmosphere so that it would make sense to design aerodynamic ships for atmosphere and boxy ships for space, but I don't see how that will be possible with current computing/network capacity.
  10. The cause for historical land battles is the scarcity of land due mostly to the limits of transportation. Here there will be a lot of space and relatively fast transportation. Defeating a territory will take time and resources, and so groups will only do it if it's worth the time and expense. I doubt it will often be worth it just to hold the land; it will likely be done to raid what is in the territory. For this reason, I think most stockpiles of resources by small groups will be kept in safezones with territories being used to safely mine and gather small amounts to transfer to safe zones.
  11. As a MMO, the game has to be accessible to a large number of people throughout the life of the game while at the same time have replayability. If flying mechanics are too complicated, it will never be accessible to a large number of people. In my opinion, NQ has attempted to strike the perfect balance here. You build a ship with elements and the game will autoconfigure it; yet, players can get into the code to specialize and add efficiency. The system is accessible while having plenty of replay value in terms of configuring new ships. Any kind of mass mining will eventually make the game inaccessible for new players. Both because they will not be able to compete in gathering resources and also because mass mining will lead to too much of a resource advantage for existing players. Personally, I hope some resources can be mass mined to an extent; for example, minerals used to build buildings or the basic structure of space stations. I don't think mass mining these resources will necessarily ruin gameplay and we will need a lot these resources if we are going to build the cities and structures the developers want us to build. Ultimately, the replay value comes from the emergent gameplay. It will be up to us to make the game continually interesting.
  12. I would hope that the players login position would be fixed to the construct when you log off so that you login into the same position within the construct. NQ has hinted that FTL could still take days, weeks, or months to reach other systems and so the player would need to be able to logoff in transit and be able to log back into the construct later in the flight (or upon arrival). I'm excited about the potential pirating, stowaway strategies this could create. For example, I am hoping I can send a character to into a neutral or enemy construct when it is unguarded and log off if I know that ship is going to fly to another system (or mining camp). Later, I hope to login with this character still in the ship at its new location (or with the cargo hold full of stuff I can now steal). Of course that would always be a risky strategy.
  13. Yes, but I was assuming all calculations would be handled client side. The server would only transmit one string (weapon used, location of shooter and target), then receive updated information of the damage (which needs to be done anyway). Also, this would only be needed for long range weapons. I would also assume a good deal of short range combat would be with lasers.
  14. To further explain, my understanding is that once a shot is locked and fired an algorithm will calculate what damage is done. So if there is a shot the system will calculate things such as weapon fired, structure hit, distances, and result in specific damage from zero to the maximum damage depending on the luck of roll (somewhat random chosen value within the range). Once the shot is fired; it's just math. How I see this working, ideally, is that a firing ships client sends a string through the server that a shot has been locked and fired. The string could include the location of the firing ship, the weapon used, and the location of the target. This string can pass through the server to the targeted ship's client which will initially calculate when that shot will reach the target ship based on the weapon used and locations of the ships. The target client then waits the required time to impact and at the time of impact makes the final damage calculation taking into account the end location of the target ship and whether any defensive elements were used (like flares or interception laser or projectiles). It's all just math. So nothing "in-game" on the server side actually affects the shot. This also shouldn't effect server load too much since the server only sends the shot string one time between the clients. It really only adds extra load to the target ship client since it now has to make two separate calculations (when will the shot hit?... then how much damage?). I suppose an extra string may be required by the server registering weapon and defense numbers to complete the final calculation if there is a concern that players will hack their client and change the values of weapons and defenses. Then again, I don't really know where the combat calculations are made. Maybe they have to be done completely server side because of connection issues?
  15. I don't mean manual dodge; I understand that once a shot has been fired the physics are locked in so that nothing can be done in the "real world" of the game to avoid the shot. I've also seen the Dev blog on the combat system, so I understand that once there has been a lock and fire it's up to the calculation. What I'm wondering is whether there is a means to impact the calculation between when the shot is fired and damage hit. Not really in the physical world of the game, but in the math. So, for example, if an enemy locks and fires on me I understand that I can't really out run it and that if something like another ship comes between us it really won't effect the shot (I can't out run it or truly avoid it). But can I deploy flares that register in the equation to lower the chances of a direct hit simply as a matter of math. If I am farther away at the time of impact, can that be registered in the math to reduce damage?
  16. I understand why the combat system will work on a targeting system. My question is whether the success calculations for the combat system will be "locked in" and calculated when the shot is fired or if the success calculation will be complete when the shot should hit the construct. For example, if an opposing construct locks and fires from a distance that will result in my construct being hit in 3 seconds; could I do anything in those 3 seconds to reduce the chances of a successful hit? Can I deploy flares or some kind of defensive system that reduces the chance that the shots fired will hit my ship or is there nothing I can do once the shot is fired? If I accelerate away from the shots, can I reduce the chances of a successful hit. I'm not talking about collision physics; rather, whether the algorithm calculating success is made at the point of impact or firing. I could imagine that a lock and fire from construct A returns a calculation that an impact will occur on ship B in 3 seconds. 3 seconds later a calculation is made on that point of ship B taking into account any defensive systems deployed or evasive action that work into the damage/success calculation (could also recalculate distance at this point to effect the damage).
  17. I am very excited about the possibility that this game will be released in VR. I think VR was made for a game like this and would really add to the immersion. I know NQ mentioned it is a possibility (they said it's the reason they went for a first person point of view). This was actually a big selling point for me. I know there is funding available for developers from both Oculus and Vive. http://venturebeat.com/2016/10/06/facebook-will-double-its-250-million-investment-in-vr-content/ What are the chances of VR being available for the initial release?
  18. I think the Griefing concern is ruining the aesthetics by buildings ugly structures and wholes just to ruin the game for others. The Devs have made it clear that resources (except possibly around the arkship) will not regenerate, and they shouldn't. A big part of the game mechanics is the limited nature of resources in an area forcing organizations to move on. A market for transporting new players to unmined safe zones will certainly develop if needed. I don't think this will be a problem and I think everyone should spawn at the original arkship, even after the area is depleted. The original safe zone will organically develop into hubs for organizations who will gladly take new players to unmined safezones as a part of recruitment or just for some cash. I also don't think the world will turn "moon" like. Strip mining will not be a good option because they will be prime targets for raid. They will be impossible to secure. The Devs have confirmed that the game will not have realistic physics for planetary structures like caves (it will be like minecraft). So I think it's fairly safe to assume that players will do the majority of their mining under the surface with limited entry points. I'm actually very excited about these gameplay mechanics because there will always be the risk of running into another player/groups mining shafts or being raided.
  19. You really can't compare the DU economy (or government) with the real world economy, they have different goals. The real world economy involves real people and the goal should be to most efficiently allocate resources justly among those people. DU is a different story; the end goal of the economy should be to create the most enjoyable time for all players (regardless of how much time they can devote). It's a game. The point is to be a game. The only way to balance gameplay to allow new players to join is if they are able to gather resources at a fairly comparable rate to all veteran players. Otherwise, the game will shrivel and die because new players will not be able to compete; they would be at the mercy of the players who control the resource gathering. While it is very true that the DU economy will be very inefficient; the goal isn't efficiency; the goal is balanced gameplay. Futhermore, an efficient economy that allows maximum resource gathering would eventually allow organizations to build a nearly limitless fleet of ships and cities. I would like to see a distant expansion allow some mining elements to give a slight advantage at resource mining; but this should not be in the game initially. Also, elements shouldn't allow a player to mine when the character is loggen in but inactive.
  20. I would hope this would be the case, that constructs can crash and be destroyed, but that still presents a game play issue. Players could crash big blobs of whatever on enemy bases and bury them even if it doesn't hurt the building. Of course, crashed ships could simply be destroyed and disappear. But again that would create a "burned earth" incentive to crash your own ship to prevent being pirated. I'm curious to see how this is going to work.
  21. I've given this some thought too. In space, the most efficient design is what maximized space since there is no air to deal with. So boxy and ugly will be more efficient. I fear space in this game will eventually look like it was overrun by the borg.
  22. It appears that they are releasing player customization in the official release, but holding off on construct v. construct until a later patch or first expansion. I am happy construct v. construct isn't a first day feature since I think it will help players make initial developments without construct weaponization. My only disappointment in no construct v. construct initially is that it seems like we likely also won't see it in the beta also. Who knows though, since it looks like they will want to add it soon after, we might get some beta construct weapons prior to the initial release.
  23. Better yet, let players write code through LUA to use whatever hardware they like. I could imagine players designing their own physical controls and marketing them.
  24. Wallfacer

    Stealth

    I'm more concerned with personal stealth than ship stealth.
×
×
  • Create New...