Welcome to Keen Software House Forums! Log in or Sign up to interact with the KSH community.
  1. You are currently browsing our forum as a guest. Create your own forum account to access all forum functionality.

Programming or eventing? post your opinion here!

Discussion in 'General' started by Fab, Apr 11, 2014.

Thread Status:
This last post in this thread was made more than 31 days old.
  1. Fab Apprentice Engineer

    Messages:
    379
    [​IMG]

    Since devs announced wireless and "programming", we should decide how we "program" the bots/machinery etc. (the computer above is how I expect the look of program/computer block)

    Eventing looks like this:

    much simpler than programming.

    [​IMG]

    Examples of inputs in Space Engineers would be like "mining drone" "Assembler 1" "Thruster 1 (up)" "Thruster 2 (forward)" etc. I think its more self-explanatory. Ask me questions if you dont understand something.

    # Programming needs more skill and time:

    [​IMG]

    Pick the one you like the most.
     
  2. lhiles Trainee Engineer

    Messages:
    31
    Eventing.

    While it puts a heavier burden on the developer to create a designer interface, the simplicity it presents to the user will more than make for it. If more complex logic is needed than can be provided by the event workflow system that moves into the realm of a mod.
     
  3. Hatchie Apprentice Engineer

    Messages:
    194
    I would like to see object based programming where you can call every mechanism on the ship and order them to do stuff like this:

    RocketLauncher1.fire()
    SmallThruster3.burst(1000;60)
    Rotor2.rotate(2,5;30;2000)
     
  4. pipakin Apprentice Engineer

    Messages:
    182
    Programming. "Eventing" would take more time to implement, have less power, and run slower since it has to be interpreted at run time.

    Also: your poll is pretty close to a yes/no, which aren't allowed.
     
  5. Helmic Trainee Engineer

    Messages:
    41
    Both. As we've discussed on the Steam forums, a lot of us would like the simplicity and versatility that a language like Lua would provide, but we also want the general functionality to be available to everyone, which you can only really do with a Game Maker-like interface.

    Both will let you do just about anything, and you can even mix the two as needed - a player who's making a complicated machine might do most of the work through eventing but may include a few custom-made events written in Lua. Those events could even be distributed in the Workshop for other players to use.

    But if for whatever reason Keen insists that there only be one method for doing things, eventing for sure. While being able to type up anything you want in Lua is cool as hell, you can still accomplish 95% of that through eventing without the learning curve and potential for game crashing bugs.
     
  6. Scorpion00021 Senior Engineer

    Messages:
    1,411
    +1

    object oriented programming would be great.


    foreach (ship.turret turret in TurretList1){
    if ((distanceBetween(turret, target) >= 1000) && (turret.getAmmo >= 1)){
    turret.updatePosition(turret, target);
    turret.fire();
    }else if(turret.getAmmo < 1 && ship.container.contents.contains(turret.ammoType)){
    container.moveContents(turret.ammoType, turret, 1);
    }
    }
     
  7. spacedMatt Apprentice Engineer

    Messages:
    421
    I would like to use methods like...

    RocketPod1.fire();

    and

    GravityGenerator1.fieldHeight(64);

    in simplified programs like....

    FunctionName{
    while(true){
    EqupmentName.methodProvided();

    if(Sensor.detectsSomething)
    Break;

    }
    }

    But I also think there should be an interface for noobs, with the same methods but in button and slider form , with simple programming operations like loops , if statements and such but in drag and drop button form too.
     
  8. Scorpion00021 Senior Engineer

    Messages:
    1,411
    I'm actually kinda split on the issue. While programming and robust computer assistance would certainly be available in the future, I feel like it would take a lot from that element of teamwork. I would like to see ships with 5 players on the bridge working together in a battle, but with programming, none of that would be very likely. Everything could be automated and set to hotkeys and the pilot would be able to manage a supercruiser all by himself.
     
  9. Meri Trainee Engineer

    Messages:
    34
    Programming. Eventing requires just a little bit less brain power but anyone who can 'press a node to start an action' can just as well 'type a command to start an action'.
    Basic scripts wouldnt require much knowledge and should be good enough for everyone, of course simple logic and some loops should be added as well.
     
  10. pipakin Apprentice Engineer

    Messages:
    182
    Plus, keen was planning on programming anyways (from the Q&A transcript thread):

     
  11. tutkarz Apprentice Engineer

    Messages:
    140
    I would start with c# and later decide if something else is needed, especially that this part could be modded rather easy.
     
  12. Lyrus Apprentice Engineer

    Messages:
    112
    I prefer programming: a script is an algorythm that can be construct with an human language then it could be translated. For the same time of learning I believe you can do much things with a script than in eventing.

    More over, enventing require a visual interface that is heavier to produce.
     
  13. Helmic Trainee Engineer

    Messages:
    41
    You're forgetting something very important here. No one without prior experience is going to know what the syntax is.

    With eventing, you've got a list to draw from, you find what you want on the list and you plop it down. Knowing what you can do is just a matter of looking at the available functions.

    With programming, you have to understand what programming even is. How is the user supposed to know any of the syntax for Lua or C# (seriously use Lua it's pretty much made for exactly this sort of situation) or the game-specific functions without reading a lengthy tutorial? How are they supposed to understand how to make an if statement if no one's ever told them before? "COMPUTER IF THIS HAPPENS DO THIS WHY ARE YOU NOT DOING WHAT I'M TELLING YOU"

    It's really easy to take for granted what we've already learned, but it's just that, learned. We already have programming experience so it's second nature to us, typing out a script is just as easy as using a drag and drop interface. For someone that lacks those skills, though, it's completely impenetrable. This is something that takes an entire elective semester of high school to learn, or maybe even a college class - even those will often start the class out with eventing or something super high-level. It's not immediately accessible to most people.

    I still advocate for allowing both. Proper scripting support is piss easy to add if you add eventing, and the ability to create custom events allows players to use player-made libraries from the workshop. Players who are mildly curious about programming can also ease into it and just do a little bit of their project in Lua and do the complicated stuff with eventing.

    I think the poll should be removed. It's focusing the discussion on which is better rather than how it should be implemented, it creates a false dilemma.
     
  14. Forgemasterhd Junior Engineer

    Messages:
    612
    I, for one, would love to learn C#, but then again, I'm doing abit of work with basic HTML with some experience in VB.

    At least I have some idea of what I'm getting into.
     
  15. d3x0r Apprentice Engineer

    Messages:
    111
    There's a game called bugbrain where you use a neuron layout board to design the brain of a bug...

    Basically, a neural net boils down to inputs of varying levels (-1.0-1.0 for instance), neurons to do threshold comparisons, and outputs which are just processed varying levels.... but given inputs (radar, or light/shadow detector) then you can cause ships to move or not... they (inputs/outputs) can also be digital levels ( a certain level of input is a digital ON) state...

    http://www.biologic.com.au/bugbrain/ (good intro/tutorial)
    [​IMG]
    I was working on a document to describe this in more detail and how it has been implemented

    https://docs.google.com/document/d/15XJuZfsdGnF_vhap8822xSAR9_DS8GbH8Jr9XdFhTEc/edit#heading=h.n6lwwmkgeuvp (lots of disogranized thoughts, some screenshots of current implementations, I use the current neuron levels to dynamically color the components so you can see what is on or off at a glance)

    I implemented a neuron engine here... (couple hundred lines)

    https://sourceforge.net/p/xperdex/mercurial/ci/default/tree/games/automaton/xperdex.brain.net/Brain.cs

    But that's not the issue; the issue is the layout and design (editing tools) ...

    I like your hotswap toolbar idea, maybe that would work instead of what I have done (relies on right click popups to add new components).

    I added a output that triggered a script component in my other script based environment... outputs can be digital

    ----
    Other classic programming games - C-robots (really now depricated) Omega was a more drag and drop visual programming language of tanks (DOS, depricated), don't really know of any current programming simulator games. ALICE ( http://www.alice.org/index.php ) Is a drag and drop visual programming language...
    [​IMG]

    also Microsoft realeased Visual Programming Language ( http://msdn.microsoft.com/en-us/library/bb483088.aspx )[​IMG]
     
  16. d3x0r Apprentice Engineer

    Messages:
    111
    But firing a rocket isn't an issue....
    although having a gui designer for cockpit controls (open hanger door, close door... )

    feedback from motors to enable other motors ...

    but, knowing where things are... 'I want to get platinum' okay, it's 50M that way... but... there's a coridore already that's nearer... so maybe pathing nodes to things?

    also how does it add that there's a new thing there? I guess being part of the engine it could cheat and just 'know' the map..

    Or how to give it an objective point 'attack targeted ship'

    ---
    Improving the resolution of current sliders would be nice... if instead of a linear scale it was simply like 4 sections ... so the left is scaled range from min to the quarter point, then quarter to half to the next quarter are pixel-perfect for 1.0 change... but when releasing you'd have to move where the middle quarters are (maybe a smaller range like 1/10th of the total is pixel perfect until a range outside of that)
     
  17. Morbophobie Apprentice Engineer

    Messages:
    145
    I also think a mix of both would be good another example is scratch

    http://scratch.mit.edu/projects/editor/?tip_bar=getStarted

    You can test it free. It is self explaining but still a programming language.

    Of course for space engineers it would have to be different but a visual language in some way would be nice.
     
  18. plaYer2k Master Engineer

    Messages:
    3,160
    I find that question rather odd, as if event-based/driven programming wouldnt be programming. The example given, which is called "eventing" (a word i never heard in my studies, maybe because iam no english native so please enlighten me), seems to just be a very limited example for a GUI to configure some event responses. So it is nothing but a front-end application to make it easier for people without the required skills to programm many things theirself, nothing they should be ashamed of.

    So if that case is true, then the answer is clearly "programming" as it would allow others, given we have enough freedom to do so, to program tools that act exactly as such a GUI front-end for others using even community based events, event-responses etc to extend the games content. In addition we coulnt be limited to such a GUI only.

    So like i previously said many times, given we get enough freedom to program our own interfaces (windows, buttons, button events) there will be people making tools for others to use and ease their daily work. Most of us have never made their own OS, text editor, 3D game or even graphical calculator and yet we use them on a daily basis. Tools are made from a minority, the majority is using them.
     
  19. Donut64 Trainee Engineer

    Messages:
    91
    If they could manage to arrange "eventing" well enough, I'd rather have that.

    However, the word you are looking for instead of "programming" is "scripting". "Scripting" is the same as "Eventing".
    What I feel you are asking for more than anything is a GUI to lay out the scripting for you, which takes a lot of effort to make.
     
  20. plaYer2k Master Engineer

    Messages:
    3,160
    My definition of "script languages" usually was that they are meant for "small scale programming", a minimalistic language to allow coding, loop and event based can happen there. So his "eventing" doesnt equal "scripting" for me. May we have different definitions there? :)

    Good examples for popular script languages are (non exhaustive ofc):
    - AutoIt
    - LUA
    - Python
    - PHP
    (some more)
     
  21. thestalkinghead Trainee Engineer

    Messages:
    29
    i think both "basic" and "expert" modes which would be selectable in the ui would be good, so if you wanted to do something simple you could just use buttons and dropdown menus in the ui with basic mode, but if you wanted to programme something complicated you could use expert mode.
     
  22. Pathfinder Trainee Engineer

    Messages:
    65
    Programming. Simply because, it's an engineering game, and also, programming would allow much more freedom, in my opinion.
     
  23. Ranakastrasz Trainee Engineer

    Messages:
    54
    Both with Programming coming first.

    It is likely simpler to set up, and more flexible. Add Gui later for less advanced players, since that would take more effort.
     
  24. Vermillion Senior Engineer

    Messages:
    2,131
    Programming.
    I just hope that players can't copy/paste coding from pastebin. That's what ruined computercraft.
    Untrained idiots could simply find a program they wanted and paste it into the game and completely remove any need to write the programs. Most people CC users don't even know how to write a Turtle program beyond "Excavate 20" and "turtle.attack()".

    Of course saving programs in-game and transferring them to an in-game Disk, or the Engineer's Suit Computer and reusing them in the same world, that's a different thing entirely.
     
  25. plaYer2k Master Engineer

    Messages:
    3,160
    I highly disagree with that. I dont know computercraft or minecraft much yet there should be an option to read a text file or copy and paste directly into the game from the clipboard. Anything else is a bad artificial barrier. I want to make backups or multiple versions of my programs aswell as i want to share them.

    Also like already said, not everyone can code and not everyone has to. However everyone shall be able to benefit from others who made programs and willingly share them.
     
  26. RayvenQ Moderator

    Messages:
    562
    I'm one person who just suffers with languages, they just don't click with me at all, no matter how hard I try to understand them. So if it was just programming alone, I wouldn't even touch those features because I'd not use them whatsoever. I'd say have both though, an eventing mode for those who can't or don't want to learn a scripting language , and a programming mode for those who know what they are doing.

    Although something akin to ALICE (whether drag and drop or just lists of the variables etc) but ingame would be a good thing imo, that sort of language, from my point of view is logical, simple and easy enough to understand, and it would be for those who also don't know scripting. but in either case, having the syntax and variables free to look at in game in some sort of list (possibly with an explanation)is extremely important. Or do it like ArmA 3 does, when you start typing, above where you type it shows the syntax and variables depending on the letters you type in. So if i typed in mo, mov, move it shows all the commands starting with those letters
     
  27. Shiliski Apprentice Engineer

    Messages:
    290
    Personally I'm all in favor of a programming-based system like LUA or even a simple scripting language.

    Eventing isn't that much different to me. There isn't just programming and not-programming languages. There are only languages that take you further and further away from direct control over the machine, and languages that are more efficient, flexible, and powerful than others.

    What I would suggest, from a game-design perspective, is to do what Blizzard does with their map editors: Have an LUA-based system underneath the hood, but let people do stuff via a trigger system that is very accessible, quick to use, and easy to understand. It's okay to just use something that already works, and the trigger system works.

    At the very least, whatever they do, I hope they have these things:
    Sequence (As in running lines of code one after another)
    Selection (If/then/else, else-if, switch statements, something like that)
    Repetition (Loops. You absolutely must have loops.)
    Variables (We need some way to store data.)
    Inputs/outputs (All this code needs to mean something, which means it has to interact with the game in some way.)
    Modularity (Not strictly necessary but it's great for code-reuse and makes things 9001x better)

    As long as the given language has all of the above, I'm perfectly fine with it and I'll be able to do pretty much everything I want with it.
     
  28. d3x0r Apprentice Engineer

    Messages:
    111
    Re: eventing: see ladder logic
     
  29. d3x0r Apprentice Engineer

    Messages:
    111
    I guess another solution is what second life did ... which is a c# sort of language ... LSL linden scripting language

    I really think we should be able to evolve to a higher capability than coding, whether the syntax is lua or lisp or the library is java or C... doesn't matter... it's all scripting...

    Ladder logic; design for PLA (programmable logic arrays) ...

    Use http://en.wikipedia.org/wiki/Self-replicating_machine
    download: http://www.srm.org.uk/introduction2.html

    (No :) it's much too much overhead for what little function it does :) )

    I'd like to see pluggable modules like all the other components in the games... assemblers /refiners can already have inputs/outputs... just have to have different properties in the middle....
     
  30. Helmic Trainee Engineer

    Messages:
    41
    Again, the poll is forcing an either/or situation when it's increasingly apparent we want both.

    First, we need to remember what this scripting is for. It's controlling in-game stuff, like motors, engines, all that stuff. It's something you'd do while playing the game, so it needs an in-game UI so you can write the script while in-game.

    For the "eventing" (thank God other people thought that was weird too), a simple interface like in the OP would work just fine. A list on right with your normal if statements and loops (all in plain English so non-programming folk can immediately know what it does) and on the left the stuff they can manipulate (cargo crates, assemblers, motors, lights...). A completely uninitiated user should be able to easily set up a button to do a simple task like remotely open a door WITHOUT looking anything up online.

    As for people worrying about the UI being "too hard" to implement: they're making a goddamn physics sandbox with fully destructible voxel-based environments. I think Keen can handle coding a 2D UI.
     
Thread Status:
This last post in this thread was made more than 31 days old.