Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1395472 Posts in 67266 Topics- by 60349 Members - Latest Member: Kasmilus

September 25, 2021, 02:07:36 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsSpace Station 13 Inspired Game
Pages: [1]
Print
Author Topic: Space Station 13 Inspired Game  (Read 1651 times)
Gambit
Level 0
*


View Profile
« on: May 26, 2021, 06:33:58 PM »

Hi all!

I'm starting a devlog to help motivate myself to finish this project. I'm heavily inspired by Space Station 13 (SS13) and the systems/mechanics that live in the many codebases that exist (primarily FTL13), and this project serves to take those further. I started the project in grid-sdk and am exploring Unity for 3D workflow.

The project has been slowing down in the past few months, in part due to life, but its also been a bit difficult to find the motivation to keep progressing.

I'm currently looking for a designer to help give the project some direction, hopefully I can find someone here.

Thanks!
Logged
Gambit
Level 0
*


View Profile
« Reply #1 on: May 26, 2021, 06:44:14 PM »

I thought I'd post a brief "history" of the project since early last year. The project started in grid-sdk which was a great start since it was sort of like Source engine, but 2D and grid based (as the name suggested) which I thought would be the perfect platform for a Space Station 13 style game.

SS13 Box Station map I made in Tiled

Implemented doors opening on touch



Added some tools

Added decontruction to walls



Made a 3D airlock in Blender

After all this, I decided to try my hand at Unity3D to test it out and see if it would be a better fit for the game. I started out by recreating a piece of UI from SS13 using the new UIBuilder https://www.youtube.com/watch?v=faQC9SFWZFU

This is pretty much where the project is at now. Most of the time in the past 4-5 months working on the project has been learning how to use Unity instead of actually making the game and I think that's where some of the lack of motivation comes from since I'm not making direct progress.
« Last Edit: May 27, 2021, 08:00:04 AM by Gambit » Logged
Ramos
Level 6
*



View Profile WWW
« Reply #2 on: May 28, 2021, 05:34:56 AM »

I like space station 13 so I am very curious about your creation.

What new additions/modifications do you plan to add in comparison to the source inspiration?

Good luck sir
Logged

Gambit
Level 0
*


View Profile
« Reply #3 on: May 28, 2021, 03:34:21 PM »

I'm still trying to flesh out the game play right now, so in that regard its kind of hard to say, but I would really like to allow the server to choose what type of map they play on (ship/station/planetary habitat), as opposed to it being hardwired into the game itself. On top of that, I'd like to implement some kind of seamless server transition. For example, if we have ServerA and ServerB, and both are "broadcasting"/"open", players from ServerA could board a shuttle to ServerB with the shuttle acting as the "loading screen" while all the players leave ServerA and join ServerB. I guess this might be something analogous to the server clustering in Ark: Survival Evolved, except that its not limited to servers you control.

I'd also like to implement addons/plugins similar to how Garry's Mod does it (Plug-n-Play style).

Back to the gameplay, I'm playing with the idea of making it 3D, but I'm legitimately worried that it will take some of the magic that SS13 has. I guess that comes with the territory of making something inspired and not a clone.
Logged
Gambit
Level 0
*


View Profile
« Reply #4 on: June 02, 2021, 08:03:18 AM »

Tested out some orthographic camera today. I like this a lot compared to first person perspective and I might end up keeping it. I mainly wanted to see how it would feel to move around with different camera transformations. I think Type 1 (Top-down tracked translation with fixed rotation) and Type 3 (Angled [30 degrees] tracked translation with fixed rotation) are easily the best. Not only does the tracked rotation look strange, but it feels very jarring even when you expect it. This could probably be fixed with some smoothing/easing but I don't think it compares to fixed rotation.

Something I might experiment with is manual camera rotation, but if the maps are designed for a fixed camera angle it might not be necessary. It might also be too cumbersome to manually rotate the camera around.



Logged
Gambit
Level 0
*


View Profile
« Reply #5 on: June 04, 2021, 09:25:57 PM »

I decided to try something with the angled camera. One of the biggest problems I foresee with this camera style is that if the map is not specifically designed for the camera view (e.g. if I made a map as if it was to be played in first person), the player's view will be almost always obstructed by walls. One solution I thought about was how the Sims games have the cut-away wall mode. Since I don't know how to do that, I opted for a solution I found on a YouTube video, and this is the result:



I like the result, and with some more work it could be the perfect solution. However, as I stated above, if the player's view is almost always obstructed by walls, this is how the player's view will look a lot of the time.

I think I'll stick with top-down and see how it goes.

This is the YouTube video I found with the solution:

Logged
Ramos
Level 6
*



View Profile WWW
« Reply #6 on: June 05, 2021, 04:21:25 AM »


Back to the gameplay, I'm playing with the idea of making it 3D, but I'm legitimately worried that it will take some of the magic that SS13 has.

I agree but then again if you do not try you will not know.

Good luck
Logged

sqaxomonophonen
Level 0
*



View Profile WWW
« Reply #7 on: July 28, 2021, 04:51:16 AM »

