Jump to content

CyberCrunch

Alpha Team Vanguard
  • Posts

    71
  • Joined

  • Last visited

Everything posted by CyberCrunch

  1. I was just about to post a question about how to deal with all the community content, but yama was very fast to answer that... So thumbs up for his wiki!! To prevent the same discussion going on for the new wiki, we should first define some guidelines how articles on the community wiki should be handled. I think we can learn from all the arguments in this discussion, and integrate them as rules for the new wiki. Basically everything that has been said also applies there. My main concern is neutrality and factuality of the information. As I've already expressed before, I think templates should be a good idea to easily channel the large amount of content the community will produce... Also every org should be allowed to create its own wiki article to prevent discussions about game politics through the wiki. This might be a bit tricky to handle, but I think could work with certain restrictions. Btw. i'm very happy with the outcome of this! These are exactly the problems to discuss early on, and it's a great to have such a clear conclusion!
  2. I'm also supporting RightBigToes side. Unlike most MMOs where conventional wiki is enough, Dual Universe is especially centered around player generated content, which should also have its place in the official wiki! If you look at the design of the RDMS system it especially allows to build very unique social structures which would be worth a wiki article, just because of their complexity. And organizations are not the only thing that will become relevant. Especially in context to the recent Devdiary I would include ship-designs(based on blueprints), cities, player-designed-machineries (e.g. Arcades, and other DPU based things...). In short I think of it as the real world wikipedia: everything that is "relevant" for a player should be documented somewhere! If it has no place in this wiki, I'd agree to yamamushi to create a separate wiki for that. (however not the optimal solution) However I also agree with the concern that orgs will misuse the wiki for self advertising. To prevent that all orgs could be forced to use a universal "template" for the article. Thereby only neutral and fact-based information would be allowed, which would also be more easy to maintain. The other topics in this "player generated content"-section should follow the same template... This would actually create a lot more effort to maintain the information on the wiki, but I'm sure it would benefit in the long run. Also it would get more people involve to participate in the wiki, as they will want to create articles for their own content tere!
  3. This Devdiary is really amazing news. The "game in a game" part was one major reason for me to pledge this game. These customizable interfaces will actually not only be useful for games, but even allow us to build quite complex machineries in stations/spaceships that will serve all kinds of functions. The best part is that NQ doesn't have to develop any of these, as they provide a universal development-platform which allows to create everything! But first I'd have one question: which ways are we able to interconnect different "Programming Units" together? I get that you can connect things to the DPU by dragging lines to various components. But what was not shown is how different DPUs could talk to each other. Obviously there are various technical reasons not to simply allow a DPU to get access to another DPU. But a very simple component (e.g. comm-antenna) could function as input/output interface between DPUs. For the Arcade games that would mean that you could play against other players, and even create tournaments to win some Qunata! For the Screen element it would also be nice if the screen itself could be used an input device (aka touch screen (ok. maybe for a later expansion...) The possibilities will be endless!
  4. Great, I'm happy that my apprehensions regarding tab targeting were not necessary. To be honest I haven't found the time to read all the other topics about the DU combat system, that's why I felt the need to post this suggestion. What Twerk an Lethys posted is of course far better than that simple "action combat" system I was thinking about! What do you think about the UI design I mentioned? Do we need life bars, and status popups, or do more subtle icons provide enough information in combat? Here is a better image of the Battlefield icons I mentioned: This could be adapted to DU-Icons, like avatar, core unit, turret, engine, reactor, comms, and what not... I know it might be a bit early to discuss this, as there will be no combat during the alpha-phase. But we could still share our opinions for what is necessary for "immersive" combat.
  5. In the last couple of weeks lots of good ideas for the combat mechanics of DU have come up. This got me thinking what the visual "experience" during combat will be. I highly value realism in games, because it creates an atmosphere for truly immersive gameplay. However DU will not be a simulation game, but a MMO first and foremost. Therefore we already know that combat system will be based on a tab targeting, because it only creates minimal server load. The risk about tab targeting is that this system could create a combat experience like many other MMOs have (most famously WoW): This supposedly "epic" combat is just a bunch of avatar-goo with damage effects all over the place. I hate this. -.- This is actually quite typical for "fantasy genre" MMOs, and of course not what NQ is trying to build. - The first issue I see with MMOs is the visual "feedback" players get for their attacks. It's actually useful to see what effect your attack has made, and see which class the other players are so a group can focus fire a certain enemy. However to fill the screen with numbers and flashing colors just breaks the immersion. I would suggest keeping combat effects as subtle as possible. As this is a Sci-Fi game there could actually be a realistic explanation for overlaid stats. e.g. as augmented reality created by retinal implants. The effects should have a similar design to the overlay for building mechanics that we already see in the game. The combat overlay could then even be further upgraded/customized for different classes/roles in combat... (Edit: E.g. A gunner needs more information about enemy shields/hull-structure, but a medic would just need health information about his comrades, and a engineer would need to know the current status of different ship parts... thereby unnecessary information could be hidden, without actually obstructing players in battle!(to elaborate Kurocks suggestion)) This image shows the interface in Battlefield, which is a perfect example for subtle overlays. This design should be applied for DU combat too. So ->no life bars, ->no numbers, ->just a little Icon that determines the faction and type of the targets. - The second issue of tab targeting is that people have to be very close to each other to deal any damage. I would like to see a more realistic range of at least 200m. I know DU won't be a shooter game, but I see no reason why we couldn't make it "feel" a bit more shooter-like. A lot of MMOs already have a more shooter like mechanic called "action combat". Thereby it's necessary to actually have the target always in the crosshairs, otherwise the attacks just don't hit at all. A good example would be Elder Scrolls Online. The targeting mechanic would also allow to have some sort of cover behind voxels, as targeting would be based on an actual "hitbox". With this mechanic a player could run into his ship for cover. As soon as the ships voxels are covering the line of sight to his avatar, he's no longer targetable. However now his ships core unit would still be targetable, which has a lot more HP. - This actually raises another issue: The combat system should not distinguish between AvA and CvC. If an Avatar shoots at a construct it should just be a normal attack with the according hitbox of the core unit as a target. In total the game would need 3 different types of targets: 1 Avatars 2 Core Units (bigger core = bigger hitbox) 3 Turrets (turrets inside core units should have their own hitbox) (Edit: Maybe even other functional components, to create more variation in combat(to elaborate Lethys suggestion)) If these types of targets reach 0 HP they just explode, leaving a wrackage behind. Everything else is just not targetable, and can only be destroyed by mining it with the nanoformer. This should be good enough to create very interesting combat situations, without fancy voxel damage calculations like in Space Engineers! Ok this last part has drifted a bit off topic, but I hope you get my idea for a immerging combat experience. So what do you think? Is realism important, or do you like colorfull fireworks like in WoW?
  6. I am seriously worried about how every single discussion in this forum seems to turn out: You either agree with Twerk or get insulted by him… If this goes on it could end up damaging the community and the development of this game! Newcomers reading this might think DU is only played by a bunch of trolls, and people might stop posting their suggestions, because they fear to be insulted. We should all be hyped about the cool features DU will have, but this just creates hate and distrust in the community. The worst thing is that Twerk is actually making some good explainations against devus argument, just the way they are packaged is horrible. Only YOU can decide TO STOP insulting people, Twerk! There is nothing the rest of us can do about it… But now back to topic: I actually like the idea of a revival system, and energy draining mechanics. In fact everything that makes the combat more complex/challenging is a good idea. An overly simplified combat system like in Minecraft would be kind of boring for an MMO. The suggested features are actually pretty standard in a lot of combat oriented games, and MMOs. This is basically what a buff/debuff system comes down to. In addition to the “energy drained” debuff, there could also be a lot of other effects, like stunned, blinded, poisoned, slowed, and all the other things you might know from other MMOs. However it’s not like everyone should be able to spam these debuffs. Instead it should allow people to take special roles in combat. These features could also be implemented in CvC, as a construct should just behave like a single Avatar in combat. In regards to the revival system: This is also a very important feature, as getting killed has such big consequences that it should not happen by accident! So every time your HP reaches 0, you could enter an incapacitated/unconscious state. In this state you would have eg. 50% of your original health, so it would provide some buffer before finally being killed for real. Some games allow you to actually do something while knocked out (eg. to fight back), however I more like the way it’s done in DayZ where the screen just gets black, and you have to hope your friends are nearby to revive you. In any ways, all these features should probably be added after release over time… so we will be able to discuss everything in more detail to prevent the combat to become unbalanced. @devu: I understand your argument for a more simplified combat system, however I think it wouldn’t be much fun to play. Thanks for your civilized contribution to this discussion.^^ Now let’s all please continue to talk about the actual game now!!
  7. Hm...This topic has drifted in quite a different direction than what I anticipated. I wanted to focus more on the actual game experience than the technicalities of how many players the servers can handle. My concern is actually the "experience" players will have during release day. This IS an important topic, as this will be the first impression players will get from the game. I think my suggestion would actually be more FUN than the original concept where everyone spawns at one point. - no overcrowded spawn, where you can't even read the name of players anymore. - no walking for 20km to get to any valuable resources (outside the save zone). - equal chances for everyone, without favoring those in the first login wave. (EDIT: I'm talking about Pang_Dreads suggestion of staggered starts!) The "transport shuttle" concept is basically a shortcut for players to get where they want right at the start, without influencing anything else in the game. Having only one spawn for new players is completely fine if there is an actual city that is welcoming them, but at launch everyone will just start mining right away as there is nothing else to do... I have the impression this forum was more open minded in the past. We need to welcome fresh ideas from new people, even if not everyone is so well informed with all the devblogs and forum-posts that were already made for DU. It does not mean that NQ has to listen to every idea that gets posted here, but it could be an inspiration to get a different view on important game-design decisions! (EDIT: But of course I have no problem to hear people disagree, just please keep things civilized....) We'll see were the real problems are during alpha/beta, but now is the time to discuss in which directions this game should go. So please keep discussing...
  8. Even though this topic came up several times already, it seems we have not jet found the best way to handle the release day issues of DU. A lot of good suggestions were already made here: https://board.dualthegame.com/index.php?/topic/9884-conflict-at-the-beginning/ or more recently here: https://board.dualthegame.com/index.php?/topic/11158-different-start-systems/ However I'd like to focus more on solutions to get a good release day experience: Problem To my understanding the save zone will be a very crowded place at launch. To have all players on one server might be fun as soon as they are distributed around the whole planet, but at launch everyone needs to go through the arkship-"bottleneck"! Here some numbers to give an impression of the flood of players: There are already over 9k backers for the game right now, but I'm sure after a successful alpha/beta phase we will see at least 10 times the number for release. And of course everyone will want to join on day 1, as they don't want to fall behind in the race for the best spots on Alioth. Let's be optimistic and say that 10 Players per second can join the server (the rest will be in a waiting queue). After about 3 hours all 100k players would have joined the servers, but the area around the Novark would look like a sea of players, as there will be a lot of people waiting for their friends to join, before going out of the save zone. Even NQs advanced server tech would not be able to handle this situation. Solution A solution to prevent an overcrowded spawn point could be to distribute the players to 6-12 separate spawn points, with separate resurrection nodes and NPC-traders. This would also distribute server load to 6-12 medium sized population clusters instead of one high population cluster. Also every point would only need to supply 1-2 players joining every second. To keep this in line with the lore the temporary spawn points could be "transport shuttles" provided by the Novark to facilitate the colonization. However the first tutorial should be running in an instantiated room inside the Arkship, so players can go straight for mining, as soon as their "transport shuttle" is ready. The transport shuttles should be placed right at the edge of the save zone(which has no resources!), so players can start mining right away. To assure the path out of the save zone is always free there should be a small no-build-area leading out into the wild. Even without gun technology PvP will develop early on, in the form of blocking people out of the save zone by digging holes or walls around the boarder of the shuttle. Thereby people can't sell their minerals to the NPCs or even get killed because they fell into a hole. These temporary "Anti-Troll-Roads" would prevent this. (Maybe not necessary, but I've seen this happen in Minecraft before!) After the first rush (after 1 week), the shuttles and all their infrastructure should disappear automatically, or as soon as the first TU is placed in the respective area, which is proving that the settlement is self sustainable. Legend: Red - Novark | Orange - Transport shuttles | Blue - Border of save zone | Green - Anti-Troll-Roads (Number and location of the territories might be wrong, but the problem is still the same) In addition there could be certain points all around Alioth where players can teleport to, thereby giving the opportunity to get directly into the outback. This would reduce the sever load around the spawn points even further. Especially smaller Orgs might want to get away from the densely populated areas as fast as possible and start building in the outback of Alioth. However this should be a one way ticket, and only be available during day 1! Far away areas should still be hard to reach, and without support of NPC traders it will be harder to build up in these areas. But a lot of players will want exactly this "isolated colony" experience. Legend: Yellow - available spots to teleport to. A side note about hovercrafts: Even though JC stated hovercrafts will be very easy to build, they should still need several hours to hover around the whole planet. So they should be good enough for commuters around the save zone, but the outback will still be hard to reach. Only after the first spacecrafts are build (1 month after launch) colonies on the other side of the planet are reachable within minutes. That's the reason teleports are necessary at start... I'm sure there are a lot more aspects I've missed out, so please let's discuss how you think a good launch day experience should look like!
  9. I’m not trying to trigger anyone, it’s just important to keep discussing these matters, to find a good balance for everyone. Thanks for pointing that out, I haven’t thought of that problem... Obviously this feature was not intended to be used that way. Maybe ship turrets could be limited to be activated only inside the sphere of influence of the territory unit of the organization that owns the ships, or Stargates should have a no automation-zone. Furthermore automated turrets could have a boot up time, e.g. only become active after the ship is parked for 1 hour. They could also consume huge amounts of energy while active, so it’s impossible to keep them running 24/7. Others have made more suggestions to limit automation, but I’m not repeating everything again. And it would be great if we can come up with more constructive suggestions to balance that mechanic! Just to put into perspective: If we would abolish automation altogether players would be forced to stay in the game as long as possible, as they would be in constant fear that someone blew up their stuff. For people that are only able to play on weekends, this would "kill the game"! (this is especially valid for smaller orgs.) Of course organizations with a very active playerbase would still be advantageous, but others will be able keep their place in the game.
  10. Very interesting discussion! I think wizardoftrash is onto something with the computing power mechanic. Not only for balancing constructs, but also to create a more interesting ship management mechanic for the crew while in battle. Combined with Shynras post about ammunition/energy/fuel system players would run around a lot inside the ship to keep everything alive. Enabling automated defenses for "inactive" constructs/ships would also make sense. It would not even cause much stress to the server, as the defense only gets activated if another player(the enemy) is nearby! However I have to disagree with the idea of linearly scaling down the firepower of automated turrets for actively piloted ships. This efficiency difference might prevent a wide spread use of auto-turrets, but some rich players will still abuse this to build "doomboxes". e.g. I'm sure we will see capital-ships that are able to sustain a crew of 100 players. Even if this ship would run completely on auto-turrets, it would have a firepower equal to 30 players (with your math)! So after a while we would only see p2w people flying around with incredibly inefficient capital-ship Core Units packed with auto-turrets!! What we really need is a sort of maximum limit of how much DPS a single player can deal. So if a single player is flying a capital ship, it should only have to firepower equal to 2-3 players at max. If the same ship is parked however, it could have a firepower equal to 50 players, because it's not possible to use this firepower offensively. I have to agree with Twerk on this: "Don't fly what you can't afford to crew" Another issue is turret spamming inside bases. To prevent that there could be a limit on how many turrets can be active in a certain area, or the automation script should only run for 1 hour and have a cooldown. Another solution would be that players can transfer their firepower to auto-turrets when they go offline.(like I was trying to explain in Rippers thread) Thereby it would not be a big deal if a few players drop out during a large battle... (because of RL or whatever xD) It's nearly impossible to find the right balance for every situation, but at least we came up with some interesting combat mechanics...^^
  11. Totally agree with that. So many posts just go back and forth without adding any value to the actual discussion. We should all act like grown-ups and get over this. Back to topic: The real challenge is how to figure out a system that is fair for all combat situations. Even without automation players who invested the most resources in their ship will always be superior against other players... Because of limited resources NQ will only be able to provide the most basic combat system anyways. But it will gradually get more interesting, flexible, and engaging through expansions over the years. My previous suggestion would just add another option for that. For now we already have a primitive mechanic of "over night" protection in the game: After revisiting the http://dualuniverse.gamepedia.com/Archive:Kickstarter_Comments it seems protection bubbles are exactly meant for that purpose: Somehow I had the impression these bubbles would only last a few minutes to have time to get out of the bed and log into the game... but with this mechanic my mine is safe! Waiting 2 days for the attack would create other problems, but this should be part of another topic...
  12. Ok, I get this is a very emotional topic for many people, but please let's focus on the actual arguments. @Twerk: Please try not to be biased against me, because of other posts I've made in this forum. I just tried to make a constructive suggestion regarding the game mechanics. Just because I like automation it doesn't mean I'm antisocial. And to be exactly clear: I am totally AGAINST multiboxing/pay2win. A skynet takeover would be exactly what I do NOT want! But that's nothing to discuss in this topic now... Back to Topic: I'm more of a peacefull miner type-of-player, so I have a personal interest in the defensive mechanics in this game. Mines are usually placed were the most valuble resorces are, so they are a prime target for pirates. To my understanding shields and protection bubbles are meant for combat between active players. The problem I am focusing on is how do you defend your bases over night? Protection bubbles are not meant for that. My example might've been a bit too specific. But more in general: any organization which has mostly players located in one time zone will have problems to defend their constructs! An actually valid concern of my suggestion is that it could be abused by multiboxers. To prevent that I would simply suggest making it harder to activate these automation scripts, e.g. by requiring a very high skill level, making the turret less effective, or making the player die when the activated turret gets destroyed. Thereby players should only use this feature when it's absolutely necessary. No matter how it's implemented, I think these advanced combat features should be added in a expansion after release. So we have enough time to figure out the perfect system. In the end what everyone wants is a fun, but challanging combat experience.^^
  13. Combat is a very complicated topic, as there are endless ways PvP will be carried out outside the safe-zone. This discussion mostly focused on active ship vs ship combat, where I agree that 5vs1 should always win. If the 1 player would buy 100 automated canons it would just be pay2win! (Linking cannons together is a good compromise though) But jacobean brought up another important point for static bases: Obviously NQ already provides "protection bubbles" for that situation, but I think these are only good for short protection, to give the defenders time to react. However the attackers are always in favor, as they can plan their attack during a time where the defenders are in lower numbers (eg. 5am). To counteract that the defenders could "transfer" their firepower to others, when they go offline. Of course only for static constructs and for 4-8 hours to prevent abuse. An example scenario would be a big mining station with 50 players that gets attacked during the night: The miners placed temporary automation scripts into the turrets as they expect pirate raids. 3 players from other timer-zones play "night guard", to keep the scripts running. Then a group of 10 pirates try to loot the mine. They break through the defenses and loot some minerals, but as the automated cannons are still dealing damage to them, they have to retreat. If there would be no defense at all, they would've been able to level the place to the ground! Again, BALANCE IS KEY. We need to provide mechanics that are the most fun for ALL types of players.
  14. DevDiary Updates - March = Orbits confirmed, FINALLY! Thanks JC! I think they came up with the best possible solution for this mechanic. It also works completely different than what we've discussed previously... xD To my understanding it is intended to be a simplified version of KSP orbits(but without apoapsis ect.) -> once a Object reaches a certain speed (escape velocity) it maintains that speed in a circle around the planet. Everything too slow will just fall back down to the planet. The orbit-speed gets slower the further away the object is from the planet. At a certain distance the speed gets to 0, which represents the free space. Even though I'm happy this feature was important enough to get into the alpha, the explanation JC gave us was very vague: Why did he say that the engines have to be "shut down", and then it "starts to orbit" the planet. I somehow have the feeling these "orbits" are actually just some scripted manipulation of the "acceleration" of objects. Here are some of my concerns: What happens when you log out while your ship is orbiting? Are you able to match speed with an orbiting space station (for docking)? How are collisions between objects orbiting in contrasting directions managed? (it will get very crowded around Alioth!) Will space-debris also stay in orbit? Will asteroids and moons also orbit around planets? Will objects be able to orbit around moons? I guess the details of these mechanics need to concider these exceptions, but luckily there is still some time untill September.
  15. Oh well, it seems you are right about the radar-element. After revisiting the devblog I even found this picture: So we definitely will have some sort of "hard coded" functionalities in each element. But as the picture shows players can still chose how they want to implement the enemyAt() function in their design. In regards to display UI, there will definitely be predefined widgets for each element. (like the fuel tank widget from the February devdiary) And as Shynras already posted in this thread: https://board.dualthegame.com/index.php?/topic/10939-guide-to-html-css-for-the-ui/ we will definitely be able to "customize the behavior in LUA" and "reskin them with HTML/CSS" to quote what JC said in the video! I really need to study the devdiarys more carefully instead of making wild speculations on how I would implement the UI interfaces! XD The reason I don't like fixed modules, is that they tend to limit the usability of certain modules.(eg. radar only in ships for combat) On the other hand this gives NQ more control and prevents abuse of modules that were intendet for completely different things.... I guess these topics have been thought through for several years now, and NQ knows much better what they are doing than we members who are only thinking of what we want in the game ourselves. Anyways, in regards to the door problem: This functionality would definitely be "nice to have" at some point, but for release I'm very happy with the key-and-lock design. Besides that it's more complex to implement (even if it's only running on the client) I think NQ could introduce this feature as a valuable element for orgs in the later game... There will still be lots of new things coming, especially after release!
  16. That is a great concept how sensors could work in the game. It is very important that they are designed modular for many different use cases, not only inside ships! The way you described the data-flow is exactly how I think NQ wants to build them, especially that they could reuse the data, that the client needs anyway to display things ingame (without active sensor modules)! However there are a few things I would like to add: I very much dislike the idea of "hard coded" elements. Display elements should be screens where you can display anything you like. The element itself would only define the size (like 400x400px). The display should be controlled by a DPU that is using LUA-UI library to visualize the input data. There are already a lot of libraries especially for that purpose: http://lua-users.org/wiki/GraphicalUserInterfaceToolkits These tools work like Swing(java) or Qt widgets, and you could easily program something that looks like a radar-display. (or use the script of someone else) Thereby the data flow can be much more modular: ===== Flow of Data to the Display ===== Sensor(detected IDs) --> to the DPU(process sensor-data) --> to the DPU(radar-widget) --> to the Display(400x400px) The great advantage is that everything could be customized in much greater detail, and even mix informations from different modules! The same with weapons: Let them only input xy-rotation and shoot commands. If anyone wants auto-attack, they can script that! If I understand this correctly, the server would need to constantly check if the player is close to a DPU and than activate it. Why not use a remote-control item that the player has to carry around. If he triggers the remote-control a predefined DPU gets activated. (if in range)
  17. Yes you are all correct: constructs already have theire own coordinate system, which is the reference system for objects inside (or very close to) the construct. Also only changes are only stored if blocks are changed, no matter how the movement of the object is. But all this has only been shown with small constructs moving around.... Obviously I've no idea about the current state of the game... maybe the size is no problem at all and everything is working already! To let planets rotate and have a big gravity sphere will be a scripted behavior anyways. No playermade construct should start to rotate at a certain size, even a Deathstar. xD A little tricky is how the transition-zone from one coordinate-system to another will be handled. But that can be said for smaller constructs, too. What happens if a shuttle starts of from a carrier that travels at warp speed? I'm very curious what NQ will come up with in the following DevDiarys. They sure have lots of challenges to come.^^
  18. Well maybe I'm overthinking this and planets are just like normal constructs (with special properties). But somehow it "feels" for me that these gigantic structures must be handled differently by the server. No matter how efficient their engine is, you have to update the voxel positions somehow... and this is resource intensive!! We also know that you can't dig into the planets core, and only 1km high, which might also be to reduce the server-load. That is exactly the challenge! I think it could work as I described it, but that is depending on how the engine would handle this situation.(especially replacing voxels with a 3D model when far away) As we saw in the February DevDiary "smooth transitions" while rendering planets is a problem they are actually working on right now.
  19. Ok this is not what I meant about orbits. xD I've no idea how "constructs" are represented inside the game engine. But apparently ships are already pulled down when they are close to a planet, so planets are already a sort of special area inside the game. The next step would just be to make that area rotate. Because of the server-load it's not possible to constantly update every voxel on the planet to create the rotation. But the planet could be in a special instance that looks static from the outside(like a mega-voxel, created through a static 3D image of the planet, that is updated once a day). Vice versa everything outside looks static from inside the planet. In the transition-zone of the planet it should be possible for ships to see each other, if they are close enough. So it's not like an invisible wall when a ship enters the planets sphere. When a ship got through the transition-zone the actual voxels of the planet are loaded. I know it will be quite hard to make everything look smooth here, but maybe this could work with the current technology of the game. Most people are making suggestions by saying "I want that in the game". They then expect the devs to do their magic and solve all the problems. I think it is our responsibility to at least discuss HOW these mechanics could be implemented!^^ True, but I only meant it should look like an orbit ingame... This is very unlikely to happen. Traveling between planets will be very expensive and happen long time after release. Therefore by that point we will have developed some mechanic to display where the nearest planets are. The ships interfaces are also customizable, so I'm sure someone will create a LUA script for that!
  20. When I think of it, rotating planets are realy the best possible mechanic to handle orbits! ^^ The open space will be static, but the planets/moons will be contained in a rotating sphere (like my 1. suggestion in smaller scale) Inside the spheres any ships will just be pulled downward by gravity, so no orbit is possible. The boarder to open space will need a sort of transition-zone to adapt to the speed difference. Furthermore because voxels can float (at least inside the same construct) we could build some pseudo "geostationary" satellites by building up from the planets surface to the border of the sphere. Any constructs outside the sphere will actually be static, but look like they move around from the planets perspective. -> no immersion break One question I've left now is how high can we build inside a planet/moon? They definitely need to limit the building height, because of the transition-zone...
  21. I know constantly moving things around is usually avoided in a voxel based game, but its very immersion breaking to see that everything in the universe is just static. JC also talked about how they want to move the planets around the sun. But apparently in the current state of the game only the skybox is moved around and every voxel is static... Of course there are more important problems on the roadmap, but there should be at least some mechanics to create the illusion of movement in space! (at lease after release ) The first precondition for this mechanic is of course to keep the server-load as minimal as possible, so I came up with some basic suggestions: - Rotating spheres: Around every planet and sun in the universe is a rotating sphere that defines 0 speed (or static voxels). So as long as you are inside a sphere everything seems static. Therefore all moons / asteroids are static inside a planet-sphere, and all planet-spheres are static inside a sun-sphere. If a player moves from one sphere-area to another, it's speed is mapped to the new sphere, and he is slowed down to match the 0-reference of the sphere. An obvious problem are the transition areas between 2 spheres, where objects are moving at very high relative speeds to one another. A solution could be that Objects are always pulled away from transition areas, so no one can park there ship in these critical areas. - Fixed orbit "rings": Everything in the universe is still static, but around every planet, or moon there are fixed rings that define where an object can "orbit". Ships that want to orbit around the planet can "dock" to these rings, by entering a marked area. The ship then gets teleported into the ring with 0 speed, thereby preventing crashes with objects inside the ring. The size of objects in the rings is limited, so they can't reach through the ring-walls. I think especially the 2. option would be easy to implement without breaking the rest of the universe. Probably players will find a way to abuse, or break this mechanic. But at least this would enable some sort of orbiting. I'm sure NQ already considered some solutions for that problem, but are working on more important topics. Maybe we can find a compromise that looks cool, without breaking the game.^^
  22. I also like the idea of a traveling city/station/ship (whatever you want to call this) And the game engine will defiantly allow it to build these things, as JC himself always uses the Deathstar reference and says that planets are just large ships! But before we continue the "why" part of the discussion, I want to make some assumptions about the game mechanics. Thereby we can base our thought experiments on how things would actually be realizable. The following statements are only based on my personal understanding, so obviously things might be completely different when the game launches: - Protection bubbles are basically just shields. They will consume huge amounts of energy, so the bigger the bubble, the heavier the infrastructure to maintain them. (they are actually more designed to give players time to react in case of an attack) - Things in space should orbit around the nearest gravity center, like shown in the following image: Obviously this will only be a simplified "orbit".... But with this mechanic the people living on the ground can trade with the space-city, every time it traverses the area. - To move these things around, they have to overcome a certain inertia that holds every object in place. e.g. if 2 engines are needed to accelerate a small 1 ton space ship, then 20000 engines are needed to accelerate a 10000 Tons space station. (the less engines the slower the acceleration) The easiest way to get that many engines would be if the inhabitants of the station would pull the station with their own ships that are docked inside the station, like shown in the following image: This would still be a very slow, and costly way of traveling. But it could be used to relocate the station to another planet every few month. Now back to "why" to travel with the whole city. For me it would be the convenience to have all your stuff always with you when you travel. And to be protected by the sheer numbers of players in the city. Space stations might be valuable targets for pirates, but are also way harder to crack, than these lonely cargo ships!
  23. It's fascinating how varying the suggestions are. While writing my post I was more thinking of "amusement park" features to add some interesting places to the game. However more established institutions like bars, and apartments will also be a important part of a city. That was also my main idea to start this thread: to get an overview of what players want to see in the world. Like with minecraft, players will create stuff, of which the developers haven't even thought about! (arguably in both directions One more thing that came to my mind is artwork: - people will create pixelart, architecture, and beautiful landscapes/parks - we could see art-contests, and galleries to display their work @Kurock, sorry if I misrepresented DICE. After reading your description, I had the impression you want to be more of a gaming commission (so make credits by hosting games, like a broker). That's why I put you on gambling topic... But you do great work! I will definitely use your service ingame, soon!
  24. The community will have a big responsibility in DU. Since DU is designed as a sandbox game there are basically no predefined activities for the players to do. One of the reasons NQ is providing voxels and LUA-scripting, is that players should build any content they want inside the game. As discussed in various other threads, it depends on the players how interesting the cities will be in the end. (e.g. https://board.dualthegame.com/index.php?/topic/10816-opinions/ or https://board.dualthegame.com/index.php?/topic/10544-in-game-activities/) However what I see is that most players/orgs are only focusing on their way to get resources (miners, pirates, merchants). This is of course how we will spend most of our time. However this is only the monotone grinding part of DU. I guess fighting over resources is a somewhat exciting part of the game. But that is also what I don't like about EVE. This game has created very complex political systems, but the daily activities in the game are often just boring grinding jobs. Where do you go to have some fun?? I mean it’s quite pointless to build giant mega-structures when you can't actually do anything inside them! In most other MMOs the developers have to create special events and quest systems to give players something to do in the lategame. A good example would be Star Citizen, where nearly everything is prescripted. In DU it’s all about us, and WHAT WE WANT to see in the game… I predict that at some point every city will develop a variety of activities/minigames that are designed by players. Why would anyone bother playing these? Because you can win credits! With the contracting system we could even create world championships, ect. Here is a list of stuff I’d find interesting (mostly based on existing games): - Arena games (capture the flag, team deathmatch, FFA) - Ball games (like rocket league with hovercrafts) - Racing games (like mario cart) - Gambling games (like what DICE is planning to do) - Board games (like tabletop simulator… I would love to play some risk-like game with the map of Alioth)^^ - Museums (about the history of Alioth (for new players)) - Rollercoaster (e.g. with catapult/ physics glitches) - Special events/gatherings (like https://board.dualthegame.com/index.php?/topic/10756-alioth-aerospace-expo/) - Use networked DUCs for minigames (nice way to spend time, when you are traveling/waiting… no idea how the terminals are going to work, but we’ll figure something out. xD) Feel free to use those ideas for your projects, or tell us what activities you would like to do in the game. This thread is not about how these things could be realized. (There are already threads in the Gameplay Mechatics forum) Obviously NQ has to limit the complexity of the game at release, but as the game evolves I’m sure more and more of the above will become possible. So I know it’s very early to talk about this stuff now, but it’s important to think about the possibilities, so people can say “I want to build this!” When the Game is released I hope someone creates a list of all these unique places in the Wiki, so people can visit them. tl;dr: What would you like to see in the game to bring cities to life?
  25. I think my initial post probably scared off some people who would consider using an administrative -Chatbot- in there org. As I said previously the whole "AI for president" thing is more of a long term vision / neat fantasy of mine. For now I'm just playing around with some (hopefully useful) chatbot features. Anyone who want to help this project can just suggest some features they would like to have in their org. Until now Warden was the only one who contacted me in this regards... ----------------------------------------Dev-Update----------------------------------------- I finally got a basic of the RSS-feed reader working. Luckily someone else has already done this, so to get a reader was not the problem. (source: http://alvinalexander.com/python/python-script-read-rss-feeds-database) However getting the output to be posted into discord/TS is a little trickier. Somehow the python feedparser I'm using has some difficulties converting special characters. No idea why it is necessary to have 2 different characters for ‘ and ` ,or – and - . My keyboard can't even produce these characters!! (maybe French keyboards) Anyway: after filtering out all special characters, it's now possible to search for new posts (in the announcement section) and post the text in discord. But please don't do posts with Chinese characters, or I have to start all over again!! xD
×
×
  • Create New...