Suggestions

Save slots for controller configuration. For quick and easy switching when a player want a different key set up for Match/Ctf and Coop/Race.

Notification in the high score screen (the one that displays the names and score when the button is held.) of when an emblem is captured already. Maybe a check mark next to their name when the person is done the stage as well.

Raise the jump height limit in Mario mode. Mario can get on top of his boxes but sonic can't.

More animals. Attacking a enemy fish and releasing a bird that flys underwater doesn't look right.
 
Last edited:
One thing I would really like to see fixed for 2.1 is SRB2's problem with rendering large rooms. The maps I make that have large rooms experience all sorts of graphical glitches, and nothing I do to fix them helps. Textures appear larger than they are, slime trails span half the screen, etc. I'm extremely frustrated by this glitch, and it really should be fixed.
 
It would have been fixed long ago if it was that easy. SRB2 uses Doom's rendering system, and that wasn't designed for large rooms. Just make smaller rooms.
 
I'll try to make my rooms smaller, of course it would probably require a large amount of coding to fix those errors.
 
Bomb Monitor.
It explodes after lets say 10 seconds,you can pass it to other players,and the one who has the bomb when it explodes gets hurts.
 
Last edited:
Bomb Monitor.
It explodes after lets say 10 seconds,you can pass it to other players,and the one who has the bomb when it explodes gets hurts.

I like that idea! :D
Maybe instead of being able to pass the bomb (because that would be extremely difficult), the player who gets hurt should create an explosion like that of an armageddon shield. Also, he should get a "HAS BOMB (seconds left)!" sign over his head, like the "HAS FLAG!" in CTF.

This would result in everybody running away from this player to prevent getting hurt. The player with the bomb should get points for every player the explosion hits (like armageddon), even if the bomb kills himself before it hits the other players.

Maybe the monitor could even be used in single player - you just need to force the player to break the monitor in a part of a level where he has no rings. ;)
 
Last edited:
Or possibly make a whole new game mode out of it.

Not sure what it would be called... So, I'm just gonna call it "Hot Potato" for now. This is how it works: the system randomly picks one person to hold the bomb and they have to pass it before it explodes. The IT player shoots a ring at another player to pass the bomb. It is passed around until it explodes and the person that was caught holding the bomb when time is up is forced to become a spectator for the rest of the match. Rinse, lather, repeat until it comes down to two players and the game ends when there is one person left. I suppose points can be determined by how long you survive.

I personally think that would be a fun new game mode if it was implemented.
 
No, I don't think it will be fun if people spectate for most of the game. Points should generate on the people that do not have the bomb like how players generate points when they are not it in tag. There can also be a big bonus for the people that did not have the bomb when it explodes. After it explodes, a different a random/winning character get the bomb
 
Last edited:
Now that you mention, that sounds a lot better than being forced to spectate and wait for the next round to start. I'm starting to see where you are going with this... Lot better than what I have had in mind.

So, what you are saying, it would go like this:

-Player 1 has the bomb (gets no points until he/she passes it) and once it is passed another player, that person will stop getting points until the bomb passed off to another player.

-Continue doing this until it explodes. The holder of the bomb gets no points while the other players get bonus points. The bomb is then given to another player and the game continues from there.

-Repeat steps one and two until time is up or a player reaches the point limit set.

Hmm... I would also think that the IT person is allowed to shoot while other players just run around making sure they don't get tagged. Yup, just like how it is in Tag.
 
I have a gametype idea."Super Sonic Surviving"
At the start,every one is Super Sonic,the number of rings is set by Host/Admin.
Then they must hit each other, to drain they Ring Limit.If a player reaches 0,he dies,then when being normal,must team with other players to drain the Super Persons Rings.The last who is still Super (or those who were Super at the end of the time limit) wins.
Setrings is auto disabled for this one(apart on the game type settings from network options,but the limit is instead of 9999 rings,999.)
Its like Tag in reversed.
 
Last edited:
Why not flip it over?
The one with the item for the longest time wins. You get points for each second you keep the item. Get shot, and the item goes to another player. Your shots don't affect those without the item.

nice idea but expect to get ganged up. >.< Actually, also change bomb to super for giving the player a better chance with the increased speed and wanting to hold a bomb will not make any sense.

Pyro got what I am saying exactly.

Funny how the bomb monitor turns into game type suggestions. It might not be easy to code new game types. I am worry about the developers.

By the way, what about elimination for race?
 
Improved version of my Sonic 3 Competition mode lap post sprite that I suggested to be used to replace the normal ones in circuit, race, or both. EDIT: NOT TO REPLACE THE ONES IN SINGLE PLAYER GODDAMMIT.
scaled.php