Back to the gameplay, I'm playing with the idea of making it 3D, but I'm legitimately worried that it will take some of the magic that SS13 has. I guess that comes with the territory of making something inspired and not a clone.

I haven't ever played SS13. I think partly because it seems to have an unwelcoming learning curve, and partly because the BYOND tech it's built upon appears quite shoddy :-) Yet its more-roleplay-than-gameplay concept is alluring and I've watched a lot of lets plays. I also toyed with the idea of making a spiritual successor, and making it 3D. Here are some of my thoughts on that:

 - SS13 seems to have benefited greatly from fan contributions, and it's undeniably easier to do some sprites or tiles in MS Paint than to do 3D modelling...

 - On the surface Minecraft would be the perfect engine to support a SS13-like game; somewhat tile-based, destructible environments, multiplayer support,... Also, the "lo-fi" graphics style is a good match? But I think the Minecraft lighting model would be a poor fit for a space game which probably would have a lot more artificial and dynamic light sources than a medieval game (seems it always comes down to lighting with 3D!)

 - World boundaries seem more natural in 2D, or at least we're more used to it. In 3D it seems better to lock the player in, like in a box canyon or whatever, which may be hard if you can do space walks and such. Gravity vs weightlessness is also something you can almost gloss over in 2D, but is probably a hard gameplay problem in 3D?

 - Atmosphere simulation like in SS13 would be more CPU-intensive in 3D.


More general thoughts, whether 2D or 3D:

 - I think built-in voice communication with lip sync face animations would be good for roleplay. With a "gain falloff" you could have a conversation without the rest of the base being able to spy on you, or being annoyed by the chatter. Of course, ideally, a closed door would let out less sound than an open door. This is probably also a much easier problem to solve in 2D than 3D.
Logged

Gambit
Level 0
*


View Profile
« Reply #8 on: August 27, 2021, 09:52:45 AM »

After a long break from working on this project, I have made the decision to move to Unreal Engine 4. It was strongly suggested to me by a friend and its going well so far. Unity was appealing because it uses C# which I am very familiar with, however I felt like the engine wasnt really helping out. UE offers a fully networked and rigged player out of the box without needing their Starter Content. For the same in Unity, I would need their Standard Assets (which were broken in newer versions of Unity), or I would have to source an asset from a third party using their store.

My friend has been helpful with me learning UE4 and I'm enjoying experimenting with their blueprints and network replication tools, although I'm having some trouble understanding how replication works regarding listen servers so if anyone knows more about this I'd be happy to chat.

