Re: Containment Breach Unity Edition (2016) - General build v0.3.1a is out (1/8/17)
#301Looks amazing! Keep up the great work!
Re: Containment Breach Unity Edition (2016) - General build v0.3.1a is out (1/8/17)
#302You could also add a "difficulty" parameter or multiple, which all affect the difficulty.zornor90 wrote:Thanks! And correct, the hallways are increasedME2 wrote:
Wow, looks great! Are the bigger maps then just filled with more/longer hallways?
There are several parameters so far
1) Distance between sectors
2) Distance between rooms in sectors
3) Amount of rooms per sector
You can choose a static number or a range (say like, 3-5 rooms per sector)
The default will be smaller maps, probably with 1-3 hallway distance. I'll have to see what people prefer!
I'll definitely be looking for feedback, and there will be a lot of tweaking to make as I move forward. The nice thing is that this is fully Object Oriented now, and will scale infinitely with new rooms added by devs and modders.
-Tesla gate frequency ( less=harder, should also make 106s following longer)
- This one could be really hard to code but I'll still say it, a parameter that affects how "hidden" rooms are, and how hard rooms are to reach. For example more rooms in positions like the middle of a G (which for example would greatly affect how hard 106 is to get rid of/avoid.)
(also, obviously rooms like the electrical center would be the ones to hide, scp rooms (especially those you don't need/want to go inside) would stay the way they are.
- You once talked about reworking the key card system, so this could go along good with it:
1. Changing the luck, ( option ) meaning the frequency of finding keycards or Keycard rooms.
2. Making it harder or impossible to get to higher keywords without having the Keycard needed before
(This should be connected to the parameter you talked about, which changes how often you find important rooms and how much you have to walk. Because if this one would be set to impossible for example and the parameter above to small/easy it would be very easy to get through.) And what I mean with connected is that if this one is set to the harder ones, the important room parameter also gets set to bigger/higher, to keep players from accidently creating maps that are too easy.
Edit: I just noticed the "G" isn't the best example for more hidden rooms, but it still would be a option to use hallways like that for important rooms.
So yeah... More Hidden rooms would then be rooms which have few (or 1) connections, to the rest of the map
(meaning the room in front of it always aswell)
And yeah, then those ways that lead to these rooms should be encapsulated by other ways.
... Yeah, everything here is a suggestion but the hidden room thing is a more "ignorable" one, it's just a hard to define addition to the "rate of important rooms" parameter, that you already have.
Re: Containment Breach Unity Edition (2016) - General build v0.3.1a is out (1/8/17)
#303These are some really good ideas! When you say hidden rooms, do you mean that all rooms would be harder to get to, or just specific ones?ME2 wrote:
You could also add a "difficulty" parameter or multiple, which all affect the difficulty.
-Tesla gate frequency ( less=harder, should also make 106s following longer)
- This one could be really hard to code but I'll still say it, a parameter that affects how "hidden" rooms are, and how hard rooms are to reach. For example more rooms in positions like the middle of a G (which for example would greatly affect how hard 106 is to get rid of/avoid.)
(also, obviously rooms like the electrical center would be the ones to hide, scp rooms (especially those you don't need/want to go inside) would stay the way they are.
- You once talked about reworking the key card system, so this could go along good with it:
1. Changing the luck, ( option ) meaning the frequency of finding keycards or Keycard rooms.
2. Making it harder or impossible to get to higher keywords without having the Keycard needed before
(This should be connected to the parameter you talked about, which changes how often you find important rooms and how much you have to walk. Because if this one would be set to impossible for example and the parameter above to small/easy it would be very easy to get through.) And what I mean with connected is that if this one is set to the harder ones, the important room parameter also gets set to bigger/higher, to keep players from accidently creating maps that are too easy.
Edit: I just noticed the "G" isn't the best example for more hidden rooms, but it still would be a option to use hallways like that for important rooms.
So yeah... More Hidden rooms would then be rooms which have few (or 1) connections, to the rest of the map
(meaning the room in front of it always aswell)
And yeah, then those ways that lead to these rooms should be encapsulated by other ways.
... Yeah, everything here is a suggestion but the hidden room thing is a more "ignorable" one, it's just a hard to define addition to the "rate of important rooms" parameter, that you already have.
Yeah the keycard system is going to be totally reworked - right now I feel that it is too heavily weighted to a key2 and then a key5 / omni. I haven't decided whether or not to even keep the current keycard system, but if I do, then I have several plans to make the system more fun and engaging.
One of the things I also want to do is establish several different ways to complete an objective - and a map could spawn with anywhere from one to all of them. For example, several different ways to get to the elevator to heavy containment. This will help keep playthroughs of the game fresh!
Re: Containment Breach Unity Edition (2016) - General build v0.3.1a is out (1/8/17)
#304Thanks!TheManWithTheTopHat wrote:Looks amazing! Keep up the great work!
Awesome, the more people testing this the better!xhul wrote:Hello there...
Seeing how far that project has gone, i must say i'm really excited, and scared at the same time (that it actually never sees the light).
But for some reason, i have faith in you.
You can definitely count on me for feedback & testing (even heavy stuff).
I'll keep on monitoring this as often as possible.
Keep up the good work !
love =]
EDIT : I'll do my best to unlock enough time in the days to come for a deep 0.3.1a test.
Re: Containment Breach Unity Edition (2016) - General build v0.3.1a is out (1/8/17)
#305zornor90 wrote:These are some really good ideas! When you say hidden rooms, do you mean that all rooms would be harder to get to, or just specific ones?ME2 wrote:You could also add a "difficulty" parameter or multiple, which all affect the difficulty.zornor90 wrote:
Thanks! And correct, the hallways are increased
There are several parameters so far
1) Distance between sectors
2) Distance between rooms in sectors
3) Amount of rooms per sector
You can choose a static number or a range (say like, 3-5 rooms per sector)
The default will be smaller maps, probably with 1-3 hallway distance. I'll have to see what people prefer!
I'll definitely be looking for feedback, and there will be a lot of tweaking to make as I move forward. The nice thing is that this is fully Object Oriented now, and will scale infinitely with new rooms added by devs and modders.
-Tesla gate frequency ( less=harder, should also make 106s following longer)
- This one could be really hard to code but I'll still say it, a parameter that affects how "hidden" rooms are, and how hard rooms are to reach. For example more rooms in positions like the middle of a G (which for example would greatly affect how hard 106 is to get rid of/avoid.)
(also, obviously rooms like the electrical center would be the ones to hide, scp rooms (especially those you don't need/want to go inside) would stay the way they are.
- You once talked about reworking the key card system, so this could go along good with it:
1. Changing the luck, ( option ) meaning the frequency of finding keycards or Keycard rooms.
2. Making it harder or impossible to get to higher keywords without having the Keycard needed before
(This should be connected to the parameter you talked about, which changes how often you find important rooms and how much you have to walk. Because if this one would be set to impossible for example and the parameter above to small/easy it would be very easy to get through.) And what I mean with connected is that if this one is set to the harder ones, the important room parameter also gets set to bigger/higher, to keep players from accidently creating maps that are too easy.
Edit: I just noticed the "G" isn't the best example for more hidden rooms, but it still would be a option to use hallways like that for important rooms.
So yeah... More Hidden rooms would then be rooms which have few (or 1) connections, to the rest of the map
(meaning the room in front of it always aswell)
And yeah, then those ways that lead to these rooms should be encapsulated by other ways.
... Yeah, everything here is a suggestion but the hidden room thing is a more "ignorable" one, it's just a hard to define addition to the "rate of important rooms" parameter, that you already have.
Yeah the keycard system is going to be totally reworked - right now I feel that it is too heavily weighted to a key2 and then a key5 / omni. I haven't decided whether or not to even keep the current keycard system, but if I do, then I have several plans to make the system more fun and engaging.
One of the things I also want to do is establish several different ways to complete an objective - and a map could spawn with anywhere from one to all of them. For example, several different ways to get to the elevator to heavy containment. This will help keep playthroughs of the game fresh!
Just specific ones, I imagine if too many rooms that have a higher importance than hallways are tried to be hidden, none of them would be at the end or the map would get too weird and repetitive (you could see where the hidden ones are because the hallways have no other options most of the time, then to show to them, when there are too many. Atleast that's what I think ) .
So yeah, important rooms (except for the item related things like the refinery) should also only have a CHANCE/Percentage to be hidden (which increases when the room is more important like the electrical room)
So there would be 2 things
- hidden at all?
And
-Percentage of tried hiddenness
All rooms that aren't important are not hidden at all and all important rooms should have multipliers to the percentage eg.
camera room x1.2
electrical center x2
And all percentages below something specified like 5% should be ignored and disable the hidden at all thing.
Re: Containment Breach Unity Edition (2016) - General build v0.3.1a is out (1/8/17)
#306Ahhh ok. This make sense! It also gives me an idea - I currently have a class called ZoneSector, which creates a sector given a list of rooms. I could subclass that and add a HiddenZoneSector class, which would then generate a different room structure and attempt to hide the room(s) passed into the function. Then if a room's hidden percentage returns true, create a HiddenZoneSector for those rooms rather than a ZoneSector.ME2 wrote:
Just specific ones, I imagine if too many rooms that have a higher importance than hallways are tried to be hidden, none of them would be at the end or the map would get too weird and repetitive (you could see where the hidden ones are because the hallways have no other options most of the time, then to show to them, when there are too many. Atleast that's what I think ) .
So yeah, important rooms (except for the item related things like the refinery) should also only have a CHANCE/Percentage to be hidden (which increases when the room is more important like the electrical room)
So there would be 2 things
- hidden at all?
And
-Percentage of tried hiddenness
All rooms that aren't important are not hidden at all and all important rooms should have multipliers to the percentage eg.
camera room x1.2
electrical center x2
And all percentages below something specified like 5% should be ignored and disable the hidden at all thing.
Something like (pseudocode):
Code: Select all
public void DivideRoomsIntoSectors() {
List<RoomSector> sectors;
foreach (Room r in rooms)
if r.shouldBeHidden
sectors.Add(new HiddenZoneSector(r))
else
sectors.Add(new ZoneSector(r))
Re: Containment Breach Unity Edition (2016) - General build v0.3.1a is out (1/8/17)
#307I forgot to mention that the percentages that would then result eg. electrical room percentage 58% could correspond to a list of pre-entered ways like:zornor90 wrote:Ahhh ok. This make sense! It also gives me an idea - I currently have a class called ZoneSector, which creates a sector given a list of rooms. I could subclass that and add a HiddenZoneSector class, which would then generate a different room structure and attempt to hide the room(s) passed into the function. Then if a room's hidden percentage returns true, create a HiddenZoneSector for those rooms rather than a ZoneSector.ME2 wrote:
Just specific ones, I imagine if too many rooms that have a higher importance than hallways are tried to be hidden, none of them would be at the end or the map would get too weird and repetitive (you could see where the hidden ones are because the hallways have no other options most of the time, then to show to them, when there are too many. Atleast that's what I think ) .
So yeah, important rooms (except for the item related things like the refinery) should also only have a CHANCE/Percentage to be hidden (which increases when the room is more important like the electrical room)
So there would be 2 things
- hidden at all?
And
-Percentage of tried hiddenness
All rooms that aren't important are not hidden at all and all important rooms should have multipliers to the percentage eg.
camera room x1.2
electrical center x2
And all percentages below something specified like 5% should be ignored and disable the hidden at all thing.
Something like (pseudocode):Then eventually more subclasses could be added for different behavior (like locking an entire sector behind a keycard, for instance)Code: Select all
public void DivideRoomsIntoSectors() { List<RoomSector> sectors; foreach (Room r in rooms) if r.shouldBeHidden sectors.Add(new HiddenZoneSector(r)) else sectors.Add(new ZoneSector(r))
4% and below = not hidden
5% and above =
20% and above =
50% and above = generated to be not easily avoidable by 106 and 173 ( long hallways leading to it, and few tesla gates)
70% and above = generated to be not easily avoidable by 106 and 173 ( long hallways leading to it, and no tesla gates)
90% and above = hardest... something
overall hiding rooms... seems really complicated to me because i cant even come up with examples to the things above.
I dont fully understand what you wrote, so... i´ll just put this out there
(in particular :where r gets its properties from, what a sector is, and if r changes above)
(i dont even know what i dont know
)i would first generate the spawn and exit, then generate the finished "hidden/ room importance factors"
(i dont think the refinery should be hidden, or atleast very improbable to be so i would set the before mentioned multipliers to a value like 0.2 ( which also destroys the partial importance - hiddenness multiplier correlation )
then i would start with the rooms with the highest hiddenness percentage,
(and all of the hallways connected that contribute to the hiddenness) from high to low.(which makes it impossible for 2 hidden rooms to spawn within anothers hidden hallway constructs, but i dont think that would lead to problems, i think there should even be more space added between each hidden room ENTRANCE (entrance because there wouldnt be a problem if these rooms would be next to each other, but only the entrances (1 way in particullar))
and yeah, then some magic ( i guess SCPS like the piece of paper or the bell should normally be treated like hallways, but shouldnt or very rarely spawn in hidden room constellations like above)
Then some more magic. scp rooms, and then normal hallway generation
Of course i dont expect you to learn anything from reading this, i dont know anything about creating games and world/map generation and just a bit of coding
but if you take any ideas out of reading the thing above / or see ways to go around problems you encounter it was worth it.
Re: Containment Breach Unity Edition (2016) - General build v0.3.1a is out (1/8/17)
#308Why would the SCP Foundation hide important rooms in the facility? That makes no sense, even less in an emergency event. That would only make them seem as if they wanted everything to fail and the SCPs to escape in case of emergency, because important rooms with the appropriate security measures would be hidden. In short: Like stupids.
Zornor, if you are going to add that feature I suggest you do in a separate mode, because it just kills the immersion.
Zornor, if you are going to add that feature I suggest you do in a separate mode, because it just kills the immersion.
Re: Containment Breach Unity Edition (2016) - General build v0.3.1a is out (1/8/17)
#309ME2 wrote:-snip-
Yeah I think that this will be a separate game mode, maybe like 'suicide' where the game is literally trying to kill you, ie the 'keter' mode in the current game. The standard mode will (hopefully) feel more like a real facility with stuff laid out on grids and stuff. Although I like the idea of a very hard game mode for players to challenge themselves, if I make the game too hard then it's easy to lose immersion. Making it a separate game mode is a great idea and I think the best way to handle it; I'm all about making the game customizable without losing the central vision. Also I (hope) to make the game moddable enough that modders can add their own game modes.Brunou8 wrote:-snip-
Speaking of that, getting very close to the new worldgen! Rotation and number of exits are back in.
Code: Select all
/// <summary>
/// Rotates the room so that it can connect to a neighbor in the specified direction.
/// </summary>
/// <param name="direction">Direction the neighbor to connect to is in.</param>
protected virtual void RotateToConnectAt(GridDirection direction)
{
switch (direction)
{
case GridDirection.down:
angle = RotateAngle.deg180;
break;
case GridDirection.left:
angle = RotateAngle.deg270;
break;
case GridDirection.right:
angle = RotateAngle.deg90;
break;
case GridDirection.up:
angle = RotateAngle.deg0;
break;
}
}
Code: Select all
/// <summary>
/// Rotates the room so that it can connect to a neighbor in the specified direction.
/// </summary>
/// <param name="direction">Direction the neighbor to connect to is in.</param>
protected override void RotateToConnectAt(GridDirection direction)
{
switch (direction)
{
case GridDirection.down:
if (hasRight)
angle = RotateAngle.deg180;
else if (hasLeft)
angle = RotateAngle.deg270;
break;
case GridDirection.left:
if (hasDown)
angle = RotateAngle.deg270;
else if (hasUp)
angle = RotateAngle.deg0;
break;
case GridDirection.right:
if (hasUp)
angle = RotateAngle.deg90;
else if (hasDown)
angle = RotateAngle.deg180;
break;
case GridDirection.up:
if (hasRight)
angle = RotateAngle.deg90;
else if (hasLeft)
angle = RotateAngle.deg0;
break;
}
}