iaza11089611596200.gif
or
iaza11089658918100.gif
 
Last edited:
Why not flip it over?
The one with the item for the longest time wins. You get points for each second you keep the item. Get shot, and the item goes to another player. Your shots don't affect those without the item.

Sounds like Overdrive from Armor Mayhem to me, and I like it. The gametype was pretty fun. The player holding the item was under attack of other players and when he was hit by ring, the item would go to the shooting player. He would be then on the run and so on. The thing is, the player with the item could have doubled his rings (on the start of game, he would have 50). But can't pick up any weapons (monitors could be popped). Surely again think.
 
(Get ready for a very long post.)

From what I have gathered, shields and other powerups are some of the most hardcoded objects in the game. That is why I have an idea for a system that could be used to make custom powerups possible to create and fully customizable.

-----

In this case, the definition of a powerup will be an object with a new flag enabled, called MF_POWERUP, or perhaps MF_SHIELD, which will signify it as a powerup and make the game treat it in a few special ways. In order for a player to collect a custom powerup, there will be a SOC action called A_GivePowerup, which will give the target player a powerup with an object number of Var1. As long as the object has MT_POWERUP checked, the SOC action will spawn the object at the player's location.

A powerup will always exist at the location of the player that it affects, and its hitbox will be the same as theirs. When destroyed, this restriction is lifted, and the shield can move away from the player while in its DeathState.

A powerup also has some special properties that are defined by its object attributes:

--SpawnState determines the state of the powerup when it is spawned around the player. This state should usually be an infinitely long single state or part of a looping pattern of states (if the creator wants a cycle of sprites for the powerup. Green = color-changeable for powerup sprites.) If the creator does not want the powerup to be visible by itself, then the SpawnState(s) should all use SPR_DISS for their sprites. All SpawnStates should have no action unless the powerup is supposed to do something when not activated by the player.

--SpawnHealth defines the amount of hits the powerup can take before it disappears. If set to 0, the powerup will disappear in one hit but the player will still lose their rings, like with the Fire Flower. Cannot be more than 3. The powerup will lose a certain amount of opacity every time damage is taken.

--SeeState is the state the powerup goes into when the player presses spin in mid-air. If ReactionTime is set, the powerup will go into this state at the same time the player activates the second ability.

--SeeSound is likewise the sound that plays when the player presses spin in mid-air.

--ReactionTime determines if the powerup gives the player a second ability that is activated when the player presses spin in mid-air. This follows the ordinary character ability table (0 = thok, 1 = fly, etc.) except for two extra abilities added on: 8 = Armageddon blast and 9 = attract objects with A_AttractChase (which is active all the time), and two abilities taken away: Fly and Glide/Climb, because they are so powerful. (Abilities activated like this, except for the extras, put players in their falling frames.) If the creator wishes the player not to have a special ability, this should be set to 10 or higher. If RaiseState does not have 4 in it (no object trail is left when using special ability) the player's thokitem will be spawned like normal when the secondary Thok or Homing Attack is used, unless ghostthokitem = 0 (solid thokitem), in which case the default thok object will be used regardless of the player's own thokitem and will behave as if ghostthokitem = 1 (intangible thokitem.)

--AttackSound is the sound that plays when the powerup launches a projectile.

--PainState is the state that the powerup goes into when it is damaged, but not destroyed (if it has multiple hits.)

--PainChance determines if the powerup launches a projectile. If it is anything other than 0, that object number (if it has MF_MISSILE checked) is launched from the front of the player when the player presses the fire button, like with the Fire Flower.

--PainSound is the sound the powerup makes when damaged, but not destroyed.

--MeleeState does not determine an actual state, but instead determines the transparency of the powerup (if visible.) 255 = opaque, 0 = invisible.

--MissileState does not determine an actual state, but instead determines if the player is turned a color when the powerup is obtained. When the powerup is destroyed, the player changes back to their normal color. The normal table of 1-15 (1 = cyan, etc.) is used for this effect. If this is set to 15 and the powerup is obtained in Match/CTF, the player's color will not be affected. In general, the color of the player will not be affected in any gametype (like CTF) or situation where the player's color is forced.

--DeathState is the state activated when the powerup is destroyed.

--DeathSound is, likewise, the sound made upon destruction.

--XDeathState does not determine an actual state, but instead what the player is immune to when they obtain the powerup. 1 = fire (MF_FIRE or Damage (Fire) sector type), 2 = electricity (Damage (Electrical) sector type), 4 = water damage (Damage (Water) sector type), 8 = drowning, 16 = space countdown. Combining values combines effects.

