Jump to content

ttcraft0

Member
  • Posts

    59
  • Joined

  • Last visited

Reputation Activity

  1. Like
    ttcraft0 reacted to lethak in [DEIM] Deimos Corp. a french speaking, teamplay focused org   
    Hi !

    I am "LethaK Maas" founder of Deimos Corp..

    DEIM is a french speaking organization around the idea that efficiency can be achieved by cooperation and teamplay rather than personal skill only. It was founded in 2012 for the Game Planetside 2 were we waged many combats.

    Generally speaking our approach to every problem is: cooperation towards a pragmatic solution involving a clear military-like hierarchy for the set of task at hands.

    Our members have had long standing careers as gamers on titles such as SWG, EvE Online, Planetside 1 & 2, WoW, Rust, Ark, Space Engineers, Naval Action, and so much more it would span the entire catalogue of available games.

    you can get the feeling of being part of our platoons back in the days
     


     
    or maybe with voice com ?

    We are not a "multigaming" community as we try to only support one game at a time.

    Having stopped officially playing Planetside2 some times ago, we are now aiming for Star Citizen, but we are fully aware it will still take many years before delivering a game enjoyable as a whole teamplay group in the long run.
     
    So, in the meantime, most of us are staying together and are looking to experience Dual Universe whenever possible and with as much people as possible with the right mindset ! (recruitment post)
    The concepts and ambitions are there, and having a sandbox background coming from SWG, I can personally tell it will be a success if delivered as promised without performances issues
     
    Also, I have created a topic on our forums and summarized in french most of the ideas behind Dual Universe in order to spread the word
     
     
    I hope we will see you in the verse, for the best or ...else
  2. Like
    ttcraft0 reacted to Wilks Checkov in Introduction: Wilks Checkov   
    First of all let me start out in saying I would have come around to this sooner rather than later in part due towards a few "unplanned" health issues that have placed me out of action and MIA for about a month. Anyway enough of focusing on the past. . . lets get to why we are all here. . .
     
     
    Introduction:
     
    I am Wilks Checkov; and yes that is my real name, and before you or anyone else asks - I am not related to a Pavel Chekov, the character on Star Trek. 
     
    I am a 43 year old USAF veteran that happens to love grand o space operas. If it has to do with space / science fiction I usually love it.
     
    Most of my time currently is divided between my daughter and my six month old grandson, and my other life long passion: Eve Online, of which I have played almost religiously since the 2003 Castor patch release. Other than that my time is divided between games like Space Engineers and the up and coming release of Star Citizen.
     
    In watching E3 this year I happened to come across the last few minutes of the demo video for a little known title called Dual Universe, and as usual it caught my eye, being in a genre that I love greatly. So after some research I found the website, did some heavy reading on the forums, and decided to come over here and support the community as this title holds quite a lot of promise if they can actually pull it off. 
     
    While we wait on on the devs to get us a game going I will be taking time to get our corporate establishment up and running as well as devising a system of government from scratch. If you or your corporation are interested in joining up feel free to let  me or one of our corporate recruiters know.
     
     
    For now, during the coming weeks and months I hope to get to know you all, and I am looking forward to seeing you on the flip side.
     
     
     
    Sincerely. . .
     
    Wilks Checkov
  3. Like
    ttcraft0 reacted to The_War_Doctor in What happendes when you log off?   
    i dont see the devs being able to force someone to log off in a certain location. but you could force a waiting period where they cant be attacked or move for like 10 seconds. this stops people from logging off as they are about to be attacked. im not sure what happens to ships though. as buildings and such stay and one would assume a multi crew ship wont vanish when one person logs off. NQ doesnt call ships a ship or a building a building. they are all constructs so in that sense im assuming that if you get dc'ed in combat your ship might be gone when you get back and you log back to be spaced or at the nearest spawn point
  4. Like
    ttcraft0 reacted to Archer in New gameplay footage!   
    Since I can't build a proper hype train with DU's system yet we'll have to settle for one built by SWDennis:
     

     
    All aboard!
  5. Like
    ttcraft0 reacted to Anaximander in What are skills? and how do they work?   
    The way I see it.


    You get a sniper rifle.

    You use the sniper rifle.

    You get better at shooting shit from a distance.

    You keep shooting things from a distance and getting better.

    Congrats, you mastered the art of murder from 5 kilometers away.



    Now, let's start with assault rifles.
  6. Like
    ttcraft0 got a reaction from Anaximander in So what Style of ships would you build or buy?   
    Yes, and everything depends on the type of gameplay the ship is used for : for example, we can have a big and slow ship for destroying, or a smaller and faster for infiltration.
  7. Like
    ttcraft0 reacted to Antioch in Symmetry mode for building.   
    This is something that spontaneously came up in my head. Feel free to remind me if this topic has already been mentioned. Thanks.
     
    Okay, so we all know that the building system in Dual Universe is going to be voxel-based. Now, building things in games such as, Space Engineers, Empyrion and Starmade is very easy with the Symmetry mode that works on X,Y and Z axis. But when it comes to Dual Universe, having voxel tools may allow players to build complex structures and more complicated ship designs. So what I'm suggesting is that we should be able to have a building mode that allows players to build things symmetrically. I'm sure there are quite a few problems that can come up, but I'll leave that up to you fellow members.
  8. Like
    ttcraft0 reacted to Pantydraco in Balancing for different player types.   
    Balancing for different player types.
     
    In spirit of "balanced pvp destruction system"
    https://board.dualthegame.com/index.php?/topic/835-balanced-pvp-destruction-system/page-5#entry9398
    Important: parts 1 - 3 is purely theoretical game design nonsense. 4 is game mechanics thoughts. 5 is whole thing conceptually summed up
    First, some important notes:
    1) Very little reasoning of 'why?' will be given. Generally, "all successful mmos do this" will applicable, and they have their reasons. Most  of those reasons also apply to DU.
    NOTE: or so I wrote initially... in practice it turned out to be a 'why?' behind my previous posts. Oops...
    2) The ultimate goal of this nonsense is "Maximize player count while maintaining intended creative direction."
     
    With this out of the way, lets get started.
     
    Part 1: abstract nonsense
    (2) means players of vastly different type and behaviors are target audience.
    Each of their very different experiences must be built to be enjoyable and complete.
     
    Many gameplay systems involve having "negative outcome" for some of the participants.
    Possibility of failure is natural part of 'game' concept, and is usual way of how sustained 'excitement' is achieved.  
    With that said, there are many things to be aware of:
    1) Actual negative outcome generates negative feeling in player. While impact of abstract 'you lose' is very small, actual loss of time causes big frustration.
    2) Excitement generated by negative outcome comes solely from 'possibility' of it, this means:
        -negative outcome must not guaranteed.  
        -it is beneficial if player is involved in the process, and outcome is determined by his actions.
            -well designed feedback loop is desired in such case. Self-improvement is one of the ways long-term engagement is maintained.
    3) Highest excitement doesn't equal best experience. Exciting gameplay should be balanced with relaxing gameplay. Another note, this balance is different for different players.
    .
    .
    Part 2: different player types.
     
    Obvious conflicting player archetypes:
    PvE <-> PvP
    Group <-> Solo
    New <-> Experienced*
    ...
    These archetypes do not describe game-mechanics, but player outlook. Same mechanic can be experienced and will be different to different archetypes.
    Those archetypes are not binary, players often enjoy mix of outlooks. Again, balance varies by person.
     
    PvE outlooks are mostly interested in game-world interaction. This in different proportions involves interest in:
    -exploration of game world (which may come in many forms, sometimes unexpected, like politics)
    -creativity (again, many forms)
    -amassing in-game possessions
     
    PvP outlook on the other hand finds npc game-world boring, and gets most enjoyment of challenging other people. It may come in many forms, and players can make pretty much anything competitive.
    -most common PvP activity is player-vs-player battles, in which both sides risk losing in-game possessions
        - is one of the players was not willing participant, his previous gameplay is interrupted(bad), and in case of loss that gameplay cannot be resumed (very bad).
            -above does not apply if danger and risk are important part of the gameplay experience. Such experience is not desirable for many (arguably most) players, but it does open new possibilities.
    -PvP outlook is not interested in earning assets PvE way, and PvP itself is asset sink.
     
    Group outlook enjoys communicating, and by extension cooperating with other players during gameplay.
     
    Solo outlook on the other hand does not enjoy mixing player-communication with gameplay, or more commonly people who want to experience game through their own strength and knowledge.
     
    *While not a personality trait, player skill largely remains more or less constant during play session, and has arguably the most impact. That's why it should also be designed around.
     
    Part 3: Archetype balance.
    What was said above together with common sense (Ha! more like me not wanting to explain myself) translates into:
        -PvE players should be able to engage in desired PvE gameplay with minimal PvP risk. This should be true for any player skill level and group preference
        
        -PvE players may instead choose different, risky option that has bigger in-game reward. This should be true for both solo and group players
        
        -most of in-game possessions of PvE players should be protected, and have reasonable progression. Independent of player skill level and group preference
     
        -some in-game possessions should be contestable, and also give reasonable benefit. Both solo and group players should have contestable possessions. Player skill should greatly determine safety.
     
        -PvP players should have expected PvP activity points, where there is constant PvP action. This applies to both groups and solos of all skill levels.
     
        -PvP players should have a way to earn valuables via PvP activity. This should apply to both groups and solo, but is dependent of skill, as all such valuables come from other players.
     
        -It is desirable that most of those points come from flexible and not binary system, in order to suit most players.
     
        -Losing possessions without owner's involvement and chance to defend is pure negative
     
        -Group play should reward reasonable material benefits. It is because of inefficency that comes with groups, as well as extra effort, time and risk required to set it up
        
     
    Applying those arguably universal (in MMO sense) points to Dual Universe creative design, that's what I came up with:
     
    Part 4: Actually sensible stuff
     
    I - Safe zones must exist and be readily available, where:
    Assets in liquid form (materials) should be mostly untouchable.
    Small ships should be mostly untouchable online, and fully untouchable during normal offline period.
    Players can build small structures and ships in relative safety without hiding.
     
    Big assets should be touchable when offline to keep universe coherency. Defenders should also be given enough time to respond, so that confrontation is actual PvP. Delayed systems similar to EvE reinforce timers or vulnerability windows are proposed. Safe zone should make it more lax
        All those things should also apply to new and solo players.
     
    With all that said, I propose a system be put in place that generates safe zones based on player activity and gives benefits to all players inside(dynamic anonymous player cities, if you will), and also the one that pushes organised territory owners to extend benefits to anonymous players. Very rough ideas: https://board.dualthegame.com/index.php?/topic/835-balanced-pvp-destruction-system/page-5#entry9515
     
    II - PvE activity should cover whole spectrum from safe to risky.
    example: mining
        -safest place to mine is within core systems, but benefit is also smallest there. These system require minimum investment, and danger is absolute minimal.
        -secondly, there are many many random uninhabited systems nearby, that scans say are not really rich. Going there should cost non-trivial amount of fuel, as well as risking the ship.
    In order to catch you, pirates must either track you there, or must have had scanning satellites there themselves. On the other hand, you can also notice their approach and pre-emptively escape. This should be contest of player skill, with no way one side is guaranteed victory. If you escape, both sides lose because of fuel.
    Those systems should be numerous enough that player attacks are really unlikely. On the other hand, losing a ship is also non-trivial matter. Average long term will depend on player skill in those rare instances.
        -thirdly, there is establishing outpost in random system. You can base from there, as well as do basic refining, which will greatly increase profit. On the other hand, this is great investment of time and money, as well as presents bigger risk someone will stumble upon it.
        -then, there are really rich systems in local cluster, that everyone wants to mine. They are few and rich, and also default area for pirates, organised mining groups, really skillful solos, and player organisations. Those system provide a lot bigger profit, but also guarantee a high risk.
        -and lastly, there are universe wide honeypots. Recently discovered regions of great economical importance. They hold previously scarce materials in great quantities. Because of them, price now and half a year from or before now will differ greatly. All biggest political players want and fight for them, with numerous smaller entities also in the chaos. True gold rush, with insane risk and payoffs
    NOTE: this built solely upon 3 things: number of systems, their payoff, and investment amount. All those things could be very finely balanced and tweaked with actual testing.
    NOTE: this is based upon travel model https://board.dualthegame.com/index.php?/topic/933-am-i-alone-in-thinking-that-stargate-probes-are-a-bad-idea/page-5#entry9459
     
    III - PvP activity should be varied, engaging, and challenging. Pure "I win" mechanics benefit none in the long run.
    Just in the above example, hunters have variety of possibilities: pure combat and ambushes of local riches; tracking and stealth of no-name miners, with possibility of siege; high excitement rush of honeypots. Plus mercenary work to counter all of it
    Group combat has all of it and beyond, with assaulting and defending territory and static assets getting bigger role.
        Important part is, in every situation, outcome is dependent on skill of both hunter and prey. Even numbers are not "I win", in most of those, detection plays a key rule, so bringing bigger force is automatically detriment to the attacker. On the other hand, it is also not guaranteed win for defender. Stealth is their biggest asset, and a single enemy is enough to ruin it. Sure, hunters get delayed, and miners have a second chance to notice a second approach, but solo pirate still benefits of selling convoy's location.
     
    Part 5: Closure & TLDR
    In short, what I call for is segregation of player base based on preferences. Players should be given an option of playing safe or risky. Players should be given an option of playing smart or easy. Risky or less profitable. Solo or group. PvE or PvP. And in every case gameplay should accommodate them. Building should be a right, not a privilege. As should be attacking structures. Solos should be protected from group abuse. Groups should be protected from solo trolling. The gamedesign grail lies not in making a single person dream game, but making a dream game of every player.
    P.S. Version 1.01 - added important note because I wasn't clear
  9. Like
    ttcraft0 reacted to MaximusNerdius in Balanced PvP Destruction System   
    I've been playing games a long time and in recent years I've spent a lot of that time playing survival type games that had some sort of construction / building system. Minecraft, DayZ, Space Engineers, Ark Survival Evolved and many others. All of them have the potential for being really great games, until you introduce players that take pleasure in doing nothing more than destroying other people's work and generally griefing other people. I'm one of those players that enjoys both PvE and PvP... but I get tired of PvP devolving into nothing more than offline base raiding and general trolling, instead of actual intense fights.
     
    The thing that I've noticed is that most systems in place in these games tend to favor the attacker over the builder. Take an example from Ark that happened just last night. A group of friend and I spent 4-5 hours working on building up a decently sized base, essentially building a large aviary structure that was going to house our Quetz (very large flying dinosaur). We were still putting the roof on when we were raided by a group flying a Quetz with a ballista mounted on it and several other flying mounts. They managed to take out the lone turret that was set up and then our 2 flying mounts before we could mount an adequate response. I give the credit for a well coordinated attack, they managed to kill all 6 of us when there were only 3 of them. While frustrating, I can enjoy PvP that happens in this way - being a PvP server, they were surely within their right to attack us. It was our fault for not having more defenses set up and a sentry for watch. But what happened next is where the issue arises...
     
    We had just spent 4-5 hours expanding our base that we had already put probably another 6-8 hours into. So a lot of effort was spent on this base. In the 15 minutes after they killed us all, they managed to knock down half the base, destroy every container and every "machine" we had built. 2 days of work destroyed in 15 minutes. As typically happens in this situation, all of us were so frustrated by this that we pretty much agreed to move on to another server. I've seen this type of thing happen in multiple games, especially DayZ (Epoch mod) or Space Engineers.
     
    I would like to ask that the devs for Dual Universe discuss / plan for a system that does not give such a favorable outcome to the attacker. While I understand PvP typically leads to destruction.. it is "war" after all, this is still supposed to be a video game where we come to play and have fun. Where is the fun if a individual or group ends up leaving the game because of this type of situation? I know it isn't something easy to address, as you need to balance the game for PvP overall..  but please don't make something a builder spent 2 weeks or a month building last only seconds or even just a few minutes.
     
    My suggestion is that structures, especially those composed of harder / tougher components, should have a much higher damage resistance. Steel should not crumple at the first blast of laser fire, or leave a big gaping hole when the first missile impacts. Whatever advanced materials we have so many years from now would be even better at resisting damage. I'm not asking for it to take 2 weeks of steady attacks to destroy a single wall... but please make it take a lot more effort to destroy someone's primary base of operations than most current survival games.
     
    Thanks.
  10. Like
    ttcraft0 reacted to Reverant_Spark in Price model, SAY NO TO MONTHLY SUBSCRIPTION!   
    For the love of god, do not make yet another monthly sub game... There is no legitimate reason to do this... And the only people who defend such a model are gamers with more money than sense, or greedy game developers...
    Make it buy to play, with an in-game cash shop with cosmetic and convenience items, like all good MMO's these days do... Its a fair business model, and you will earn what you deserve, based on how good the game is. Which will give you an incentive to improve it further to make more money. You already have a game which is basically Star Citizen/Elite Dangerous meets Space engineers, that already sounds pretty damn good to me... So you would still rake it in cash wise. And bare in mind whenever a good looking game is free/buy to play, knowledge of it spreads through the gaming comunity via word of mouth like a lightning bolt...
    Monthly sub business models are only utilized by greedy developers who want nothing more than to exploit and rob the gaming community... The monthly sub needs to go the way of the dinosaur, because there are better business models in existence these days... So please, do not use this business model... I want to play this game when its released, and while I have more than enough money to pay for a sub, I will not do it... But if it was buy to play, with an ingame cash shop, I would buy the game, AND spend money in the cash shop if you gave us interesting worth it items to buy in there...
  11. Like
    ttcraft0 reacted to Cybrex in A wild ttcraft0 appeared !   
    Welcome to DU! Be sure to read up on all of the Devblogs, a lot of good information there to go over.
  12. Like
    ttcraft0 got a reaction from Ghoster in What are you gonna do with your new life?   
    I think I will build some cities, space stations, etc, and manage a little community of players. Maybe making a lot of ingame money
  13. Like
    ttcraft0 reacted to The_War_Doctor in A wild ttcraft0 appeared !   
    Welcome sir. And your English is just fine sir
  14. Like
    ttcraft0 reacted to NQ-Nyzaltar in DevBlog: LUA Scripting and Distributed Processing Units (DPUs)   
    (Posted Friday 18th of September 2015 on the DevBlog)     Big news! We just finished designing and implementing one of the most critical and distinguishing feature of Dual: the capability to script any construct that you make. A construct is anything that you build in the game, it can be a ship, a building, a space station, or whatever. It is a physical object, it can move, collide with stuff and potentially include hundreds of "Elements", which are operational units that you can craft or buy, and freely position inside your construct to add functionalities to it. Examples of Elements are: propulsion engines, control units (computers), doors, weapons, batteries, containers, accelerometers, radars, targeters, drone bay, elevator, and many more. The way the construct orchestrates all these Elements is through scripts, and what we call "Distributed Processing Units". Let's dive into it, and see what it can do.   Warning: The following Blog Post implies you already have some basic programming knowledge. If you don't, some parts may seem a bit obscure or difficult to understand.   This is going to be a slightly more technical and longer post than usual, but I hope people interested in the topic will find it entertaining. In any case, remember an important point: you don't need to understand anything about scripting or ship building to actually buy a ship and fly it. You actually don't even need to use a ship at all if you don't want, there are plenty of activities to do besides this in the game. It's a bit like in real life: you don't need to be a mechanics to drive a car, and some people just never drive anyway, they take a taxi. It all depends on your playing style, and what you expect from the game. But if you are interested in creating your constructs and scripting their behavior, I hope you won't be disappointed by the deepness of the gameplay experience we propose.   So, let's summarize again what a "construct" is: in Dual, you can assemble chunks of matter (stone, wood, iron, kevlar, etc...) in any way you like, a bit like in Minecraft, but instead of simple cubes, you can forge almost any shape you like. The technology behind this is called "Dual Contouring". This can be used to build the hull of a spaceship, the walls of a castle or a gigantic statue. Up to you. Attached to this inert structural skeleton, you can add some components called Elements, which are actual gameplay components that you can deploy in your construct to make it functional. In a spaceship, you need propulsion engines, fuel tanks, navigation instruments, one or several cockpits, etc. All of these are Elements. The collection of all Shapes and Elements are what constitutes a construct, which is a whole that can be moved once created and is subject to the laws of physics (for example, it falls if dropped in a gravitational field). A construct can be owned, traded, copied, etc, but this is another story we will discuss in another post. Right now we will concentrate on one particular aspect: how do you orchestrate all the Elements so that they can work together? We will take the particular viewpoint of a spaceship, which is a good way to illustrate the concepts involved, but this can apply to anything you like, including a giant spaghetti monster robot or whatnot.   In terms of game design, we could opt for an easy strategy here. If you have the required number of engines in the right direction (no matter where they are), and you check the list of instruments needed, it would "magically" fly. With this approach, all ships would fly the same. Trying to put more engines, or optimizing their position would be more or less useless. Hoping to have an AI helping with automatic navigation would be up to the engineers of Novaquark only. Fancy a new way to drive your ship? Impossible. How about the weapons system? How about drones? All this would be predefined and more or less rigidly identical for all players. That's not what we have in mind for Dual Universe. While we will provide basic templates to start with, you?ll be able to engineer your construct the way you want. Engines are real (they physically push your ship where they are, with the power they have), gravity is real, weapons have to turn and target (which also requires a targeter). If you are smarter than others, you can get the job done in a better way, get an edge in battle, or in trade by launching the new Falcon X-42 superfighter and change the balance of game combat with new tactics and possibilities. It?s not only about how you can use the predefined capabilities of ships within a predefined classical game setting, but it?s also about how you can redefine these capabilities. We call it: emergent gameplay.   Each Element is an active unit. It can do basically two things: emit "events" and execute "functions". Let's give some examples: a radar unit can emit events like "new enemy detected at (x,y,z)", a jet engine can execute a function like "set thrusting power to 45%", a weapon can execute the function "fire", etc. Technically events and functions are described a bit the same way: a name followed by parameters written between parentheses. The above examples would become something like:   enemyAt(x,y,z) setPower(45) fire()   Events are emitted spontaneously by the Element when something happens for which it has been designed to react to, and functions are services that the element can fulfill when it is asked to by some external agent. When considering a particular Element, you want to know the list of events it can emit and the list of functions it can fulfill. This is entirely defining what this Element is, from the point of view of the gameplay. We call it its "Type".
      Now, how do you orchestrate the interactions between several Elements, each emitting events and reacting to them, fulfilling functions in return, etc? The central notion we introduce here is what we call a "Distributed Processing Unit", or DPU in short. A DPU is a bit like a computer program, an orchestrator. It has several slots in which it is possible to plug Elements, and it contains a list of event handlers that can react to events emitted by the Elements plugged inside its slots. The schema below illustrate this:     Events handlers are conceptually quite simple: they are "condition => action" managers. On one side, there is a conditional filter, which is a generalization of an event from a given slot, with certain parameters set to given expected values, while other parameters can take a variable "free" value. A particular event emitted by an Element in a slot will be examined by all event handlers, and it will trigger the event handlers if the event signature matches the event handler filter.   To give an example: suppose that we have a filter like ?enemyAt(x, 42, y)?, associated to the ?radar? slot. Now the radar slot emits the event ?enemyAt(11,42,66)?. This event matched the filter and so will trigger the event handler. If the event ?enemyAt(12,13,66)? is emitted however, it will not match the filter (because 13 is not equal to 42). The schema below illustrate this point:     On the other side of an event handler is the action that the handler can trigger when the filter is matched. This is where LUA really enters the scene. The action is simply a piece of LUA code. LUA is a very simple and efficient scripting language, for which you can get many tutorials online. You can try this for a start.   Now what kind of code will you write on the LUA side? Basically anything you want, but, as you guessed, it will ultimately contain some calls to functions among those provided by the Elements plugged in the DPU slots. The syntax will be something like: "self.engine2.setPower(42)". The "self" prefix is a requirement of LUA, then comes the name of the slot, and then the name of a function available from the Element in that slot, together with its parameters between parenthesis.   That's it. That's the basics of what a DPU is and how scripting works. Let me summarize: a DPU is an orchestrator, it has several slots in which you can plug Elements. You can then define event handlers to catch events emitted by these plugged Elements, and react by executing LUA code, which includes calls to functions taken amongst the set of available functions of your plugged Elements.   To be more precise, I have to refine this picture a little bit: I talked about customizing a DPU, but exactly what DPU are we talking about? Where is it? In fact, the DPU you want to customize is stored inside a special Element called a "Control Unit". The DPU is started when you activate the Control Unit (go next to it and press the activation key). Notice that there is no problem with having several Control Units (hence, DPUs) inside the same construct, potentially all activated at the same time.   Now, the DPU inside a Control Unit is special because you'll have a GUI to freely customize it (plug stuff into the slots, define event handlers, etc). Actually, you can do even more than what I just described: you can define a set of events that your DPU is capable of emitting (event emission is done via a special LUA syntax inside your scripts). You can also define a set of functions associated to your DPU, and the corresponding LUA code that should be executed when this function is requested. If you remember, I presented the type of an Element as the set of events and functions exposed by this Element when plugged inside a DPU. Actually, the truth is that there is in fact a DPU inside each Element (albeit not a customizable one), and the events and functions of this Element are actually the events and functions of its DPU. Now to the important conclusion: it is not really Elements that you plug inside the slots of your Control Unit's customizable DPU. It is in fact DPUs. It can be the DPU of Elements, when you plug Elements, but it can be more generic or abstract DPUs. More about this now.   One particularly important "abstract" DPU is the System DPU. This DPU is capable of emitting events when keys are pressed. You almost always want to plug the System DPU, because you want to control your scripts with keystrokes bound to actions. So, typically, you will have several event handlers in your custom DPU to catch action events emitted by the System DPU. The System DPU is also capable of emitting "timeout" events when a timer is due, or at regular intervals, and many other useful functionalities.   You know enough now to script a simple spaceship controller. You need to put a least one Control Unit in the ship, and customize its DPU. Inside this DPU, you will plug the System DPU (typically in the "system" slot), plus at least 3 engines pointing upwards to lift the ship, and 2 more engines at the back of the ship to make it move forward. You need also to plug a gyro (more exactly: an inclinometer), which is an Element that provides the getPitch and getRoll functions, to know about the pitch/roll angles of your ship. And that's it. Now you set a timer with the system DPU (call the system.setTimer(0.1) function to set the update every 0.1 second) and catch the corresponding timeout event. When caught, you can then associate the LUA script that will query the gyro about the pitch/roll and use these values to correct the intensity of thrust power in your motors (using the setPower function) to stabilize the ship tilting. And of course, you will also catch the action events from the System DPU to inform your script about the direction in which the player wants to stir the ship. The exact details of how this is done in terms of control and dynamics are beyond the range of this post, but it involves simple Newtonian physics about torques and forces.   This above custom made Control Unit DPU could be seen as a black box, a ?Stabilizer?, with 7 slots (5 engines, 1 gyro and the System DPU). You can move this black box in what we call a Component DPU, so that you can sell/exchange it. Now players possessing your ?Stabilizer? can plug it in their own Control Unit DPU along with their own Elements, and then connect these Elements in the Component slots, with a simple drag and drop interface, or a smart ?autoconfigure? system, making the whole process of scripting a ship very simple for those who don?t want to put their hand on code:     The DPU system goes ways beyond this simple ship stabilization example. Weapon control, whether in FPS direct view on a jet fighter, or in tactical overall view in a battleship, will be handled with DPUs. Scripting a drone can be done with DPUs. Setting the automatic defense mechanism of your castle can be made with DPUs. Factories can be automated with DPUs, etc. It's all about orchestrating Elements and Component DPUs via scripts that react to events and execute LUA code. The user interface is also scriptable to decide what happens when the Control Unit is activated, how Elements can display their status and give access to parameters (we will probably talk about this in another blog post).   Novaquark will be providing several useful "starter" Component DPUs to start with, as well as smart autoconfigure options to handle the most basic cases. You can get a ship to fly without knowing a thing about DPUs. But, if you are interested in this aspect of the game, it will be up to you to build from there and create the most amazing control system and contraptions, win the markets or the wars with them and leave your mark in the Dual Universe history of innovation and engineering!   JC Baillie, Project Lead.
  15. Like
    ttcraft0 got a reaction from The_War_Doctor in A wild ttcraft0 appeared !   
    English version :
     
    Hi ! I'm ttcraft0. I am a french player of Minecraft, Ingress and Pokemon Go!, and I used to play Robocraft.
    I discovered DU thanks to Google Now and I was instantely interested in the project. I loved the number of the possibilities of what we can do (sorry for my not very good English ^^). Hope I see you soon !
     
    Version française :
     
    Bonjour ! Je suis ttcraft0, un joueur français de Minecraft, d'Ingress et de Pokémon Go, et je jouais également à Robocraft.
    J'ai découvert DU grâce à Google Now et j'ai tout de suite été intéressé par le projet. Je ne compte même pas le nombre de toutes les choses que l'on pourrait y faire En espérant vous revoir bientôt !
×
×
  • Create New...