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 16

    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 18

    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?).

Sign In or Register to comment.