Jump to content

Difficultylevel

Alpha Tester
  • Posts

    1
  • Joined

  • Last visited

Reputation Activity

  1. Like
    Difficultylevel reacted to SiLeNCeD in Movable Parts and Pivots   
    First off, Great start to a game!
     
    I did add something like this suggestion to https://upvote.dualuniverse.game/, but couldn't find it. Figured I'd share here and not seeing quite the same suggestion, so I hope this one is worthy.
     
    I would like to see the ability to attach special dynamic movable elements that allow functional movement of elements and/or voxel 'parts'/'groups'. Things like a hinge, pistons, rotators... stuff like that.
     
    One example would be a dynamic 'Hinge' element that allows attaching 2 elements and/or voxel "parts" (a group of voxels considered as an 'object' - after a selection is copied and pasted, which defines 'grouping').
    Elements are easy to consider an 'object' as they are. Individual voxels must be moved to the movable hinge element and separated from the rest of the construct so it can define a grouping of those voxels that will allow movement (think of it as creating a sub-group of voxels in order to define a piece that can be manipulated using movement). Dev note: This can likely be set using the copy and paste feature (I copy a selection at a certain point and when I add the 'movable' object (and it is voxels), I use paste so that it treats it as a sub-object of the entire construct)  
    Workflow (Door using hinge):
    User buys a Movable Hinge element User attaches the hinge to an opening in their base (the base acts as the 'locked' object) User attaches a wall piece to the unlocked side of the hinge By default, the hinge element will think the 'wall piece' can swing from start of the 'locked' hinge side all the way around to the other side - 360 degrees) User then sets the movable side of the hinge to have a 'max open' at 45 degrees from the 'locked' side of the hinge A controller can be added to use the default 'open' and 'close' functions (users could set individual stopping points as well to give it extra position options that the control could pin-point and/or cycle through). User steps back and now has very new options to how they open the entry-way of their base, the ground, a garage, etc.  
    General Examples:
    The first thing I thought of when this popped in my head was making an x-wing fighter. Unfortunately, I didn't proceed because I love the functionality of the actual x-wing, which are wings that will separate after you've taken off. The hinge element I described would actually be perfect for that... attached a second wing directly above another using the hinge, set the angel to like 15 degrees (you can flip and repeat to do the same thing to the other wing if you want them to open away from each other) and attach a controller that would open the wings together. The door I mentioned in the above workflow. It also opens up some other opportunity about creating very flashy entrances with interesting moving mechanisms (build whatever size Tardis you want and throw on some swing doors). Note: It may be worth while to define a 'max amount of moving elements' a person can have within a single construct. Imagine you're flying in and you are within range of a remote door at your base. You click a button and the ground separates open (using sliding door elements or possibly the hinge element), then a landing platform raises up (using piston(s)). You land, hit the button again, the landing pad lowers you into your personal hide-away and the doors above close once you're clear. Very batman-esc lol... but actually a nice plan for "pirate stashes" and  Note: The movable elements could probably support the different sizes like cores, but they should also support a max weight. That gives DU more control over what the user is trying to add to the element (ex: Max weight stops user from attaching a building to another building since that would distract from the reality of the game and doesn't line up with physics in general) (Added on 1/14) Gun force - You see a ship coming in. Looks like it's just a freighter. As it gets closer, hatches open on the sides of the ship (sliding doors or voxel doors - flip with hinge or slide open using pistons), guns slide out (pistons) and you realize it's a pirate/bounty hunter. Note: On a fun note, you could have a "camper" ship (think "Space balls")... you bring it to an event for display. When you arrive, you hit a couple of control boxes and your camper ship extends out "for show" rooms with fun and interesting decor.  
    Additionally... I believe this can actually set a 'foundational' framework for "attachable constructs" where you can link one construct to another and it will move together (this one is pretty straight forward, but a really clear example would be something like a train where I have my dynamic construct at the front pulling smaller dynamic constructs). A funner example would be the Enterprise D... where I build the saucer section separate from the body. In that case, attachment allows control to be ran in different sections, but to move the 2 constructs as 1... then depending on the situation, allowing from my "Number 1" to take the helm and split off for tactical or escape advantage. It could also be a desperate move to save half your ship (perfect movie moment).
     
    I've attached a draft of the hinge (more of a side view just to keep it simple). What are your thoughts?
     
     
     

  2. Like
    Difficultylevel got a reaction from tj0108 in [Discussion] DevBlog: Rebalancing the Universe   
    So the change is welcome if the rest hinted at can be implemented. But and there's always a but, this doesn't fix anything. It creates a class system of have's and have not's. So the market which was a mess to start with, as it was largely irrelvant except for converting mass into quanta to buy the assets you needed, will now still be irrelevant for anyone who isn't poor.
     
    Now is the time to try this but without a fully developed system and even more importantly, a complete lack of a meta system, making careers definable or desirable, we're back at square one.
     
    The game is missing so much and anything, anything, is welcome but this will not lead to the depth required because it's a finite game design loop, not one of infinite variety or viability.
     
    I honestly think this is a clear example of a finger in the dyke of bad game design.
  3. Like
    Difficultylevel got a reaction from Maitre_NaDaoine in [Discussion] DevBlog: Rebalancing the Universe   
    So the change is welcome if the rest hinted at can be implemented. But and there's always a but, this doesn't fix anything. It creates a class system of have's and have not's. So the market which was a mess to start with, as it was largely irrelvant except for converting mass into quanta to buy the assets you needed, will now still be irrelevant for anyone who isn't poor.
     
    Now is the time to try this but without a fully developed system and even more importantly, a complete lack of a meta system, making careers definable or desirable, we're back at square one.
     
    The game is missing so much and anything, anything, is welcome but this will not lead to the depth required because it's a finite game design loop, not one of infinite variety or viability.
     
    I honestly think this is a clear example of a finger in the dyke of bad game design.
  4. Like
    Difficultylevel got a reaction from kulkija in [Discussion] DevBlog: Rebalancing the Universe   
    So the change is welcome if the rest hinted at can be implemented. But and there's always a but, this doesn't fix anything. It creates a class system of have's and have not's. So the market which was a mess to start with, as it was largely irrelvant except for converting mass into quanta to buy the assets you needed, will now still be irrelevant for anyone who isn't poor.
     
    Now is the time to try this but without a fully developed system and even more importantly, a complete lack of a meta system, making careers definable or desirable, we're back at square one.
     
    The game is missing so much and anything, anything, is welcome but this will not lead to the depth required because it's a finite game design loop, not one of infinite variety or viability.
     
    I honestly think this is a clear example of a finger in the dyke of bad game design.
  5. Like
    Difficultylevel reacted to TheGeek in DevBlog: The Maneuver Tool and Disconnecting Ships - DUscussion thread   
    If I can't maneuver tool the voxel board that Yeeted itself 10km away back to my base, then what do I do? Fix game breaking bugs before nerfing the tools we would use to compensate for those bugs.

    The Alt-F4 was used to compensate for flaky mechanics. Fix your game before nerfing the tools we use to make this game bearable to play.
     
    And nearly nobody travels at sublight speeds anymore, EVERYONE warps. So this nerfing of Alt-F4 only hurts those trying to not have to repair their ships over and over because of game-breaking bugs. And combined with the fact that elements will have a fixed repair amount, you are going to have people ragequitting in droves...
×
×
  • Create New...