The new forums will be named Coin Return (based on the most recent vote)! You can check on the status and timeline of the transition to the new forums here.
The Guiding Principles and New Rules document is now in effect.
[Design On] Space Station 14
AJAlkaline40
__BANNED USERS regular
__BANNED USERS regular
Now, I'm going to level with you. A lot of people have said in the past that they intend to make a remake of SS13. They've said that they were going to make a Source version, or a Torque version, or even just make a new version in Byond just with better netcode. Some of these projects have gotten closer to fruition than others, but none of them have ever gotten finished. It's largely just because a game of the magnitude of SS13 requires a huge investment of time and effort, and most people aren't ready to deal with that sort of commitment for no reward. Well, I'll be honest, there's at least a 50% chance I'll never go anywhere with what I'm making either, and if I ever do get this game into releasable beta, it's going to be in at least a couple of years. However, I figure that if I ever intend to make a game some day, I might as well have a project to start with.
Anyway, without further ado:
I am attempting make a remake of Space Station 13 (thread here, in case you're not familiar with it). I would be programming the game in Java and utilizing Project Darkstar for handling the online multiplayer component. I also intend to draw all the art assets myself. I am, however, very open to advice or suggestions. I am a novice, I've never made an entire game before, much less an online multiplayer game, but I am very familiar with Java and have a fair amount of confidence in my abilities. Obviously, this is a huge undertaking for someone like me, so I'm going to be working on the whole thing in bits and pieces, and only intend to produce a product over a very long term.
Ideally, the finished game will be isometric, and preserve all the elements of gameplay complexity and detail of the original. It will take a long time to get there, though.
For a vague hint of what the finished game will look like (and how pitifully little I've managed to do so far), here's a screenshot of my current isotile experiment:
(As of now, you can move the toolbox around the map with the WASD keys, the map scrolls as you move around it, and can vary many tiles on the z-axis as well as the y and x)
The major purpose of this thread, however, is to give me suggestions on to what sort of gameplay elements you'd like to see in the finished (gods willing) version of the game. I would also be willing to accept any help or expertise from those better versed in what I'm working with.
So far, a few ideas I've been tossing around:
A wiring system akin to the GMod wire mod, allowing complex creations with logic gates,
An "objective" mode in which the crew works together to fulfill a mission objective,
New aspects such as navigation, asteroid mining, and complex surgery.
Also, I've been working on how I want the basic user interface to work (one of the most archaic parts of the original), and my idea so far is that most actions would be done through holding a key on the keyboard and clicking the right or left mouse button to correspond to the right or left hand. For instance, if you want to grab an object with your left hand and throw an object in your right hand, you'd hold 'G' and left-click then hold 'T' and right click.
Anyway, please, go ahead and give me your ideas.
Anyway, without further ado:
I am attempting make a remake of Space Station 13 (thread here, in case you're not familiar with it). I would be programming the game in Java and utilizing Project Darkstar for handling the online multiplayer component. I also intend to draw all the art assets myself. I am, however, very open to advice or suggestions. I am a novice, I've never made an entire game before, much less an online multiplayer game, but I am very familiar with Java and have a fair amount of confidence in my abilities. Obviously, this is a huge undertaking for someone like me, so I'm going to be working on the whole thing in bits and pieces, and only intend to produce a product over a very long term.
Ideally, the finished game will be isometric, and preserve all the elements of gameplay complexity and detail of the original. It will take a long time to get there, though.
For a vague hint of what the finished game will look like (and how pitifully little I've managed to do so far), here's a screenshot of my current isotile experiment:
(As of now, you can move the toolbox around the map with the WASD keys, the map scrolls as you move around it, and can vary many tiles on the z-axis as well as the y and x)
The major purpose of this thread, however, is to give me suggestions on to what sort of gameplay elements you'd like to see in the finished (gods willing) version of the game. I would also be willing to accept any help or expertise from those better versed in what I'm working with.
So far, a few ideas I've been tossing around:
A wiring system akin to the GMod wire mod, allowing complex creations with logic gates,
An "objective" mode in which the crew works together to fulfill a mission objective,
New aspects such as navigation, asteroid mining, and complex surgery.
Also, I've been working on how I want the basic user interface to work (one of the most archaic parts of the original), and my idea so far is that most actions would be done through holding a key on the keyboard and clicking the right or left mouse button to correspond to the right or left hand. For instance, if you want to grab an object with your left hand and throw an object in your right hand, you'd hold 'G' and left-click then hold 'T' and right click.
Anyway, please, go ahead and give me your ideas.
AJAlkaline40 on
0
Posts
Don't take suggestions.
Make a clone of SS13 first, then add originality, trying to make this both at once is difficult.
The thing is that it's going to be fundamentally different no matter what. It's not going to really be a clone of SS13 at any stage in development. Of course, most of the suggestions that I receive in this thread aren't going to be things that I would try to implement until long into the development of this thing, but some of them would be pretty fundamental and would be worth discussing now.
This, primarily, is why Obs' StellarSapien failed to pan out. Ultimately it was because he hated coding in Byond and lost interest, but if the design team really hunkered down and convinced him the project needed a framework to stand up on its own as a testable game (then move towards a grand space explorer/random alien encounter generator), the player base's interest would have taken off. They'd merely use it to play Traitor mode games at first, but it'd put way more momentum into the full project later than untested ideas and half-attempts.
I really miss StellarSapien. Being able to perform brain transplants on people and apes with a consistent drag & drop interface was really something special.
I agree with the others though. At this stage, suggestions might only hinder you. It might be fun to talk about possibilities, and it might even encourage you to keep going if you get excited about some possibilities, but the focus should be on getting a working game first.
That disclaimer said:
Different models of ships, and space battles.
I mean, XNA can do 2D stuff no problem. Tile based things for it are really simple. Moreover, you get a powerful language with good network support (I mean, it comes with lots of premade classes for networking). The graphics engine is really simple to use, too: just fire up a SpriteBatch, and tell it where to draw something. Poof. Drawn. C#/XNA books are cheap and plentiful; online tutorials moreso. Not to mention that it has a rather good IDE released and updated for free.
XBL: LiquidSnake2061
Hm, I hadn't really considered it...
Honestly, my main attraction to Java is that I already know how to use it :P. I'm not really familiar with any other languages. As far as easy networking, I'm liking what I see out of Project Darkstar so far. I'll think about it, though.
EDIT:
Hm...space battles...
You know, some kind of Star Trek style fighting may be feasible. It does make me think about how I want to do the movement of the ship in space.
I don't really know the merits of Byond but from what I've seen I don't really like it. I support XNA.
Space battles could rock (especially if players could board the enemy ship to sabotage it), but there could be a serious problem with maneuvering, obvious from the grid based game play.
If the fighting is supposed to be Star Trek style, which it should, then maneuvering could be done under a second system entirely. The ships placements and orientation could all be based off of coordinate information, and nothing else. Basically, the coordinate information would let players know what they can attack, and how long they have to defend against an attack. Part of the tactics should definitely involve targeting systems, protecting systems from being targeted, and maneuvering in a method that best allows your weapons to fire on the enemy's various systems. I always loved Star Trek's sense of navy battleships, but in zero G space.
edit:
Man, that would make a sweet MMO. It would be way too niche though. Would it be possible for individual servers to be ships, and players create a character on said ship, then rival servers could attack one another based on their spacial coordinates? Various ships (servers) would have different player capacities, and would probably want to base the ship around what would work best with said (server) capacity. Be cool flying around, exploring planets, finding new technology, then running into a ship of an alien race that your race is at war with. Seems like the massive multiplayer element of it would be pretty low on bandwidth demands if most of the player controlled stuff is server side.
Fuck.... I'm such a nerd.
Of note, I learned Java in college and shifted to C#. It's very similar, but C# has some more power.
I think the biggest problem I had when switching is that I always forget that C# doesn't allow you to wildcard include. E.g.:
Other than that (and that System.out.println() is now Console.WriteLine()). it's a rather easy switch, and it's much easier to do just about anything with graphics.
XBL: LiquidSnake2061
Project Darkstar is actually made to support MMOs. It's based around persistent servers.
Of course, I wouldn't be attempting anything nearly so ambitious until I actually have a playable game set up more like the original SS13 (as so many are suggesting), but as a thought of a project to attempt in the future, that's actually a pretty interesting idea.
EDIT:
The funny thing is that the graphics system is basically all I have figured out so far :P. I've already figured out how to stack the tiles correctly and place objects on-top of them and animate the scrolling of the map and all that good stuff.
I'd say an MMO like that could focus strongly on individual character progression, the progression of the ship, and the progression of the faction.
I have been working quietly on an XNA powered game engine specifically for this purpose. It is by no means ready for game development, but I would be happy to throw my programming abilities at this project if you choose to go with C# and XNA.
Linked for h-scroll rape.
Yes, I figured that these two things together were the number one concern: the unintuitive and over-complex interface, and the poor net-code. I'm positive I'll be able to improve upon the interface. I was wondering, though, how did Stellarsapien go about improving upon either of these things?
The netcode for SS13 wasn't really the terrible part; it lagged because the gas coding was really inefficient. The game was originally written as a proof-of-concept for the gas stuff, but they kept adding and adding to it. The source was spaghetti, and that led to most of the problems.
As for the UI, I think they never really got around to modifying it :P
XBL: LiquidSnake2061
Yeah, I've been thinking about the gas code, actually. Wasn't it something like every square of gas would periodically check to see if it could disperse or heat up or something?
If that's the case, what I'm thinking is that I would have the gas find out what its equilibrium position would be when something in its immediate environment changes that would change the equilibrium position, then have it incrementally move towards that position and stop when it gets there, recalculating the equilibrium whenever something crucial changes in the meantime.
Also, if at some time in the future you plan to allow people to help you in the coding, you need to start designing with that in mind from the very start. My problem was that the code I wrote didn't really lend itself well to collaboration because it lacked suitable documentation (or rather it wasn't self documenting), and when this happens the game doesn't scale well later because people have to figure out too much code to determine where they can add new features. You had to actually be like some kind of guy who knew what he was doing. I actually started working on a new BYOND engine for a while sometime this year that was designed for collaboration and could produce SS13 like games.
Also, SS13 isn't really a game of huge magnitude once you figure it all out. At the core it's basically a world where you can move around and interact with various objects, and objects can interact with you, and occasionally you have an objective. The illusion of depth is created by the interactions that result from you using objects to interact with other objects, which causes the amount of possibilities to increase by some magnitude of order N.
You don't have to handle gas tile by tile, the approach I used in BYOND was to actually have entire "clusters" of clouds, and all the data is stored in matrices, not objects. This gave a huge performance boost. You could drain an entire station in probably less than a minute if you left even one door to space wide open.
A cloud cluster is a group of tiles that all have the same value, such as the tiles in a sealed room. Each tile doesn't actually have a value itself, but rather a pointer to an index in an array where you find the value for the air of a tile in that cloud. This means you can instantly change the value of air for any group of tiles in O(1) time.
In order to correctly compute the average air for the cloud, the cloud cluster must also know how many tiles are in the actual cluster, this is done by having another array with the same index from before that automatically gets incremented and decremented as new tiles join in.
It might be really complicated to understand, I spent quite some time on it.
This is where it gets complicated
A new cloud is created in any situation that changes air values, because if two tiles have different air values for some reason then they are not in the same cloud obviously. The origin of the cloud is usually at the place of change. I believe a more recent cloud always overrides an older cloud.
If a cloud loses a tile to another cloud, it's average air value shouldn't really change, because not only does the new cloud claim the tile but you also claim the amount of air it had. As a new cloud is expanding it's average air value is constantly fluctuating due to new tiles and their air values coming in constantly. By the time it has expanded, the new cloud has stabilized with the final average of the air value across all the tiles, as seen in that diagram with the two rooms of equal size but different air values. 14 and 2 are the values of air for each tile in those rooms.
Meh, this is insufficiently explained, but it works
there are special conditions
for when a cloud
touches a vacuum tile
In the example image I posted the value of the blue cloud when it begins to expand should actually always be 8 if it's expanding uniformly on both sides of the room (which it should be, because the rooms are the same geometry)
Specifically, my idea was to create a Sealab 2021 version. Same concept, but underwater, and an appropriate setting. The game would be made objective-based by taking every single player and giving them various, clear objectives, all of which would lead to some sort of conflict with other players. Each player would be scored on these objectives and announced at the end and kept on an ongoing basis, but no real "winner" would be declared, as that wouldn't be the spirit of the game. If funny shit happens, everybody wins.
Objectives would ideally be chosen in a manner that tries to promote cooperation and competition between certain players, but inevitably leading to conflict. For inspiration, just watch Sealab for a bit, take what people are doing, and boil it down to simple actions. If you want some Martian Law, give somebody an objective of "watch as many people get the shit beaten out of them as possible", and give one or two other people "beat the shit out of as many people as possible".
Anyway, a list of potential objectives, off the top of my head, could be things like,
"Get high as shit"
"Get everybody else high as shit"
"Convert the crew to worship of Mardok" (score based on how many times other people say "Mardok")
"Get people to shut the fuck up"
"Prevent anybody from leaving Sealab"
"Kill all animals!"
"Hug all animals!"
"Destroy everything that is the color red"
"Just hang out with your homies, yo" (periodic scoring for being near people)
"Follow Jim" to be paired with Jim's objective, "Stay the fuck away from people" (which would be boring on its own)
"Paint the walls with blood"
The idea is that you codify the crazy shit that goes on. Instead of relying on people to come up with the crazy shit themselves - which generally results in "I'm cutting down this wall" "Why the shit are you cutting down this wall?" "TOOLBOX'D" - you give people incentives be more creative. The objectives are not intended to force a re-enactment of the same thing over and over, but to try to get people to come up with a creative way of accomplishing what they're told to, IE: you could paint the walls with blood by collecting legitmate blood samples and just, you know, throwing them all over the place. Also, perhaps one person every game should have the objective of "destroy Sealab!" to keep everybody else appropriately paranoid.
I guess my point is, the fun of SS13 was in the crazy shit people got up to, and participating in it. Everything that was added to the game that enhanced this crazy shit was good. Everything that didn't was not. Focus on the crazy shit.
I would play that. I would play the hell out of that. It would be amazing in something like a MUD environment, which would also be perfect for actually keeping score of stuff like that in-engine. But maybe that's just me.
Also, I like the look of that tile test. I'm looking forward to perhaps seeing a character. Even if it's just a little concept.
I think that would be the way to go - to encourage the collaborative aspect. I was just musing.
That's a fantastic concept. Think there might be a way to implement this in SS13?
Twitch (I stream most days of the week)
Twitter (mean leftist discourse)
What you are essentially tying to create is a "B game", which is incredibly hard to do on purpose.
SS13 is a B game in every sense. It's got a crappy interface, shitty graphics and shitty code, but people will probably always play it because it's so bad it's good, and it's become a sort of cultural icon thing with good name recognition on forums. It's all in the marketing.
Meh, popularity isn't really what I'm going for. Largely this is just a project to get me associated with making games. I have some ideas for other games I could make using the online multiplayer isotile engine.
You could have started with a traditional tetris>breakout>pacman>mario progression