In the coming days I plan on having a fully functioning lobby setup (like Epic's and DevAddics MP w/ Steam tutorials), which will server as the basis for the new game project in Unreal.

SS13 seems to have benefited greatly from fan contributions
This is a great point and I fully intend to have first party mod support.

- On the surface Minecraft would be the perfect engine to support a SS13-like game; somewhat tile-based, destructible environments, multiplayer support,... Also, the "lo-fi" graphics style is a good match? But I think the Minecraft lighting model would be a poor fit for a space game which probably would have a lot more artificial and dynamic light sources than a medieval game (seems it always comes down to lighting with 3D!)
I'm glad you brought this up. I've gone back and forth on what kind of graphical style I want and honestly I'm still a little undecided. I thought something like 7 Days to Die/Space Engineers would work nicely (especially since the voxels might help a little more with map destruction), then Valheim launched and I realised you could have the best of both worlds: Great pixel lighting with voxel terrain. I'm unsure how I'm going to approach this though.

- World boundaries seem more natural in 2D, or at least we're more used to it. In 3D it seems better to lock the player in, like in a box canyon or whatever, which may be hard if you can do space walks and such. Gravity vs weightlessness is also something you can almost gloss over in 2D, but is probably a hard gameplay problem in 3D?
I think localizing player gravity could solve the gravity for the most part. For the map boundaries: I started reading about Map Composition in Unreal but I need to study it a bit more since my original idea was to have maps be composed of other maps. You have your "main" map (station/ship/whatever) then the server will randomly load in adjacent maps for things like asteroids and derelict ships. This would also pave the way for travelling star systems since it should (in my mind) be a simple load/unload? I'm not sure yet.

- Atmosphere simulation like in SS13 would be more CPU-intensive in 3D.
A problem for another time Giggle I'm going to guess that a "simple" graph data structure would work for things like atmos and electrical networks.. But I'm not smart enough to figure this out yet..

- I think built-in voice communication with lip sync face animations would be good for roleplay. With a "gain falloff" you could have a conversation without the rest of the base being able to spy on you, or being annoyed by the chatter. Of course, ideally, a closed door would let out less sound than an open door. This is probably also a much easier problem to solve in 2D than 3D.
Localized voice chat is absolutely something I plan on including. Limiting the voice chat to a "room" would be a great addition since having 100% text communication is horrible in a real-time game.
Logged
Gambit
Level 0
*


View Profile
« Reply #9 on: August 30, 2021, 02:02:04 AM »

Got a "server browser" working. It uses Advanced Sessions and creates a new UMG widget for each session.

Initially I had the list server up as a ListView widget which caused me some problems. When I added my session item, the item would not store the session I gave it, so I thought maybe the session data was becoming invalid somewhere and decided to store all the sessions in the GameInstance, then give the session item an index, which didnt work either. I then thought maybe it was some kind of caching issue with how Unreal does incremental builds. After rebuilding Unreal source, and the project, I ended up swapping the ListView for a VerticalBox and it solved literally every problem I was having.

The final result is functional but not very nice looking, and decided to add a properties window (The blue window) which only displays the "Extra Settings" keys. Funnily, because I'm using the Steam OSS and using the SpaceWar Steam AppID, it shows up all servers for SpaceWar. Annoyingly, I can't control the timeout for the `Find Sessions Advanced` node and it seems to return some sessions after about 5 seconds, but each time I look I get different sessions - I even set the `Max Results` input to 100.
Logged
Gambit
Level 0
*


View Profile
« Reply #10 on: September 13, 2021, 06:44:40 AM »

In the past 2 weeks I have been playing around a bit more with building Unreal from source which is required for dedicated servers (which I'm supporting from the start). I didn't really have a starting point for my game, but decided to checkout the vehicles in Unreal and found out that they don't support AI navigation out of the box. I stumbled upon a blog article which details how to implement a PID to control the vehicle (https://superyateam.com/2020/04/18/how-to-implement-vehicle-ai-in-ue4/). All I had to do was create a new UWheeledVehicleMovementComponent4W class which contains the PID, and a  AWheeledVehicle class who's only job is to substitute the default Vehicle Movement Controller with my custom one. By default, Unreal 4 uses PhysX for vehicles which are deprecated in 4.27 so I tried switching to Chaos. Unfortunately, after adapting the PID to work better with Chaos, it still did not work as well as it does with PhysX. Given that Chaos is still experimental I decided to go back to PhysX. The result of all of this is that the default AI Controller works perfectly when issued `Move To Actor/Location` commands, given that a NavMeshBoundsVolume exists.

I also added in support for passenger seats to the base sedan. This was actually quite trivial to implement, however there are some annoyances I could not solve. The heart of the implementation is setting up sockets to act as the seat transformations, tracking which seats are available, and attaching the player's character to that socket on entry. I also added in extra sockets for exit positions so I wouldn't have to guess or calculate exit positions. My blueprint also tracks the driver and handles vehicle possession for them, but not for passengers. There are only 2 things that I could not fix:

The first is that I had to disable collisions for the character's capsule, and disable the character movement component. If I set the capsule to query, the character gets pushed out of the vehicle most times and the vehicle does not drive correctly and ends up flipping. I tried changing the channel response for vehicles to ignore/overlap, but it didn't work. This isn't necessarily a bad thing, but it means that traces wont hit players inside of vehicles.

The second is that when passengers would enter the vehicle, their camera would get stuck inside the seat. They would look around but would only see inside themselves. I managed to fix this by turning off Camera Settings -> Do Collision Test in the spring arm of the character. This is not ideal as the camera now clips through everything. I tried setting this value when they entered/exited the vehicle but it didn't seem to make a difference if it was changed while playing. I probably could have tried to set the collision channel but this is good enough for now.

Values for the PID if anyone is interested:
Throttle:
  • Proportional: 0.9
  • Integral: 0.3
  • Derivative: 0.5
  • Min Error: 0.0
  • Max Error: 0.02

Steering:
  • Proportional: 0.5
  • Integral: 0.3
  • Derivative: 0.2
  • Min Error: 0.0
  • Max Error: 1.0


Logged
Gambit
Level 0
*


View Profile
« Reply #11 on: September 17, 2021, 10:59:43 AM »

I decided to try and implement the musical instruments from FTL13. The end result is a very pleasant success, however I decided to not use my brain at first. Originally, I planned to prototype this in Blueprints, however that quickly became and unmanageable mess, resulting in massive Blueprints that were difficult to read, follow, and were overall worse than just writing the code by hand.




Surprisingly this actually worked for the most part. The mistake I made was using `Delay` to enforce the tempo, which doesnt play nicely if you need it to delay execution for the entire event.

I ended up scrapping Blueprints entirely for the implementation and moving to C++, where I could more easily port the original code. I ended up using a Sound Cue to represent each instrument's note capacity, and using a Branch node with a named bool parameter equal to the name of the note. Its not very nice to look at but it works better than my previous attemps.




Once it was playing the songs properly, I noticed that each chord it was playing was cut off by the next chord being played on the same Audio Component.





The solution to this was to create a pool of UAudioComponent* and create them if there wasn't a component which wasn't playing, then remove them all when the song is finished. I considered removing them on-the-go but it ended up removing them as soon as they finished playing, meaning another component had to be created a few chords later. A better solution might be to track which components have not been used recently and remove them.





I thought this song sounded particularly nice on the piano:
https://youtu.be/GdvjJ9YoNd4

And the bikehorn because why not? Doesnt have the note capacity for the song though.
https://youtu.be/wOEf0eblRF0

Source procs from FTL13 can be found here:
Logged
Pages: [1]
Print
Jump to:  

Theme orange-lt created by panic