Untitled 2D Bridge Game.io

Time for my brainstorm/word vomit idea dump!

I'm wanting to get familiar with the Godot engine, so I am going to try my hand at a bit of genera mashing with bridge simulation, io games, and blockbased ship building games. This is very much a departure from the games discussed here, if the forums are for more serious and bridge-sim (I would call this idea a crew-sim) games just let me know :)

My 10 year old son and his friends don't have a lot of overlapping options for playing in this social distance time. Different consoles, some only have their smart phones or tablets to play on. They are limited to web games or Fortnight. So I started putting together something that they can play together in a cooperative way, but still have that quick and easy fun competitive component too.

So a quick list of objectives and goals:

  • As an IO family game it needs to be super simple to play and hop in and out of a game
  • Crew design should be super flexible, crewing a ship with one player should be just as viable as 6
  • Everything should still be playable and fun on a phone screen
  • Game is 2D. Ships are made of tiles to create rooms. Think FTL.
  • Newtonian physics.
  • Quick initial progression with ln growth

One departure from the bridge sim genera is that the players are represented as an avatar on the ship. They can move around the ship, man different controls to play the different stations. This does allow the possibility of putting some gameplay elements in interacting with the ship by the avatar, instead of a bridge station console (Engineering being the big one). It also means that in non-combat situations the crew members can still participate in other roles for running the ship. Weapons can switch to comms for example (both are a form of communication after all!).

Similar to agar.io, ship can pick up meteors to repair/upgrade/expand. Combat can leave scrap which is used for the same purpose.

Because of this I am framing the game in terms of tasks, instead of specific bridge stations. Many would be mapped to a bridge station.

  • Captain Chairs: If other stations are not manned, it lets one player control most of the basic ship functions for pilot and combat. This is your standard 2d space shooting game. The camera is zoomed out as most of the gameplay is outside the ship
  • Pilot (same as above). Not quite sure on what control scheme to use yet.
  • Weapons -- Basic gameplay are turrets follow the cursor and shoot on tap/click. Individual turrets can be manned and manually controlled.
  • Power management. This one I am thinking could be done in the ship by laying, and pulling up, extension cords strewn about the ship.
  • Repairs. There is slow auto repair using the ore collected from scrap and meteors. Players can also run around and accelerate repairs. This is a bit wack-a-mole which can get tedious, so I'll need to think more on how to make this more fun.

The rest I am thinking to include somehow but I haven't spent time thinking about implementation yet. There is potention for a longer multi-session game loop:

  • Scanning, comms, mine, expansion/construction, transporter/away teams, medical, environment controls, shields.

For the visual art style I am leaning to a vector Tron inspired neon, but is is also an overdone athetic. My art skills are limited so doing some basic vector shapes and colorize it to communicate information to the player, instead of number readouts.

For audio I am thinking making things musical. The universe has an underlying tempo. Different abilities and weapons add different instrumentation and and rhythm. You know your ship is getting damaged visually AND it sounds off. SimCity 5 did REALLY well in this department. If I go with faction or team gameplay, each group can be given a different musical style.

I have not dived into particular network protocol or structure yet other than a standar client/server over websockets.

