Jump to content

Samedi

Alpha Tester
  • Posts

    101
  • Joined

  • Last visited

Everything posted by Samedi

  1. Erm, no, they are artisan skills in real life! You literally can't do them in DU unless you have specific real-world talents. That's fine, but I think the game needs to find more ways to support solo and small-group-of-friends play styles. Just my opinion of course.
  2. The problem with the tier system is that a factory, making tier 5 items by the thousand, produces identical quality stuff to one making just a few; which really means that the economic competition is a brutal race to the bottom. The simulated economy has to be an approximation of real life, of course, but it also has to be designed to make the game enjoyable and allow a range of play styles. The gist of a lot of what you're saying seems to be "it's a game, it shouldn't mirror the bad bits of real life" and I agree wholeheartedly. However, right now it feels like it mirrors one of the most pernicious aspects of real life - that you just have to work for a big company! Well, yes, it's an imperfect analogy of course. I think you may have taken it a bit too literally
  3. I hear what you're saying, but I think it could be made to work in a way that added depth to the simulation without being too onerous. For example: it should take literally years to decay completely we should have much better tools for bulk replacing/repairing things maybe you could buy a repair unit which did it automatically whilst the core was still powered (we need power to be modelled), or by slowly burning fuel
  4. To be fair, what I was getting at was just that any forum like this becomes impossible to catch up on after a while through sheer weight of posts. So the notion that things keep coming up even if they've been discussed many times before is fairly inevitable. You might be right about NQ's use of the forums, but in that I personally would cut them some slack (for once!). There are so many channels right now, that it's a bit of a nightmare for any company to know where to engage. I engage about DU mostly here and Discord, and it annoys me intensely that those two places overlap a lot and I can't quite decide which one to use (and I'm not consistent when I do choose!). Add all the socials into the mix and it's a nightmare...
  5. Lest I sound too negative, I should probably just add that the stuff that @NQ-Ligo has been doing recently, and posting about potentially doing in the future, is very encouraging. It will take time, but I have a small glimmer of hope that not all is doom and gloom...
  6. Back in the mists of time, before NQ had completely broken my spirit, I started writing a series of opinionated blog posts, about DU scripting, how I was doing it, how I thought it should work, and so on. My intention was to slowly open source the framework I'd built for my own stuff, but to do it in an episodic way with examples, rather than just dumping a load of impenetrable code on the world and running away. Then I kinda got disillusioned with the direction of Lua in the game (and the game itself), and so the whole thing got put on hold. Recently I've been noodling around in the game again, but I'm mostly avoiding scripting as I know it will depress me too much. That said, I realised that I don't think I ever really shared the blog posts I had written. For what it's worth, here is the opening post. Think of it as a hysterical historical document. Maybe I'll revive it one day if I ever get my mojo back. Possibly something in one of the posts will help someone. Probably a lot of the experienced scripters will disagree with my approach. That's ok. I did say it was opinionated.
  7. I agree it's unlikely, and I've no doubt that the problems right now are greatly amplified by NQ running out of money. However, in effect the two systems in my suggestion would just be two instances of the server (dare we say "two shards"...), the investment in time would actually be minimal. In what you're suggesting you'd still need to add some new assets and modify some aspects of the game (eg the map), and to enforce the money transfer rules etc you'd need to make a distinction between the two locations that's more than just spatial; I suspect the sum result of the work would be similar either way. I'm not sure I understand the fly-for-12-months idea. Nobody is actually going to do that. Sure. I've been reading these forums for years too. They're inevitably a tangled swamp which nobody in their right mind has the time to catch up on - that's how this sort of forum works. If someone didn't happen to be part of those discussions, they might not know. If we stop saying things because they might have been said before, there's not much point saying anything...
  8. ...although I'm not sure it will really help with my specific point of giving smaller players a way to compete with the monoliths. I'm fully in favour of it for other reasons though - not least of which being a basic sense of realism...
  9. Yeah, power/energy is definitely something that would help with a lot of design flaws. Fairly mind-blowing that it wasn't there from early on. Some sort of quality stat might be another option. The main point - and again, this has been said multiple times in this thread by others - is that a reset on its own won't fix the economy, and without it being fixed, we will just end up back where we are in a few months. How to fix it is up for debate but that it needs more than a reset should be self-evident.
  10. Good suggestions all, but I think it will take more than that. For the economy to work, individuals / small orgs need to be able to offer something that mega-factories / large orgs can't. For example being able to make better stuff, but slower / more focussed, giving it scarcity value. Individuals need a niche that allows them to earn money (other than just as a mining-drone), and everyone needs an incentive to work and trade together (other than just joining an org to do PvP).
  11. Honestly, I think that the design ship has long-since sailed, so I'm posting this more in the spirit of floating an idea of how it could have been, rather than any expectation that it might happen. That said... I've been thinking about what is broken about the economy/industry, and the main thing that occurs to me is that unlike real life, there is no real niche for "artisan" builders. In the real world, mega factories and mega corporations do exist, and they do largely dominate the market for cheap consumer goods (whether we want the game to mirror real life is maybe a question for another day, but at least we can probably say that in this detail, the game isn't massively inaccurate). However, in the real world, there are also people and smaller companies who make high-quality, low-volume stuff. You can either buy a mass-produced Ford, or you can buy a custom-made McClaren super car. The super car is ridiculously expensive, but to some lucky people it is worth it, because it is very rare, and very high quality. Likewise you can buy some chairs from IKEA, or you can find someone who makes amazing chairs by hand. You'll get something extra from the artisan furniture maker, but it will cost you, because it takes a long time to make them and each one is unique or at least very rare. This is where I think the Dual Universe simulation falls down: there is no way to express the quality of something, other than the very crude tier system. Furthermore, there is no sense in which an "artisan" builder can get themselves to a position where they can make better stuff than a mass-production builder. Even worse, really the only barrier to building high tier stuff is having the ridiculous amount of money required to buy the schematics - which I suspect makes it virtually impossible for someone to do it without first becoming so rich that they can effectively make a mega factory if they want. What I think would help with this would be if every item in the game - from ore through pures through parts all the way up to elements - had a quality stat. Probably expressed as a percentage, so that it has a large, continuous range, rather than just the crude "low, medium, high" kind of thing that tiers represent right now. Being able to make high quality stuff would require high quality input materials, high quality industry equipment, and high skills for the particular item(s) being built. If you want to specialise in making something to a really high quality, it should be possible to do it without being insanely rich, but it should take a lot of time; enough time that no single user could ever make everything at the highest quality. Megafactories could still exist, but they'd have to compromise on quality. This would carve out a niche for individuals to become artisans, and they wouldn't even necessarily need to be making actual elements. Maybe all you ever do is make top quality screws! If someone is making top quality military engines, they will need those screws, and they may not have enough time / skill points to make the screws themselves, so they have an incentive to buy yours. Orgs will still exist, and still have power, but that power will derive more explicitly from the combination of the skills of their members. What I like about this idea is that I think it might create more of an incentive for people to work together, and it might make the trading economy healthier and more diverse. Of course, the quality stat would also have other uses. Equipment could reduce in quality over time if it was used, so that eventually it "wore out" and you'd want to replace it. Weather effects could slowly erode the quality of anything exposed to the elements, which again would give a reason for things to be replaced. This should be slow (taking months or years) but gradual. Repairing an item would bring it back to full functionality, but reduce its quality - which would serve the same purpose that the "repair three times then you have to replace it", but in a much subtler and more lore-friendly way. As I said at the start, I doubt very much whether design changes of this scope will ever happen now. It's nice to dream though...
  12. This is the only scenario that actually makes any sense, and which serves both goals of allowing new players to start on a (more) level playing field, and allowing existing players to retain their hard-won stuff. I would do it slightly differently, but it's the same principle: - add a new solar system - new players start in the new system - existing players remain in the old (legacy) system with all their money and stuff - allow free travel between new and old systems; but you can only take blueprints with you - not property, and not money That allows existing players to blueprint their stuff and recreate it in the new system if they want to, but they have to bootstrap themselves again financially. As discussed elsewhere in this thread, they will still have a large advantage due to the skills they've got etc - but at least they won't start with vast cash or equipment reserves. Crucially, it also allows existing players to still visit, use and modify their stuff in the old system. Which means they don't instantly lose years worth of investment in creative endeavour. It also means that they can customise things before blueprinting them, which makes it a lot easier to just take the bits they want to recreate. Over time the legacy system could be deprecated and maybe even removed, but it should be in the order of years and not months before that happens. Could NQ do this in a reasonable timeframe? In theory, the two systems are pretty much two parallel setups of the game, so it ought to be pretty easy to bring up a new solar system. They would probably want to change names and maybe configurations of planetary bodies, so that's some work. The main new bit of code would be a mechanism for "travelling" between the two, which I think essentially means logging out of one, into the other, whilst preserving / moving any blueprints in their nano pack. That's obviously some work, but it is work that would be very valuable as it could also be used to allow people to share blueprints with the PTS - which makes the PTS a lot more attractive as a place to try things out, prototype, build, etc.
  13. I'd prefer a wipe, but honestly, it'd just be papering over the cracks. There are fundamental problems with the game design, and other fundamental problems with the implementation of that design. I love the game and have invested a lot of time in it but honestly I think that the point has been reached where it would be better to learn some lessons from what went wrong with DU, and start from scratch with something new.
  14. All the timescales sound way too short to me. Two weeks is nothing. I'd like to see things a bit more stretched out. Give us a month or two with territory transfers enabled so that we can get our heads around which territories we want to keep and who needs to own what. Then a month or two more with rents enabled but no territory reclaiming / forfeiting. Let that bed in before you start throwing people off their tiles and destroying their stuff.
  15. Yeah, I see what happened here. The problem is with the quoting system. I probably selected that sentence in the post where you quoted it, and then hit quote, and it stripped away the original attribution and made it look like you'd said it instead. So unreserved apologies for any appearance that you'd said it when you didn't. However, if you'd approached the whole thing in a less aggressive manner, and maybe pointed out what had probably happened, the penny would have dropped immediately and you'd have had an instant apology and correction from me. It doesn't take a lot of empathy or thought to work out that I had absolutely no reason to misrepresent what anyone was saying, so probably it was an honest mistake.
  16. Sorry, what? You said "Drop Lua". I said "Lua isn't really the problem". Maybe be careful to use the right words, if you said "Drop Lua", but didn't mean "Drop Lua". Yeah, apologies - quoting SNAFU.
  17. EDIT: it was Kirth Gersen who I intended to quote, and not Zeddrick (I accidentally quoted a quote, and the attribution got messed up). Apologies for any confusion caused. Lua isn't really the problem, and it's very lightweight and relatively easy to integrate into other apps, so it's a sensible choice. The problem is everything that surrounds it - the tooling, support for external libraries, versioning, debugging, and so on - along with the richness (or not) of the in-game APIs. Just switching to JS wouldn't necessarily solve those problems. You wouldn't automatically be able to use npm and just pull in any random library you wanted. There would be all sorts of implications in terms of overhead, and the logistics of making sure that every client was running exactly the same code. Most of those problems could be solved, with the right level of investment, but they could also be solved for Lua.
  18. Hah, yes. Obviously it would be work, but a v2 API would give the opportunity to really clean things up. At the very least, there should be some sort of `system.getAPIVersion()` call. Given how dynamic Lua is, that would be enough (though not ideal). Not versioning a public-facing API is a bit of a schoolboy error tbh.
  19. Sorry, but you can, you just need to add a versioning scheme to the API. All existing scripts use v1. You could add a completely rewritten v2, and have a setting on the controllers where script authors can opt into v2.
  20. Rather than an all-or-nothing cancellation of warp, it would be a lot more interesting if hits on it reduced its reliability, which in turn gave the possibility of it failing later, and dropping you out of warp in the middle of nowhere. Similarly it would be nice if other elements could take hits and become unreliable, spring leaks, etc, etc. That moment when you think you've got away, then you realise that you're leaking fuel out into space and are about to become a sitting duck...
  21. On that topic, why don't NQ organise some actual events on the PTS? Something along the lines of "we're all going to have a big battle in location X, on date Y, come and test the PvP with us". You could do similar events for other changes too, for that matter: "let's all fly over to location X and test out the new docking rules"... etc.
  22. As a coder I am biased, but instead of “IF IT’S BROKE, FIX IT” I'd rather hear “IF IT’S MISSING, LET THE PLAYERS ADD IT”. I get that most players in the long-run may be more interested in using stuff than building it. I also get that you may worry that opening up more flexibility is a Pandora's box that could lead to game-balance problems later. However, to quote that well-known fan of open-world sandbox space simulations, Voltaire: "Perfect is the enemy of good". This is still a beta. You have a finite number of designers and coders at NQ, and a lot to do. You have another army of both out here in the game: stop trying to do everything yourselves! If you give us more API hooks and better tools, we will prototype things for you, and we will fill in a lot of the gaps for now, whilst you focus on the infrastructure. With a modest number of additional hooks I'd say that we could have a community-run mission system and player markets already; they wouldn't be perfect, but they'd exist! If the community adds something and NQ later replaces it with something built-in, few people will complain as long as it is an improvement... and if it's not an improvement then arguably you should be spending your time on something else instead.
  23. I agree that this is a dilemma. Do I spend time experimenting in the PTS, or advancing my actual progress on the real server? A suggestion that would help for those of us who build things: implement a JSON interchange format for blueprints, then allow us to copy/paste them, so that we can move them between the servers. This would allow people to spend time building potentially complex things in the resource-rich PTS environment, then deploy them in the real environment. We wouldn't gain any material advantage - I could build a palace in the PTS, but I'd still only have a blueprint on the real server. However, the time on the PTS would become productive time, and we would be able to experiment with exotic materials, so we'd have an extra incentive to be there. You could probably achieve this with another mechanism for moving blueprints, but I would suggest JSON because from time to time there are bound to be incompatibilities between the two worlds - a text based format is flexible enough for us to hand-mend things. Having a JSON format for blueprints would also open up a whole range of possibilities for external tools (material swapping, for example).
×
×
  • Create New...