--Speed determines the actionspd equivelant of the ReactionTime ability.

--Mass determines the color of the powerup, if its sprites have green in them. Like MissileState, this follows the 1-15 table of colors.

--Damage determines if the player leaves a trail of an object. If it is anything other than 0, that object number will be trailed behind the player, and the angle of the trail object will always be the same as the angle of the player when the trail was created. To prevent the player from being damaged by their own damaging trail, the powerup will prevent the trail object from being tangible until a certain number of tics after spawning.

--ActiveSound determines the sound the powerup makes when it begins to create the trail.

--RaiseState does not determine an actual state, but instead when the trail is created. 1 = when the player is moving, 2 = jumping, 4 = using special ability, 8 = spinning on the ground, 16 = using second ability that the shield gives them. Combining values combines effects. If the trail is spawned while the player is using a ReactionTime-based Thok or Homing Attack (only ReactionTime-based, RaiseState has 16 in it) it will act as the thokitem for that ability, with ghostthokitem set to 0 (non-ghostly). This will mean that is is spawned in place of the normal thok object and appears even when the player is moving at 0 speed (for example, if Speed (secondary ability actionspd) = 0.)

--If the powerup has MF_FIRE checked, it will disappear underwater, emitting a flash like the Attraction Shield.

In order to make the powerup function properly, all states should eventually lead back to the SpawnState or a point in the cycle of ordinary states, to prevent the powerup from disappearing or turning into something else. Having a powerup state lead to the DeathState will cause the powerup to self-destruct upon reaching the state, and having it lead to the PainState will cause the powerup to damage itself. If any state-determining value is set to 0, the powerup will remain in its current state, except in the case of DeathState where it will disappear. Obtaining a custom powerup will override all others.

If the creator wants to create a custom ability for ReactionTime, like Hinote's Flare Jump, the best option would be to set ReactionTime = 0 (secondary thok ability), RaiseState = 16 (causes trail to appear when using secondary ability), and set the trail to the custom ability object. If the player should be stationary when the ability object is spawned, set Speed = 0 (secondary ability actionspd = 0.)

-----

And that's my idea. Anyone think it's a good one?
 
Last edited:
A map header option for the optimal time it takes to complete the level for maximum Time Score at the end in terms of seconds.

For example, MapTime = 300 means that if you complete the level in 5 minutes or less, you get the full 50000 point Time Score at the end of the level. It then scales down normally afterwards. If no maptime is specified in the header, it defaults to 30.

This allows map makers to set a sort of time attack in their level if they want to, and actually making the time bonus applicable in longer levels.
 
Hey, I came up with something amazing for once. Er, in my opinion anyway. So, here it is.

Just recently, I came up with an idea for a gimmick in Starlight Station Zone, a zone in a level pack Badnik and I were working on. It's a small conveyor belt with a horizontally-moving laser that goes the opposite way. However, Appearing/Disappearing FOF makes the FOF effect stay in effect while the FOF is invisible as well. So, I'd have to use a crap load of upper unpegged Move Tagged Sector's Floor and Move Tagged Sector's Ceiling linedef executors. Why not make Not Climbable or some linedef flag on the Appearing/Disappearing FOF line special get rid of the FOF's effect while it's "gone?" However, Block Enemies (or whatever) could be used to keep the FOF's tangibility while it's invisible (Think Flash Black Galaxy from Super Mario Galaxy 2, where the platforms were only visible when lightning struck.) This would be WAY simpler than, say, 100 linedef executor loops.

Also, another idea -- Sonic can barely jump in SRB2, but in Sonic 1, 2, CD, and 3 & Knuckles, he had a large jumpheight of, hmm, I'd say 320 fracunits if it were in SRB2. However, most of the levels would need to be redesigned completely to accomodate this, so I don't see this making it into SRB2.

The super transformation and drowning sounds should be changeable in a character's S_SKIN lump. For example, let's say I made a Shadow wad. Whenever he turned super, he would play DSSHSUPR, which is him shouting "Here I come, you creep!" But it wouldn't make it any less obvious, because of TAB and "(name) IS NOW SUPER" as well as a fast, non-flinching yellow thing flying at you.

Lastly (and this has been discussed between Badnik and me in my server,) weapon freeslots. For example, homing rings. And speaking of homing rings, A_BuzzFly needs an option to chase after the tracer as well, because missiles changing target results in the actor that fired it to get damaged by it.

That is all.

tl;dr: Read anyway. I spent time typing this.
 

Who is viewing this thread (Total: 3, Members: 0, Guests: 3)

Back
Top