Comments

  • I love it!

    I think this still fits easily under the category of Bridge Sim, although not as centered. Crew Simulator is a pretty good more general genera name.

    I like the general style vibe you have given. And I love the idea of Newtonian Physics, I have found that they are not really complicated, just not familiar. ...orbital mechanics is another story...

    Careful with having the players an avatar, and not controlling a station themself. It can definitely be cool, but it is a quite different thing, and has subtle effects that change the nature, when compared with a typical bridge sim, that are not expected. I think it can be a great idea, but if you want it to feel like Artemis or EE, then it won't. Have you every played Pulsar: Lost Colony?

    "Ships are made of tiles to create rooms." I have to snicker... as that is the plan for Sigma Tau, not tiles, probably a more fluid triangular mesh. It is not really a primary concept of Sigma Tau, but fits nicely under a couple of others. I am hoping it will work for Sigma Tau, but it is for the future as it is secondary, not primary. Needless to say...I love the idea!

    How do you expect to handle a single player with separate "seats" for Pilot and Weapons, and other objectives?

  • Sounds quite a bit like "lovers in a dangaours space time".

    Also sounds like fun.

    And, sounds pretty large and complex. Don't overscope and start small and simple.

  • [quote]Careful with having the players an avatar, and not controlling a station themself. It can definitely be cool, but it is a quite different thing, and has subtle effects that change the nature, when compared with a typical bridge sim, that are not expected. I think it can be a great idea, but if you want it to feel like Artemis or EE, then it won't. Have you every played Pulsar: Lost Colony?[/quote]

    It is a departure from EE and Artemis conventions! I have played pulsar with my brother, as well as space engineers. I've done the tutorials of Stationeers and dinked around with Station 13.

    [quote]Sounds quite a bit like "lovers in a dangaours space time".[/quote]

    I had so much fun with that game. It stressed my husband out.

    [quote]"Ships are made of tiles to create rooms." I have to snicker... as that is the plan for Sigma Tau, not tiles, probably a more fluid triangular mesh. It is not really a primary concept of Sigma Tau, but fits nicely under a couple of others. I am hoping it will work for Sigma Tau, but it is for the future as it is secondary, not primary. Needless to say...I love the idea![/quote]

    Godot has a tilemesh https://docs.godotengine.org/en/stable/tutorials/2d/using_tilemaps.html feature for its 2d games. It keeps the opportunity open for some more advanced features down the road -- and where things are placed will determine how the ship flys and fights. I'm now trying to figure out if I should implement ship components in the tilemap system or as regular nodes snapped to the tile grid, but that is engine implementation.

    [quote]How do you expect to handle a single player with separate "seats" for Pilot and Weapons, and other objectives?[/quote]

    The captain chair will be able to do both if those stations are empty.

    [quote]And, sounds pretty large and complex. Don't overscope and start small and simple.[/quote]

    Oh I know. I'm trying to design this so the bare bone mechanics are fun and simple, but allow me to iterate in more advanced and detailed mechanics later. The games had success while in Early Access were always successful fun games in every stage of its development.

  • edited June 2020

    I have learned a few things!

    I have been pronouncing godot wrong in my head for years (Gah-doh in correct, instead of go! dot! which is how my head does it)

    I need a better way to organize my web research as I have a bazillion open tabs everywhere.

    Something I already knew is that networking is hard.

    Because I am going to deploy to HTML5 I'm limited to using WebSockets and/or WebRTC for networking. WebRTC is UDP so more performant for a faster paced game, however it was only standardized three years ago so there isn't as much documentation yet for rookies like me. The interesting thing about webrtc is it still requires a websocket based signal server for the initial handshaking. WebRTC is peer-to-peer based. Even with an authoritative server model the netcode treats everything as a client.

    Godot using a message system for the observer model. Unfortunately the websocketclient and websocket server class both emit the same "data_received" message, so I can not have the signal server in the same process as the game server (which is an authoritative client).

    I have one more rtc tutorial video to watch to see if there is a work around, but it seems like I need a separate signal server. At this point I am looking at Nakama https://heroiclabs.com/docs/index.html

    It has an impressive feature set that will take care of some of the nuts and bolts of user management, integration with Godot, and also opens up the possibility of some future fluff features (unlocked cosmetics, etc).

    EDIT: I'm now wondering if webrtc is a bit overwkill and should just use websockets. Websockets are TCP and I am worried that cell data isn't exactly low latency. I don't need peer to peer. Ships are relatively large targets -- and I intend for them to fly more capital ship style instead of a twitchy fighter. I am looking for somewhat quick gameplay, but not twitch based. Eve-online's simulation runs at 1 tick a second yet it feels responsive due to client graphical and ui/ux smoke and mirrors.

  • Right, if you have a velocity, you can extrapolate a very good estimated position, even with high latency.

    What kind of network are you expecting to run over? TCP is really only slow because packet loss. It's primary problem is that when a packet is dropped there is a huge latency spike, to wait for a duplicate. Sigma Tau uses WebSockets, and part of the reason it works is because the web-client is expected to be over a local area network which does not have meaningful package loss, and if a packet is lost, latency is so low that waiting for a duplicate is not a problem.

    "Eve-online's simulation runs at 1 tick a second". Hum, that is cool to know. I have been thinking of making a super long physics tick for Sigma Tau, I haven't experimented if it would be feasible, I guess Eve-online has already proved it to be so.

  • Eve online goes further in that ships have no rotation, only velocity and a sphere radius. This may have changed in the last decade, but eve online was designed for 56k modems. The client then renders a ship's orientation based on its velocity.

    My goal is to be playable over a cell network.

  • edited June 2020

    I switched to websockets, which is a very standard client-server paradigm. In just a day I got far enough to spawn ships and avatars with physics. However I set the ship mass too low and was able to propel my ships by running into walls....

  • lol, technically your avatar should propel the ship in the opposite direction of its motion when it moves, and then perfectly cancel out when it hits a wall. But simplifying it so that the avatar has no effect on the motion of the ship would be better. Making the mass of the aviator to the ship large enough to mitigate the problem would also work, although, less ideal (should the mass of the avatar just be zero?).

  • Oh dear lord I'm a slow programmer!

    For networking I am using a library that is delta-snapshot based. Took me some time to get back to a crewmember walking around on the ship.

    I'm now starting work on piloting. Input events are sent to the server, which will then do the appropriate calculations. I plan on simulating individual engines and thrusters and will need to find or write code that will activate the appropriate engines for the requested maneuver.

    Thinking about the needed variables for an engine component lead me to outlining how the sensor station will work. I want sound ot be a component of the game, but for accessibility I need to make sure there is visual feedback as well.

    Inspired by the Expanse passive sensors will be based on the EM spectrum, which which be modeled categorically instead of on a spectrum - Radio, Micro, IR, Visible, UV, X, and Gamma rays. This is also a standard seven note scale (what key do I want the game to be in! Major? Minor?) so each range will be assigned a note. Each ship module, the ship itself, in game objects, and environmental events will emit differently across the spectrum at different intensities. A ship running with engines at full will have sustained IR and visual emissions, while a tactical nuke will have a momentary blip on the whole thing.

    The sensor station will view these passive events as a ring around a ship. Emissions are visualized as a specific color for the type of EM, and by intensity as an equalizer-like waveform (like EE sensor screen). Tones will also play as well. Sensors can also be isolated by type and sensor direction can be limited too. Distance is not known, the intensity that shows up on the sensor screen/speaker will be dependent on the intensity of the event and the inverse square law.

    I am debating on including active sensors, which will light up your ship in the radio spectrum. This will be visualized as the traditional radar screen. I want to encourage the passive sensor mechanic. Other than increasing the visibility of your ship, emission of the radar is infinite, but it only resolves distances at certain ranges. If I simulate power and heat as serious limiting factors, then running radar would be a resource drain.

  • O.o, that sounds like it could be totally cool, hopefully it works as well as it sounds /:

    You could actually fit an 8th tone if you wanted, and just be Do (1, the dominate (C in the key of C)) an octave higher. Maybe make the two Dos related in some way. I would also make the notes not in the pentatonic scale be less common (as they will sound more tense), or used strategicly; and make the Do and So (5, subdominant) (and maybe Me (3)) more common, as they sound sonorous. Pentatonic can work in Major or Minor.

    I have no idea how much music theory you know, I just have two brothers who are college majors in music, and it rubs off.

    Keep sharing your progress, I read your posts, even if I don't have a response.

  • Its been a while but I know a fair bit. Its been done with the orbit of planets https://www.youtube.com/watch?v=WS5UxLHbUKc and can get a little chaotic. https://www.youtube.com/watch?v=UGnuDE7sINI&feature=emb_logo


    I spent some time in my old physics textbook figuring out how to convert player input to thruster fires (force). My long-term objective is damageable components and even player built ships, so I need a generalizable solution. In short, how does Kerbal Space Program do it? I would love to see code for this, but haven't found any available. So I will just need to do it myself.

    Godot 3.2 2d physics engine has some constraints. It is getting improvements and a rewrite in 4.1, but that is a year down the road. Currently I have to manually place the center of mass, but I am able to apply positional forces.

    There are two basic forms of motion - liner and rotational. When the player uses one generally the other is to be minimized. Yet a player may be applying both at the same time as well.

    One of Star Citizen's developer posted on reddit that they cache the potential forces and torque that the thrusters apply, then refresh the cache when the thruster output changes from damage or power boosting.

    Each thruster has a displacement vector from the center of mass (r). A thruster applies a force vector in the push direction (F). The force vector has an angle from the displacement vector θ. Torque, at least on a fixed axis of rotation (I assume this will be the fixed center of mass), is T = r * F sin θ.

    The thruster cache needs to know which thrusters apply force for each cardinal direction, and also know what set of thrusters will result in clockwise and counter clockwise torque.

    Here is where implementation is getting a little fuzzy for me.

    When the player inputs liner movement the thrusters for that direction are brought up. They are subgrouped by clockwise or counterclockwise torque. If torques sum up to 0 then they will apply their forces. If torque is unbalanced then there are two options. The low fuel option is to reduce thrust on the unbalanced side (solve for F). The high fuel option is to search for additional thrusters that can apply a balancing force without counteracting the liner velocity. If no solution can be found then the ship will have unbalanced flight.

    Rotation would be a similar process, but the lookups would be the direction of torque, subgroups would be force direction.

    The part I am REALLY wondering about is when players apply multiple inputs (ex, thrust forward, lateral left, rotate right). What is the algorithm that identifies the front left thruster needs to reduce or turn off for this maneuver.

  • Hum,

    Calculating the effect of a burning thruster is done with a basic offset force (most physics engines should have this).

    You will probably want the functions labeled "force", not "impulse", as the unit of the force is over time, but here is my implementation for impulse

    void applyImpulseCentered(Entity entity, Vec2 impulse) {
       entity.vel += (impulse / entity.mass).rotate(entity.ori);
    }
    void applyImpulseAngular(Entity entity, float impulse) {
       entity.anv += impulse / entity.inertia;
    }
    
    void applyImpulse(Entity entity, Vec2 impulse, Vec2 pos) {//pos relative to center of mass
       entity.applyImpulseCentered(impulse);
       entity.applyImpulseAngular(cross2d(pos, impulse));
    }
    

    Is that one thing you were asking?


    Caching the effect of the combined thrusters, and only recalculating when a thruster changes, makes sense. For Sigma Tau, I actually plan on storing the total forces from the thrusters (linear and angular separately), and then just add/subtract when a thruster changes; I would not recommend this unless you know what you are doing and are convinced it is worth it, you are opening up a can of possible bugs when doing so. (If you want, I can elaborate on my thoughts)


    As for calculating how thrusters should fire in response to user input. I have not coded that yet for Sigma Tau, but that is absolutely my intention (the user will be able to either control thrusters individually or with the stated abstraction). I currently just have a debug thruster which applies basic thrust and torque. I was planning on coding it down the road and focus on more important gameplay mechanics, but I will do it sooner rather than later, so that I can share my learnings/code.

  •  I actually plan on storing the total forces from the thrusters (linear and angular separately), and then just add/subtract when a thruster changes

    Floating point rounding errors will accumulate and cause phantom forces...

  • edited July 2020

    Yup, that and forgetting to apply an adjustment will remain as a never ending force.

Sign In or Register to comment.