Jump to content


Alpha Tester
  • Posts

  • Joined

  • Last visited

Profile Information

  • Alpha

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Megabosslord's Achievements

  1. Anyone else annoying by this glitch in the voxel render? Shows up as a ripple in curved shapes, and a random diamond shape in flat surfaces - and can't be smoothed out. Appears to repeat at multiples pf X:Y 32:
  2. @Elias Villd The fixed-price physical coins option is certainly the easiest to implement and it opens a workaround for a 'Reverse Dispenser' in that you can then control access to a normal dispenser using a combination of doors and sensors, and dispense coins to a recipient. But it's complex for the player to implement, multiple points of failure (e.g.: connection lost during the access control process), and also open to exploitation since you can easily lag-clip thru doors/sensors and abuse logout/login. (I had this working for my casino payout booths, and was going to pay out wins in warp cores since they seemed like the most stably priced commodity, then I watched the price heave and would have lost millions. It's also why I built the 'lag box' to test how hard it was to bypass the booth security. Don't even ask. For these two reasons alone 6 mths of work on the casino - well before Oasis existed - were abandoned.) The best compromise - short of implementing a robust system (which I still don't think is monumentally hard) is that payments out from the Reverse Dispenser go into a pending state that can be batch approved. Still far preferable to manually tallying up pay-outs, looking up players IDs in the current interface, typing in values, and tracking it all offline. The current payment system is godawful for high-volume transactions. As for the hinge, again there's a simple compromise if you don't want to deal with toggling off collision between hinged constructs (again, shouldn't be nightmarishly hard, but anyway), and that's to start by only implementing it with static and space cores. Not as good, but still a step in the right direction that can be built on later.
  3. I don't know how you Wipers develop this delusion that a wipe is going to miraculously bring in a bunch of new players who wouldn't play otherwise - aside from your own wishful thinking and a peer-group of likeminded friends probably reinforcing your bubble. There's just no evidence ever in any game that a wipe does anything more than swap out some old players for new less-committed players resulting in long-term decline. And those who are unhappy with their lot in the game - access to territory or resources - are just replaced with a different group of people who missed out on the latest land rush. Add to that it's also a reversal on a commitment made at beta launch ('magic BPs') and the result will be even worse.
  4. I fear you're right, but I hope the investors are bold and ambitious enough to give the lemon one more squeeze. If done right, their equity is far safer. If they're really tapped out, I'd do another small round of capital-raising before pushing the product. Re-energizing the player-base is also a force-multiplier in word of mouth for launch.
  5. Yeah, true, the rep system needs some thought - to keep it simple would rely on players giving persistent rep points to other players, and org agents doing the same on behalf of an org. The algorithm would be something like: my rep score = SUM OF [points awarded to me by any player or org ÷ total points issued by issuing player-org* x rep score of issuing player-org** x time subscribed***] ...with 5 important caveats: - This logic of weighting value of points (* above) serves several purposes: It normalises points issued across orgs/players - I might be handing out millions, while others are issuing 1 at a time. But the weighting must be based on the base values at the time they're issued, since I could change tactics later. This also gives the issued points their intrinsic value, since the more points I hand out, the lower the value of my individual points - thereby incentivising me not to just hand points out to anyone. It does away with the need to limit points issued by either a financial cost or other false cap (e.g.: only issuing as many points as you've earned.) - All players orgs must start with a base non-zero value or the algorithm fails (** above) - Weighting by time played - capped at launch - (*** above) means we're all effectively earning more points to spend with time, while also gaining credibility for playing for longer, so you can't just spin up a bunch of new orgs and alts to game the system. - Total SUM is necessary, rather than an average, to avoid gaming with a high score from a single 3rd-party and to incentivise dealing with as many other parties as possible. It also means a org rating quickly becomes more valuable than a rating from a single player. - You do need to be able to look up the players profile and see where their points have come from. Transparency is key to an effective 'points' marketplace. Players will quickly figure out if my rep score is bogus, or has been gamed through reciprocal arrangements or org stacking by double-checking on my profile. - The fact you can just buy points from someone else may sound broken, but it's actually a feature - since you can then be remunerated for building up your own rep and selling your points to others with the important caveat above that I need to be able to see if a rich org just paid for it's rep. [EDIT: I've looked around at other rep systems, but it occurs to be it must be bespoke since the dynamics of players, orgs, and subs are all unique to DU.]
  6. PROBLEM: Most will agree NQ appear to be running low on resources, but also that the game is not release-ready. NQ are also sitting on a huge opportunity in the gaming marketplace. Minecraft and Roblox are both multi-billion dollar franchises with 100s of millions of players, and paying out a demographic dividend of a user base outgrowing "children's" games and looking for an adult equivalent. Minecraft av. player age is now >25 yrs. while 15% of Roblox players or ~30 million players are over 25yrs. Both these franchises started by small indy studios demonstrating the magnifying effect of properly leveraging user-generated content (UGC). Both are rich in lessons learned. Meanwhile, the apparent focus on collecting refugees from EVE Online (of which I am one) is a dead end. It's a mid-tier <500k player game and the whole studio is worth a measly $500m. Done right, there's no reason NQ couldn't be sitting on a billion dollar franchise as well. But this huge opportunity is time-sensitive. If they don't captivate some market share soon, they'll be competing with an improved version of SC, and Bethesda's incoming behemoth Starfield. Releasing now is death. Taking too long to release is also death. Getting one more release right, and launching well equals a massive potential for gaming conquest. SOLUTION: The right combination of fast, low-cost dev options and some bold new creativity, is required. Here are my TOP 5 suggestions: 1) Basic 1HP voxel-eating critters with an engineerable solution. A simple PVE loop, like the early addition of Creepers in Minecraft, is not as good as full PVE (or territory warfare) but pays a disproportionate dividend and signals intent, and franchise potential - while also adding to immersion, game lore, suspension of disbelief. (It's also totally impossible in any universe that trees evolve with no complex carbon-based life. During Earth's Carboniferous period when trees first evolved, there were already 10ft long centipedes and giant dragonflies. We can even hear them already, for crying out loud.) Even better, critter populations could also be weighted to resources on the tile (i.e.: high value resources require more effort to secure than just getting to the tile first.) But it has to be kept simple for now - no elaborate combat system, Just shoot a critter with your Skittles laser, one hit one kill. And it only attacks a structure when you're logged in, and nearby. It can be iterated on later. 2) A cool new toy with every release - and a commitment to continue this into the future. This is straight our of the early Minecraft playbook as well. In the first year when Creepers, Skellies, red stone, pistons, Villagers, new mobs were dropping with each release, the franchise grew exponentially. For NQ, add something exciting with every drop - a tractor beam, ship-mounted asteroid mining laser, a programmable hinge that lets you connect two constructs... There are many more options (wheels, walker legs...) but they require too much dev time for right now. Put those on a list for the future. Notes on a hinge: Why am I banging on about hinges? Well, I was there pre-alpha when Minecraft first added pistons. The boost on chatter and subs of players messing around with the new tech for months was massive. It was vital (along with adding red stone, which we already have in the form of LUA) to Minecraft's' early success. A simple addition like this pays a disproportionate dividend, ignites player interest, signals intent, and franchise potential. A simple programmable hinge between constructs (along with a multi-core BP) keeps players busy for years figuring out ways to utilise the physics - gates, draw-bridges, giant ship grabbers, prisons, jumping/walking constructs, articulating craft, obstacle courses... and probably a hundred more things I can't think of. But that's the whole point. 3) Reverse dispenser w/ LUA money API. This has been a gaping hole forever, and now sounds close (?) But the simple ability to read container contents and make pay-outs without having to do manual wallet transfers, answers the cries for player-run markets that were promised in the Kickstarter. We can then build our own merchant systems the same way players have built HUDS, while also opening up a million new gameplay options: Insurance companies. Interest, banks and lenders. Stock markets. Salary payments and loot sharing systems. Combine this with 'physical' coins - 1 quanta item with a fixed value that can be bought, sold, stored and shipped like real cash - for even more gameplay opportunities, and a more liquid economy. But most importantly, the ability to script payments creates an incentive system for players to leverage and invest in player-generated gameplay loops: in-game puzzles, racing, treasure hunts, obstacle courses, and so on. This is probably the biggest opportunity of all, since it's essential the whole business model of Roblox - now the biggest franchise in the world. Let the players create games for other players. One player-created obstacle course in Roblox 'Tower of Hell' has been visited 17 billion times, just to get their name on a leaderboard. The popular community-run activities in DU today - AD's Dome, Friday Night Racing - could be just the beginning. The desire is there, just not the tools. Which also brings us to... 4) Full Rep System. If every player had a rep score with every org, and every org with every org, it creates an additional incentive system for player-generated gameplay loops (win rep with my org by delivering my goods... or winning at my challenges) while also helping self-police bad behaviour. A banking system doesn't work without a form of credit history. No in-game games work without ensuring opponent's play fair. Better still, an aggregated rep score for each player built up from their rep with each org, multiplied by that orgs rep with other orgs (so a rep point with a high-rep org is worth more), provides a single metric for all performance while also self-reinforcing the value of rep. I want to get my rep score up, because then my score of someone else more highly valued. Easily built and implemented. [EDIT: Possible rep algorithm described 2 posts below...] 5) 'Test flight' option. Spawn a time-limited copy of the ship on 'pilot only' RDMS. This adds significantly to the FTUE since new plays can go flying in space within minutes of getting started in the game, and give them of taste of what they can work towards when they build/buy a ship. Doing it inside the game world adds to immersion, but spawning in a tutorial-style space is probably easier to code. At the moment, handing someone who just bought a space game a flying bicycle to start out, is underwhelming. SUMMING UP: There are many more even more exciting new features I'd wish for (e.g.: drones w/ no collision damage or weapons capability, combined with the ability to have multiple controllers running at once incl. while far away, logged out, or operating another construct OR a smoother way to parse a RNG variable in LUA back the server to sync between clients) but they all have significant dev cost, or don't work on a client-side engine, and as such are wishful thinking at this point. But one more release crammed with 1-5 above would be a game changer. Everything else can go on a roadmap, if NQ build enough social collateral with the next release. Most important of all though, to get the final moonshot right, NQ must consider their own TOP 5 deeply, think well outside the current paradigm, and canvas players for input.
  7. Here's a question: Wouldn't the Reverse Dispenser (which they've also been circling forever) and/or money API (ability to automate payments based on container contents instead of manual money transfers only) fix this? One of these SHOULD have been done when they first did wallets, per the discussions at the time. If we could build our own merchant systems in-game, it would solve this and a dozen other problems at the same time. (My OP suggestion above is just an easy out for NQ to stop-gap a secondary problem.)
  8. Thanks. Yeah, that's what I thought. It's kind of annoying they're expending dev effort on stuff like fiddling with bezier curves when there's some easy wins to make the franchise more profitable.
  9. I've long suspected that if a new DU player can't get airborne in the first few hours of gameplay, we're losing players. The initial DU loop of building your first space-ready ship is fun for some, but it's niche. The starting speeder is 'meh'. Every other space game just gives you a starting ship that you can pretty easily fly into space right out of the 'dock'. But there's a problem, right? If you give every new player a basic space-ready ship it frigs up the economy. A glut of ships, parts, and destroys ship-builder income. But there's a simple solution: 1) Make the UEF store (much) bigger.. Or have 10 of them around the starting locations. 2) Allow players to take their ship token (which already locks it out) to a terminal at the store and pay a fee equal to X% of the price they set for the ship, to submit the token. (This terminal is most of the new code.) 3) The ship spawns in the UEF store on the existing style of 'for sale' display. 4) New players - or any players at all - can walk up to the display, and choose 'test flight' 5) The ship spawns on a nearby pad with pilot rights only, restricted to the test pilot who chose 'test flight'. 6) The 'test flight' player can test fly the ship for a period of time (or until they die) after which it de-spawns and the player is returned to the store. 7) The player can then chose to buy the ship from the store. The tokenised original is ported to the pad, and the seller receives their moula. Ship builders make money. Creates no ship/parts glut. New players can go flying in their first 5 minutes after FTUE, even before they have any money, and get a taste of what's to come. Thoughts/comments: go.
  10. Got my space cores 50.8kms from Aegis. Now I just need to know if NQ gonna wipe space cores before I build a space station...
  11. Has NQ considered a physical 'coins' object with a fixed value of 1 coin = 1 quanta? If a reverse dispenser or LUA wallet API is unachievable, we could use physical coins as a workaround to make automated or offline payments to other players by dispensing them in capped amounts from existing dispensers (governed by RDMS and/or control access to those dispensers using doors/detectors/LUA) and take deposits via container.acquireStorage(). This would allow (a) orgs to pay salaries or profit share, (b) operate banks, insurance companies, or stock markets, and (c) set up prizes for user-generated games and puzzles without the risk of arbitrage on a commodity with a floating value.
  12. Hmmm. That's mildly annoying. It just needs to work the same way placing a static BP as placing a new static core.
  13. I didn’t get time to try the BP visualisation on PTS. Does it work for statics and snap to the grid of the construct you’re standing on?
  14. And LUA control of rights (check player id) w/ reverse dispenser! (receive item, pay money!)
  • Create New...