EmptyEpsilon2

edited June 16 in EmptyEpsilon
So, I started working on something. I've decided the park my "large planet rendering" code for a while, seeing the amount of bugs I was having with it. Maybe I'll revisit it later, maybe I'll do something else.

Anyhow. EmptyEpsilon2, what it will have for 100% sure is full 3D motion. So I started working on the helms controls.
image
Right now I have manual and CPU controlled motion. The CPU controlled motion is simply a planned action that your ship will execute. While manual controls are direct buttons for rotation/trust. The direct actions are also hooked to keyboard keys right now.

It's all very prototype state. And the CPU based rotation action took me a full evening to get working. The UI is fully defined by data files, so no longer messing with lots of code to change a bit of UI. This means that station screens will be fully customizable at some point.

Ironing out bugs in the GUI system from SeriousProton2 and the 3D collision/physics engine hooks, is another time sync. Most likely fill find a ton of bugs in the multiplayer code as well, as that is never tested.

The fusion engine UI is just a placeholder, not linked to any code. Just UI elements that do nothing.
3D models are from https://www.kenney.nl/assets/space-kit and I consider placeholders at the moment.
«13

Comments

  • I think "Trust" should be "Thrust"
  • Really excited about the "full 3D motion" bit! Good luck with EE2. Will you have a separate site for this project, or share the EE1 site with this one? I'd be interested in donating at some point for EE2 development. Could possibly also contribute planet and spaceship models, and space skyboxes.
  • I think "Trust" should be "Thrust"
    Oops. Dyslectic as fock. :-)
    Really excited about the "full 3D motion" bit! Good luck with EE2. Will you have a separate site for this project, or share the EE1 site with this one? I'd be interested in donating at some point for EE2 development. Could possibly also contribute planet and spaceship models, and space skyboxes.
    Once I get to a playable state, I'll make a seperate site I guess. For for discussions/forums, I'll just keep using this forum. So this will be the only location for information for the upcomming while. As right now, it's really in early prototype phase.
    I just want to involve you guys as soon as possible.


    Right now, I had a day off. So I could do a bunch of things:
    Updated the text fields to allow selection of text
    This is one of those things that you really miss if it's not there. The text fields are 100x better then in EE1. I already had a cursor that you could move with clicking and the keyboard. But selecting all for quick entry just makes it so much better.
    It's one of those things that sounds easy, but took me an hour to get right. With all the pre-conditions in place.

    EE1 made very little use of text fields because of their general bad behaviour and that they didn't work at all for our touchscreen setup.

    Planning screen
    As outlined here: http://bridgesim.net/discussion/comment/3768/#Comment_3768
    I want to make a "planning" station. The difficult part there is the map.
    Made some good steps in 2 things, line rendering and rendering cutoff:
    https://imgur.com/13zaU46
    These are a bunch of lines, which are rendered as axis aligned billboards. Just see fancy lines, and know that there is a bit of math behind those.
    I also cut them off rendering nothing outside of a sphere in the center. So they are actually square areas of lines, but rendering only render the pixels in the center sphere.
    The effect is more obvious when you move trough the space instead of only rotating.

    BUGS
    As this is the first major thing I'm doing in full 3D with the SeriousProton2 engine, I'm encountering quite a few bugs. For example, just spend quite a large chunk of time because the mouse clicks on the 3D scene where not translated to 3D positions properly. This worked fine for 2D scenes, but as always, in 3D everything is 3x as complex.

    Other things
    There are a lot of things that I'm now prepared for that EE1 really has issues with. Just a bunch of things that are really difficult for EE1, and EE2 with SeriousProton2 engine are prepared for.
    * Multi-touch support (for hardware that has this, including Windows)
    * Multi monitor setups, running the main screen on 1 monitor while running a station on a 2nd requires 2 instances of EE1. With EE2 this can be done from a single instance at some point.
    * Fully customizable stations. Don't like which buttons are where? This will be fully data-driven.
    * Scripted sequences. In EE1, if you want to have a mission where X happen, wait for Y, then Z happen, then this required a complex sequence of setting up functions and checks. With SeriousProton2 I have a few much more powerful script functions that allow you to "pause" a script and resume it later. Allowing for easier and cleaner mission scripts.
    * Better keybinding system, supports multiple keys to a single bind, as well as joysticks/gamepads/mouse buttons.
  • Well, a percentage-based trust-system would also be interesting :-)
    Promising feature list, looking forward to it. Would EE2 support unicode?
  • edited June 19

    Promising feature list, looking forward to it. Would EE2 support unicode?
    Good point, let me see. Nope, not yet, let's fix that as well...

    Ok, for displaying static text, it was quite easy just some utf-8 decoding. For text entry I need a bit more work. But all in all, yes, EE2 will support unicode with utf-8 decoding.


    I haven't decided yet if I want translation support or not...
  • Ok, still trackling the "planning" radar view:
    image
    There is a lot going on in this image, and it's most likely confusing as hell right now.

    The lines are drawn in 3D space as before. Behind everything you see a navigation "sphere" which is aligned with the ship, so the 0 degree N is forwards (I've stolen the image)
    There is a semi-transparent plane seperating the top and bottom halves giving you the 2D plane of the ship if you would only change yaw.

    Lines have a shadow towards this transparent plane. Or at least, that's the plan.
    Maybe this 2nd image shows it a bit better:
    image


    I will be spending quite some time on getting this right, slowly getting somewhere I think. But there is still a lot of work to be done on just the viewing part.
  • I haven't decided yet if I want translation support or not...
    Yeah, I know you are not a big fan of translations. but at least utf8 would be a very good basis. So even if you decide against it, it would at least be much easier to do unofficial translation-mods/forks than it is now for EE1.

    That planning picture looks cool, but as you said, also pretty confusing. But it might be a thing of getting used to it. It reminds me of the nav screen in SNIS (although the sphere is more subtle there and the alignement is different):
    https://smcameron.github.io/space-nerds-in-space/#navcontrols

    If you haven't already, SNIS's science screen is worth a look as well for regarding inspiration.
  • The screenshot is also confusing because of the textures that have too much things on them, and the randomness of the lines (after all, they are really random lines)

    The SNIS radar is a bit of the look I'm going for. A screenshot for these kinds of information carriers doesn't work very well, as you grasp a lot more information in motion.

    SNIS could use more colors to differ between different things. And the planet wireframe model does make it messy. It could do with a whole lot less lines.



    Now, why am I drawing lines, and not objects/points? I will add "icons" later on for that. With lines towards the center plane, just as SNIS has.
    I need lines for the planning part. Certain types of scanning equipment will tell you something is in a about a certain direction, but not how far. So if you scan from different locations and draw lines from those scans, your target is at the intersection.
  • SNIS could use more colors to differ between different things. And the planet wireframe model does make it messy. It could do with a whole lot less lines.
    Thanks for the feedback on the colors. Duly noted. As for the planet mesh on the nav screen, it's better than it used to be since it uses a "uv sphere" instead of the old icosphere now. There are 5 camera positions for Nav, and I think that particular image has the camera at the farthest position, so the planet is at its smallest on-screen size and the mesh is at its densest. When you switch between camera positions, it gradually interpolates between them, so I need to use the same mesh for all camera positions to make it smoothly transition, and the mesh doesn't look so dense at closer camera positions. I think I'm ok with it as is.
  • Cannot speak for the higher zoom levels, but at this level you might just want to show 4 circles, 1 aligned with the camera, and 3 alined with each of the planet axis.
    Bit like this:
    image
    Same for the rings, only draw the outline.
    (This was some quick&dirty paint action)
  • edited June 24
    (I feel like I'm derailing this thread a bit... sorry). I could do the change to the rings, I think. But to change the planet would, I think, require a new shader to be written, and changes to the renderer. My renderer currently has a kind of global "mode" one of which is more or less "transparent wireframe" being used here, and in which there are not per-model shaders (that is, object materials are ignored, and it uses a wireframe shader for everything) and I think that there is no possible triangle mesh for a sphere which can be rendered in the manner you've drawn by the wireframe shader, and so this kind of radical change for (to me, a minor) cosmetic difference feels not worth it. Better, I think, to spend my time trying to make the game more fun (not that I have a lot of ideas about how to do that, ha). Thanks for the feedback in any case.
  • OMG, I thought you wern't going to a 2nd edition :) So Happy
  • Better, I think, to spend my time trying to make the game more fun (not that I have a lot of ideas about how to do that, ha).
    That's always the difficult part. And fun for person A might not be fun for person B.

    What is generally important is that players make meaningful decisions. This goes pretty much for any game. Take a first person shooter, you generally have the decision to aim for a bit longer or fire now. Shooting sooner gives you advantage if you hit, but wastes ammo or alerts enemies if it doesn't. While waiting a bit longer might cause you to be seen and shot yourself.

    Some games lack this meaningful decision aspect at all. If there is only a single path forwards, no difference between decisions you make. Then you have a story (movie/book) not a game. Some games abuse this, giving you a decision, which has no result at all. (I look at you Bioshock Infinite)

    Generally, you have:
    * Strategy decision, do I plan to do X or Y, do I buy missiles or mines? This is where EE1 goes wrong, there is no decision in restocking weapons. As they are all cheap enough to get them all stocked.
    * Split second decisions, missiles are fired at you, to you raise shields and take the hit, or do you evade, even maybe lowering shields to get more power for the evasion.
    * Timing decisions, when do we do X? Do we drop the mine now, or when the enemies are closer?

    Now, for a bridge sim game. Search for the decisions that influence multiple stations, to people have to talk and decide.
  • * Strategy decision, do I plan to do X or Y, do I buy missiles or mines? This is where EE1 goes wrong, there is no decision in restocking weapons. As they are all cheap enough to get them all stocked.

    One thing Im lucky using this for LARP, since they have to buy stuff to have it on ship.

    PLEASE PLEASE KEEP THE GM MODE :)
  • Naturally there will be a GM mode. At some point. Once I have something that actually does something more then a small experiment.

    Most likely will be a year before I have anything playable, so don't get your hopes up too high. Amount of time&energy I have is much lower then when I was building EE1.
  • On the good new side, I got my engine to work on Android (with a few bugs left) and I managed to bypass all the stupid android build tools now. So I might be able to fix the EE1 android build as well.
    It's still a hacked together script with a few very nasty hacks at the moment. But I think I will be able to make this pretty without much hassle.

    Didn't do much on actual EE2, as I'm using smaller easier games to test the android support.
  • The nice thing in EE1 about the ordnance, is that the price can be programmed and varied in the scripting language making the decision about purchasing weapons more important
  • https://github.com/daid/SeriousProton2/commits/master
    Took a whole bunch of commits. But I have the android build working with the same buildsystem as my normal builds now. With the only "note" that it does not have a proper icon yet.
    But, I can use this build system on Windows and Linux now. Which makes the Android version much faster to test (before I could only build the android version on a slow linux machine)
  • That's great. I know EE1 is off topic here, but what are the chances of getting the Android build running again on EE1?
  • Well, that is sort of on-topic, as I talked about building for Android.
    I have to see, SFML (for EE1) has a bunch more dependencies then SDL2 (which I use for EE2) so building could be a bit more challanging. Also, SDL2 uses java code for a few bits, while SFML is only C++. So there are some differences there.
  • will EE2 be open source?
  • Most likely, I'm not in it for money. And being open-source is I think one of the major success parts of EE1.
  • Spend some time on testing the network code, server->client communcation. Conceptually quite the same as EE1, with a few minor improvements. But as the code was brand new and untested, I had a few bugs to squash.
    So the good news is that the server->client updates now work. So I can update game state from a server to a client.

    The bad part is, the clients cannot send any interactions back yet. I didn't like how that was implemented in EE1, and I haven't got a new implementation working yet.
  • Ok, got the client->server communication working as well.

    For those that know the EE1 code. In EE1 you had to code glue logic for this part, build a packet, give it an ID, send it to the server, there decode it again, and then handle it.

    With SP2, I can now:
    //setup a function for "replication" with: multiplayer.replicate(&Player::testFunction); //And then on the client call the function like: multiplayer.callOnServer(&Player::testFunction, 1, 2.0f);
    All parameter conversion to network data, ID handling, decoding on the server is all handled by magic.
  • Epic!

    Phantel
  • > multiplayer.callOnServer(&Player::testFunction, 1, 2.0f);

    Out of curiousity, does it block until it gets a response, like a synchronous RPC? Or does it just fire off a packet and proceed with no response, or some kind of async response?

    In SNIS, once a session between client and server is established, all messages both ways are fire and forget with no real associated response. The client streams "opcodes" and their operands at the server and vice versa. I tried to make it so the client doesn't hold important state, so I tend not to need any synchronous request/response type sequences in the protocol.
  • It's fire and forget, after all a client shouldn't hold important state and make no assumptions over state. As only the server has absolute truth.
  • edited August 11
    I see, sounds similar to what I'm doing. I guess you are using a variadic function for multiplayer.callOnServer and using the first parameter to know what the remaining parameters should be? Or variadic templates? I do something similar with a printf() like packing/unpacking function, but haven't gone as far as combining the packet building and sending into a single call, but often use two nested calls for a similar effect, e.g.:

    queue_to_server(snis_opcode_pkt("bb", OPCODE_REQUEST_YAW, yaw));

    snis_opcode_pkt returns a marshalled packet with the specified format (two bytes in this case) and checks the format matches what the opcode expects, and queue_to_server() puts the packet into a queue that another thread will forward to the server.
  • classic one-way binding. cool!
  • > Or variadic templates?

    Variadic templates: https://github.com/daid/SeriousProton2/blob/master/include/sp2/multiplayer/replication.h#L139

    It's not so bad compared to the script binding variadic templates, which also need to deal with returning data conversion, and binding to class member functions.
Sign In or Register to comment.