Trigonometry Wars 3 Redux: The Revengeoning (v1.0 released!)

A place for people with an interest in developing new shmups.
Post Reply
User avatar
Giest118
Posts: 1042
Joined: Wed May 02, 2012 1:50 am

Trigonometry Wars 3 Redux: The Revengeoning (v1.0 released!)

Post by Giest118 »

I decided to remake Trigonometry Wars 3 because. At the moment I have one stage, all three ships, and configurable controls fully implemented.

VIDEO OF CURRENT PROGRESS

My intentions for this game:
* Five stages. The original Trigonometry Wars 3 had 9 stages, but I'm condensing it down to 5 stages because 5 stages is way better.
* Rip off DoDonPachi even harder than the original game did by using the Get Point system. I'll be adding other things to it later, but for the moment it's basically this.
* No difficulty select because fuck that.
* It will be generally better than Trigonometry Wars 3.
* Some bosses that were in the original game will be demoted to midbosses due to less stages.

I was hoping to have input replays in this game, but it seems like SOMETHING doesn't want that to work; probably some deeply-rooted thing in Game Maker where it processes key presses in a different order from how I was reading them from the replay file, or some shit. Basically the movement was always off by a pixel. I varied certain bullet patterns based on the player's position (intending to emulate the way arcade shmups randomize based on input) but because the replay was always off by a frame or a pixel or something, everything messed up. So that kinda blows.

So I will be posting here sometimes to update on my progress. I may even post some playable demos to try avoiding that stupid crap I had with My Little Pegasus where I released the full game and it was riddled with stupid bugs that I totally should have noticed. :V


UPDATE: v1.0 released!
DOWNLOAD HERE

Navigate menus with the arrow keys, Enter or Z selects. Note that if you change the controls via the Config menu, it also affects what key selects stuff in the menus. You can find everything else you need to know in the incredibly helpful How To Play screen.

Changes since the demo:
* Three more stages added
* Boss practice added
* Point items have a third state: If your Get Point value is maxed AND you're currently using a hyper, they will be worth even more points based on the level of your hyper.
* Several interface changes, including a gauge showing how long your current hyper will last, and floating hyper level indicators, ala SaiDaiOuJou.
* Stage 2 boss's final attack has been changed a bit
* Hyper rank has been added: basically, while a hyper is happening, enemies are more aggressive and crap. It does not increase the more you use hypers, but it's worth noting that with higher-level hypers, you will need to deal with the harder bullet patterns for a longer time.
* Numerous bug fixes
* Probably some bugs introduced maybe
* Bomb stock resets with each stage
* Breaking a chain now results in a 50% Hit reduction and a 75% Get Point reduction, as opposed to setting both values to zero
* Grazing during a hyper gives you points, proportional to the level of the hyper. It's not that much, but it's another thing for score-whores to consider. :V
* (can't remember if this was in the first version or not) Grazing bullets will slow down the chain gauge, stalling it a bit

Changes between v0.8 and v1.0:
* Second loop added
* End of a hyper now gives a screen clear
* All enemies now drop point items
* Popcorn enemies drop two point items instead of one when killed with the shot
* Most likely fixed that fucking slowdown issue that some people have had with the configurable controls
* Graze hitbox is now visible
* Stage 5 boss's third attack now much easier
* Small point items now only add a little bit to your chain gauge (though a screen-clear will most likely fill it)
* Using a hyper now completely fills the chain gauge
* Changed the way chain breaks work on bosses; it now works the same way as it does everywhere else, but bosses instantly fill the chain gauge when lasered, so if you need to stop lasering for whatever reason, you have a second of slack time to resume your chain; this also applies to midbosses
* The square enemies in stage 5 who launch yellow swirl attacks now give a partial screen-clear on death
* All shots and lasers are now slightly faded, mostly to address the clusterfucking that occurs in high-level hypers

... And possibly a few other changes I forgot.
Yes, being able to select any stage and boss from the get-go is intentional. :V

UPDATE: Posted a new version with a couple of fixes.
* Added an option to turn off gamepad controls altogether in case you would prefer to use XPadder or something
* Hopefully fixed the issue where the game would crash when playing a lot of sounds on Windows 8 machines
* Fixed a retarded bug that I cannot believe I didn't see earlier and indeed am glad nobody discovered


A note for anyone who experiences slowdown for no discernible reason (mostly Cagar): It's possible that the configurable control code is somehow interacting badly with your computer. For this reason, the config menu also has an option to turn the configurable controls off (locking them to the defaults).

I am interested in criticism regarding mechanics, difficulty, and (obviously) bugs. Let me know what you think works well or doesn't work well.
Last edited by Giest118 on Thu Mar 14, 2013 12:34 am, edited 4 times in total.
User avatar
Lord Satori
Posts: 2061
Joined: Thu Jul 26, 2012 5:39 pm

Re: Trigonometry Wars 3 Redux: The Revengeoning

Post by Lord Satori »

infinite continues
BryanM wrote:You're trapped in a haunted house. There's a ghost. It wants to eat your friends and have sex with your cat. When forced to decide between the lives of your friends and the chastity of your kitty, you choose the cat.
Meseki
Posts: 129
Joined: Fri Mar 30, 2012 11:36 pm

Re: Trigonometry Wars 3 Redux: The Revengeoning

Post by Meseki »

I haven't played the original (and didn't play enough of 4 to remember anything significant), but I like that the GP value is limited; it means a chain break close to the middle of the stage (or after a midboss or something) might not necessarily destroy your score, depending on the circumstances (and the difference large point items make).

As for replays, I don't know your method of recording/playback, but you may be getting messed up by the order of events, especially if you're using Begin/End Step events or Alarms. As stated in the Game Maker 8.0 manual:
  • Begin step events
  • Alarm events
  • Keyboard, Key press, and Key release events
  • Mouse events
  • Normal step events
  • (now all instances are set to their new positions)
  • Collision events
  • End step events
  • Draw events


The create, destroy, and other events are performed when the corresponding things happen.
User avatar
Giest118
Posts: 1042
Joined: Wed May 02, 2012 1:50 am

Re: Trigonometry Wars 3 Redux: The Revengeoning

Post by Giest118 »

Lord Satori wrote:infinite continues
There will be continues. :V




Meseki: I was recording the input by, at any given step, checking whether a button was pressed, and then writing either 1 or 0 to a text file (the replay file) based on whether the button was pressed. When playing back, I made the ship object do things based on numbers read from the replay file. I did the playback by having the ship object move/fire/whatever during its Step event. The only thing I could think of was that I ordered the actions wrong in the step event itself. Either that or I shouldn't have been using the Step event. Either way, it was off by a very small amount that was causing desync. I did try putting this stuff in the Begin and End step events just to test, and just for fun, I also tried intentionally delaying playback by a frame and, in a separate experiment, jumping the playback forward by a frame just to see if that did anything favorable. No such luck I'm afraid.
Meseki
Posts: 129
Joined: Fri Mar 30, 2012 11:36 pm

Re: Trigonometry Wars 3 Redux: The Revengeoning

Post by Meseki »

Giest118 wrote:Meseki: I was recording the input by, at any given step, checking whether a button was pressed, and then writing either 1 or 0 to a text file (the replay file) based on whether the button was pressed. When playing back, I made the ship object do things based on numbers read from the replay file. I did the playback by having the ship object move/fire/whatever during its Step event. The only thing I could think of was that I ordered the actions wrong in the step event itself. Either that or I shouldn't have been using the Step event. Either way, it was off by a very small amount that was causing desync. I did try putting this stuff in the Begin and End step events just to test, and just for fun, I also tried intentionally delaying playback by a frame and, in a separate experiment, jumping the playback forward by a frame just to see if that did anything favorable. No such luck I'm afraid.
For the input related commands, first take note of what's being held (I assume default input events aren't being used), then record (or playback) input, then have the rest of the Step event (including moving the object, etc.). It's very important that input is played back before movement is done.
User avatar
BPzeBanshee
Posts: 4857
Joined: Sun Feb 08, 2009 3:59 am

Re: Trigonometry Wars 3 Redux: The Revengeoning

Post by BPzeBanshee »

Oh lord, the headache of input replays.

I don't know how you're doing it but in GMOSSE I use queues. I also use a different inputs system so looking at it probably wouldn't help.

The general idea is though, a separate input replay controller object loads a file which consist of a queue for each input. The actual input controller is disabled and the variables that are normally changed based on your keyboard input are then actually whatever the head of the queue is at the current time.

For actually recording an input replay file, the replay controller just puts whatever the input variables are set to into a queue during gameplay, and then at the end of a game each queue is saved to file as one line thanks to the function that turns the queue into a string.

As far as I've tested (no one's been helpful for me in that regard) this more or less works for everything except Swordfish which for unexplained reasons is not consistent. I gave up trying to get it to work a while ago.
User avatar
n0rtygames
Posts: 1001
Joined: Thu Mar 15, 2012 11:46 pm
Contact:

Re: Trigonometry Wars 3 Redux: The Revengeoning

Post by n0rtygames »

BPzeBanshee wrote: For actually recording an input replay file, the replay controller just puts whatever the input variables are set to into a queue during gameplay, and then at the end of a game each queue is saved to file as one line thanks to the function that turns the queue into a string.
This is exactly how Skyravens records input replays. Player inputs are simply an object containing a bunch of boolean values that correspond to the buttons the player has pressed in this frame. A list of this type of object also exists, each frame - these inputs are added to the list. Sadly I've not been able to push that over to Chronoblast because of memory limitations and to be honest the thought of sharing input replays over XBLIG is quite simply bats**t mental. But I'm working on that tech slowly ;)

One thing to be very mindful of when dealing with input replays is that you HAVE to impose limitations on how long the game can run for or you will theoretically eventually run out of memory. So have invisible timers on your bosses so that if the player goes for a specified amount of time without having damaged the boss, or just the fight itself - it automatically takes enough damage to knock it in to its next phase, or flat out destroy it. Give them a survivor bonus for this and then turn your bug in to a feature ;-)

Here's a bit of pseudo c# code off the top of my head that should help demonstrate the concept:

Code: Select all

public class FrameInputs()
{
     public bool mbLeftPressed = false;
     public bool mbUpPressed = false;
     public bool mbDownPressed = false;
     public bool mbRightPressed = false;
     public bool mbFirePressed = false;
     public bool mbBombPressed = false;
}

public class MyPlayerInputSystem()
{
     List<FrameInputs> maReplayInputs = new List<FrameInputs>();

     bool mbReplayMode = false;
     int mnFrame = 0;

     public void Update(float lrTimeStep)
     {
           bool lbLeft = false;
           bool lbRight = false;
           bool lbDown = false;
           bool lbUp = false;
           bool lbFire = false;
           bool lbBomb = false;

           if (mbReplayMode)
           {
                if (mnFrame >= maReplayInputs.Count)
                      return; // We should probably stop when we exceed the replay size!
           
                // Since we're in replay mode...     
                lbLeft = maReplayInputs[mnFrame].mbLeftPressed;
                lbRight = maReplayInputs[mnFrame].mbRightPressed;
                lbDown = maReplayInputs[mnFrame].mbDownPressed;
                lbUp = maReplayInputs[mnFrame].mbUpPressed;
                lbBomb = maReplayInputs[mnFrame].mbBombPressed;
                lbFire = maReplayInputs[mnFrame].mbFirePressed;
           }
           else
           {
                 // We're not in replay mode, let's store these inputs instead
                 if (Key.Down) lbLeft = true;
                 if (Key.Up) lbUp = true;
                 if (Key.Right) lbRight = true;
                 if (Key.Left) lbLeft = true;
                 if (Key.Z) lbFire = true;
                 if (Key.X) lbBomb = true;

                 FrameInputs thisframe =  new FrameInputs();
                 thisFrame.mbLeftPressed = lbLeft;
                 thisFrame.mbRightPressed = lbRight;
                 thisFrame.mbDownPressed = lbDown;
                 thisFrame.mbUpPressed = lbUp;
                 thisFrame.mbBombPressed = lbBomb;
                 thisFrame.mbFirePressed = lbFire;
                 
                 // Finally add this new piece of frame data to the list
                 maFrameInputs.Add(thisFrame);
           }

           if (lbLeft) ship.MoveLeft(); 
           if (lbRight) ship.MoveRight();   // etc etc etc etc

           mnFrame++;
     }
}
At the end of the level, you'll probably want to save this to a file then clear the list and reset values for the next stage - I recommend splitting your run in to multiple temporary files per level and caching the filenames of each one - then on the gameover/complete screen if the player chooses to save a replay, create permanent versions of these files in the users save folder and a master file that tells your game which replay file to read data from on each level :)

Code above is horrible, but demonstrates the concept fairly well.

Phew.
facebook: Facebook
User avatar
Giest118
Posts: 1042
Joined: Wed May 02, 2012 1:50 am

Re: Trigonometry Wars 3 Redux: The Revengeoning

Post by Giest118 »

Here's the thing: that's pretty much what I did. The process shouldn't be any more complicated than saving the player's inputs and then replicating those inputs when playing the replay, but for some reason, something was out of sync. The reason probably has to do with how I handle diagonal movement. For example, if I'm pressing right, I need to check if I'm also pressing up so I can move at the correct diagonal speed. I think something about this is what's causing my problems; the order in which I checked the move directions in my step event may be different than the order in which Game Maker checks the keyboard arrow events. I could re-order them in my step event, but then the question is whether Game Maker checks joystick direction events in a different order than the keyboard arrow events. It's all very ass-backwards and weird to explain.

Thanks though. I may come back to this replay thing at some point. :V
User avatar
Giest118
Posts: 1042
Joined: Wed May 02, 2012 1:50 am

Re: Trigonometry Wars 3 Redux: The Revengeoning

Post by Giest118 »

Random update that is barely noteworthy, or perhaps very noteworthy depending on how big a deal music is to you.

I (understandably) get a lot of comments (but not necessarily complaints) about how I use the shit out of Cave music in my games. It made sense for me to do so for My Little Pegasus (since "Kizuna DoPonyPachi" was half of the title and the mechanics were ripped straight out of two of Cave's games), but that doesn't really give me an excuse for TW4, which had a little more than 50% Cave music, and the mechanics were all its own except for maybe the laser.

So I've decided to cut down on my use of Cave music to these two tracks: The boss music (because SaiDaiOuJou boss music is best boss music) and the stage 4 theme. For everything else I'll be stealing from Cyber-Rainforce like every other doujin shmup developer. Actually that's a bit of an exaggeration. For example, the stage 3 theme will be this: SHADOWRUN

For those wondering why I don't make my own ost or find someone to do it for me:
* I have no musical talent
* I'm a bit too nice to subject someone else to the torture of trying to make music that would meet my unreasonable standards

So there you have it.

Meanwhile, I'm starting work on stage 2 because that needs to happen.
User avatar
n0rtygames
Posts: 1001
Joined: Thu Mar 15, 2012 11:46 pm
Contact:

Re: Trigonometry Wars 3 Redux: The Revengeoning

Post by n0rtygames »

Giest118 wrote:Here's the thing: that's pretty much what I did. The process shouldn't be any more complicated than saving the player's inputs and then replicating those inputs when playing the replay, but for some reason, something was out of sync. The reason probably has to do with how I handle diagonal movement. For example, if I'm pressing right, I need to check if I'm also pressing up so I can move at the correct diagonal speed. I think something about this is what's causing my problems; the order in which I checked the move directions in my step event may be different than the order in which Game Maker checks the keyboard arrow events. I could re-order them in my step event, but then the question is whether Game Maker checks joystick direction events in a different order than the keyboard arrow events. It's all very ass-backwards and weird to explain.

Thanks though. I may come back to this replay thing at some point. :V
Okay, so thinking about this - it sounds like you might be doing your control systems a bit mental. Would you mind sharing how you're actually moving the ship at the moment?

What I'm doing is this.... and jesus christ I haven't looked at this section of code in months. Urgh!

Code: Select all

                int lnAxisPressed = 0;
                float lrDiagMoveAmount = 0.6f;
                float lrMoveAmount = 1.0f;

                if (lbIsLeftPressed || lbIsRightPressed) lnAxisPressed++;
                if (lbIsUpPressed || lbIsDownPressed) lnAxisPressed++;

                // Diagonal speed fix
                if (lnAxisPressed > 1) lrMoveAmount = lrDiagMoveAmount;   // This is the important line

                // Handle Movement
                if (lbIsLeftPressed)
                {
                    this.Ship.DesiredDirection.X = -lrMoveAmount;
                    this.Ship.UpdateSideGuns(new Vector2(-1, -1));
                }
                else if (lbIsRightPressed)
                {
                    this.Ship.DesiredDirection.X = lrMoveAmount;
                    this.Ship.UpdateSideGuns(new Vector2(1, -1));
                }

                if (lbIsUpPressed) this.Ship.DesiredDirection.Y = -lrMoveAmount;
                else if (lbIsDownPressed) this.Ship.DesiredDirection.Y = lrMoveAmount;
What you might be finding is that if you're dividing your movement amount by a float and the result is quite a few decimal places - that you get weird unexpected results. This isn't a problem for me as Chronoblast is written for one specific platform in mind so the hardware is all the same and I'd say it's going to be a 99.9999999999999% accurate simulation across two devices. Floats aren't exactly reliable.
facebook: Facebook
User avatar
Giest118
Posts: 1042
Joined: Wed May 02, 2012 1:50 am

Re: Trigonometry Wars 3 Redux: The Revengeoning

Post by Giest118 »

It's kind of a moot point by now since, as time goes on, input replays seem less and less practical for this game.

First, some context:
In V1.5 of Trigonometry Wars 4, I added the ability to configure the controls. This negated the need for keyboard events. Later, Cagar informed me that he was experiencing horrendous lag that was not present in earlier versions of the game. I tested and concluded that somehow, the way Game Maker checks for keyboard/gamepad inputs was interacting poorly with his computer for some reason. I also concluded that other people might have the same issue.

Thus, in TW3Redux, I am including the ability to turn off configurable controls and use the regular keyboard events. The problem is that there is no keyboard event for "pressing up and right at the same time" and such. Therefore, if I wanted to do speed correction when the player is moving diagonally, I had to do a bunch of checks: For example, when pressing right, it's necessary to check if the player is also pressing up.

My theory is that this fucked up input replays in the following way: Game Maker checks keyboard events in some order at every frame. I don't know what this order is. Thus, when reading the replays, it's possible that I was doing all of the movement in the wrong order, which was causing diagonal movement to be a frame out of sync, which caused the input replays to die.

"Now, wait," you might be thinking, "why not mess about the order until it works?" And my answer is: I also use joystick events, which might be read in a different order to the way the keyboard events are. Essentially, my efforts to make the game playable for everyone are making input replays less and less possible, because I have no way, in the replay, to determine if the player was using a keyboard or a joystick, especially since a player could (if they so desired) switch between the two at any moment.


tl;dr My game is too awesome for input replays to handle.
User avatar
trap15
Posts: 7835
Joined: Mon Aug 31, 2009 4:13 am
Location: 東京都杉並区
Contact:

Re: Trigonometry Wars 3 Redux: The Revengeoning

Post by trap15 »

More like tl;dr game maker blows
@trap0xf | daifukkat.su/blog | scores | FIRE LANCER
<S.Yagawa> I like the challenge of "doing the impossible" with older hardware, and pushing it as far as it can go.
User avatar
Giest118
Posts: 1042
Joined: Wed May 02, 2012 1:50 am

Re: Trigonometry Wars 3 Redux: The Revengeoning

Post by Giest118 »

trap15 wrote:More like tl;dr game maker blows
NO ARGUMENT HERE

And yet I keep using it.
User avatar
n0rtygames
Posts: 1001
Joined: Thu Mar 15, 2012 11:46 pm
Contact:

Re: Trigonometry Wars 3 Redux: The Revengeoning

Post by n0rtygames »

Okay, so being logical about this - I can see this sort of thing happening with what basically amounts to bad code. I'm not saying that YOUR code is bad - more likely that the way Game Maker is handling it as you've suggested.

I've never actually touched Game Maker in my life. How does a keyboard event actually look (in code)?

See, I could cause a bit of a performance hit in XNA by doing this:

I could royally fuck things up by doing this

Code: Select all

for (i = 0; i < Players.Length; i++)
{
    bool lbFirePressed = GamePad.GetState((PlayerIndex)i).IsButtonDown(Buttons.A);
    bool lbBombPressed = GamePad.GetState((PlayerIndex)i).IsButtonDown(Buttons.B);
}
Where as THIS is much more preferable - but certainly not perfect

Code: Select all

for (i = 0; i < Players.Length; i++)
{
    GamePadState lState = GamePad.GetState((PlayerIndex)i);

    bool lbIsFirePressed = lState.IsButtonDown(Buttons.A);
    bool lbIsBombPressed = lState.IsButtonDown(Buttons.B);
}
Where as THIS is even more preferable - because I'm not creating and throwing away a new object every loop

Code: Select all

/* Somewhere in your class where this remains permanent and isn't local to any particular method. */

GamePadState[] lStates = new GamePadState[Players.Length];
for (i = 0; i < Players.Length; i++)
{
    lStates[i] = GamePad.GetState((PlayerIndex)i);

    bool lbIsFirePressed = lStates[i].IsButtonDown(Buttons.A);
    bool lbIsBombPressed = lStates[i].IsButtonDown(Buttons.B);
}
In the first example, I'm telling the framework to go off - poll the joypad and then return its results for every single button.

In the latter, I'm simply getting all of the buttons once per player and then working off a set of values already returned to me once this frame. There's no sense in polling the device multiple times per frame.

If what you're saying is that Game Maker goes off and populates the input data whenever it feels like, then I can see that causing all sorts of problems - so I doubt that's the case. What if you're half way through a method and then GameMaker decides its time to update the inputs. Can you imagine that in something like Street Fighter? It would actually make people turn in to murderers.

tl;dr - your game does look pretty awesome actually - but there has to be a way to beat Game Maker in to submission.
facebook: Facebook
User avatar
Giest118
Posts: 1042
Joined: Wed May 02, 2012 1:50 am

Re: Trigonometry Wars 3 Redux: The Revengeoning

Post by Giest118 »

n0rtygames wrote:I've never actually touched Game Maker in my life. How does a keyboard event actually look (in code)?
That's kind of the thing. It's not "code" as you use the term.

Game Maker uses a predominantly visual interface. "Events" are basically conditions under which an object should do things. For example, a "Step" event contains a list of things for an object to do at every frame. There is a command (execute code) that can do slightly more low-level scripts that look more like the code you would be used to, but the fact remains that whatever you put in an event will not happen unless the event is triggered.

Keyboard events are basically "do this during every frame that the corresponding key is pressed." There is no way to combine these events, so there is no "up and right are both pressed" event. You CAN define your own events, but not without the keyboard/gamepad checks that I previously said can cause problems on certain machines.

So, if I want to make a check to see if both up and right are pressed, I basically need to store this information in variables that are changed in those events. Then, in the Keyboard Up event, I check the variable that says whether Keyboard Right is also pressed, and vice versa. And this is where things get sticky; I know there must be an order in which these events are processed per-frame, which would affect the order in which my conditions are triggered, thus affecting when the "diagonal movement" actually kicks in. I could compensate for this by messing about with the movement order when I actually try to play the replay, but that leads into the problem of the joystick events, which are listed in a different order in the event list, and thus makes me wonder if the directions on a joystick are processed in the same order as the directions on a keyboard. If they are, that means I would necessarily have to let input replays made with a keyboard or with a joystick go out of sync.

This probably all sounds clusterfucky and shitty, but that's only because it is. I never even had to think about it this deeply before I tried doing input replays, and that's pretty much the appeal of Game Maker; you don't have to worry about anything at a lower level than making objects do things... UNTIL YOU TRY DOING THIS SHIT I GUESS LOL

I guess if I was desperate enough for input replays to work, I could forego the speed correction for diagonal movement entirely, but I think making sure the game plays right is more important. *shrug*
User avatar
BPzeBanshee
Posts: 4857
Joined: Sun Feb 08, 2009 3:59 am

Re: Trigonometry Wars 3 Redux: The Revengeoning

Post by BPzeBanshee »

I've never actually touched Game Maker in my life. How does a keyboard event actually look (in code)?
Correct syntax, simplified GML code from what I do in GMOSSE:

Code: Select all

/* scr_inputs script, called in Step */
global.jleft = 0;
global.jright = 0; // reset variables etc
if keyboard_check(vk_left) then global.jleft = 1; // left
if keyboard_check(vk_up) then global.jup = 1; // up

Code: Select all

/* Player object Begin Step event*/
if (global.jleft = 1) && (global.jup = 0)  then x -= shipspeed; // left
if (global.jleft = 1) && (global.jup = 1) // left-up
   {
   x -= diag_shipspeed;
   y -= diag_shipspeed;
   }

// etc, not using Boolean even though I could because nimitz made it first and why bother
I don't actually make the diagonal speed any different by choice but the system for it is nonetheless there. This works for me (although my use of Step vs Begin Step is probably a leftover from old tests) and input replays with the exception of Swordfish work (I've tested many times with the others with consistent runs, and no one's bothered to test themselves and prove me wrong yet).

I'm interested to hear whether Cagar has 'unplayable lag' issues with GMOSSE as well which has used this system since MK-IV. If it's truly a GM-specific issue and not a result of programmer's differences then I would think it should lag just as badly using both keyboard_check and keyboard_check_direct. If it works without issue, however, I'm more inclined to look at the diagonal speed variables as placing objects at decimal-point-based x/y positions would indeed cause issues.
User avatar
n0rtygames
Posts: 1001
Joined: Thu Mar 15, 2012 11:46 pm
Contact:

Re: Trigonometry Wars 3 Redux: The Revengeoning

Post by n0rtygames »

BPzeBanshee wrote: I don't actually make the diagonal speed any different by choice but the system for it is nonetheless there. This works for me (although my use of Step vs Begin Step is probably a leftover from old tests) and input replays with the exception of Swordfish work (I've tested many times with the others with consistent runs, and no one's bothered to test themselves and prove me wrong yet).

I'm interested to hear whether Cagar has 'unplayable lag' issues with GMOSSE as well which has used this system since MK-IV. If it's truly a GM-specific issue and not a result of programmer's differences then I would think it should lag just as badly using both keyboard_check and keyboard_check_direct. If it works without issue, however, I'm more inclined to look at the diagonal speed variables as placing objects at decimal-point-based x/y positions would indeed cause issues.
By the sounds of it, the input replays and lag experienced are two seperate issues. From what you've posted there, it really does sound like there's an awful lot going on in a single update with too many requests to poll devices as I suggested at. Though if Giest is using a more visual approach, we'll never be able to debug that...:-)

A decimal point based location shouldn't be a huge issue depending on how many decimal points we're talking about. For instance, 0.6 is pretty damned easy to keep a hold of. However if you're doing something like:

ship.Move(speed * Game.TimeStep) -- you're going to end up with weird and unpredictable results.
facebook: Facebook
User avatar
Giest118
Posts: 1042
Joined: Wed May 02, 2012 1:50 am

Re: Trigonometry Wars 3 Redux: The Revengeoning

Post by Giest118 »

So I've finally finished with that pseudo-Touhou fangame that I decided to actually finish, which means I can go back to THE REVENGEONING.

Someone recently suggested SDOJ Hypers as the mechanic to add on to what's in the game currently. I can totally do that, but I have another thing to consider: Both the original TW3 and TW4 incorporated grazing into their mechanics somehow. In TW3 it added to your chain, and in TW4 it charged up the Graze Shield. So, I'll need to figure out how to incorporate it into this game. Perhaps it can help charge the hypers?
User avatar
n0rtygames
Posts: 1001
Joined: Thu Mar 15, 2012 11:46 pm
Contact:

Re: Trigonometry Wars 3 Redux: The Revengeoning

Post by n0rtygames »

Might make hypers really easy to gain... or so small for balance reasons that it becomes almost worthless. At least that's been my experience of converting graze to hyper.. Why not let grazing charge in hyper for a Crimson Clover style double breaker?

coming up with an idea is 1000 times easier than implementing it

: )
facebook: Facebook
User avatar
Giest118
Posts: 1042
Joined: Wed May 02, 2012 1:50 am

Re: Trigonometry Wars 3 Redux: The Revengeoning

Post by Giest118 »

n0rtygames wrote:Might make hypers really easy to gain... or so small for balance reasons that it becomes almost worthless. At least that's been my experience of converting graze to hyper.. Why not let grazing charge in hyper for a Crimson Clover style double breaker?
So, graze enough mid-hyper and you get a super hyper?

That's just crazy enough to be fucking glorious.
User avatar
trap15
Posts: 7835
Joined: Mon Aug 31, 2009 4:13 am
Location: 東京都杉並区
Contact:

Re: Trigonometry Wars 3 Redux: The Revengeoning

Post by trap15 »

Grazing for hyper reminds me of DDP2's graze for bombs mode. Which was hilariously abusable.
@trap0xf | daifukkat.su/blog | scores | FIRE LANCER
<S.Yagawa> I like the challenge of "doing the impossible" with older hardware, and pushing it as far as it can go.
User avatar
Giest118
Posts: 1042
Joined: Wed May 02, 2012 1:50 am

Re: Trigonometry Wars 3 Redux: The Revengeoning

Post by Giest118 »

I have a question about that. Are those grazing mechanics (that trap15 and n0rtygames mentioned) based on number of bullets grazed or time spent grazing bullets? In TW4 I kept it pretty well balanced (ie, minimal abusability) by making it the latter.
User avatar
trap15
Posts: 7835
Joined: Mon Aug 31, 2009 4:13 am
Location: 東京都杉並区
Contact:

Re: Trigonometry Wars 3 Redux: The Revengeoning

Post by trap15 »

It was a combination for DDP2. Every X frames grazing a single bullet added to the charge. So grazing X frames on two bullets adds 2 to the charge instead of 1. I think the least abusable way would be to allow only a single 'graze' per bullet, to prevent you from milking slower moving bullets. Of course, if your game is more danmaku, being time spent grazing without stacking per-bullet would probably be less broken.

You'll probably just want to try out both and see how it fits.
@trap0xf | daifukkat.su/blog | scores | FIRE LANCER
<S.Yagawa> I like the challenge of "doing the impossible" with older hardware, and pushing it as far as it can go.
User avatar
ciox
Posts: 1001
Joined: Sun Feb 12, 2012 5:29 pm
Location: Romania

Re: Trigonometry Wars 3 Redux: The Revengeoning

Post by ciox »

To me, it kinda defeats the point of grazing if there's no difference whether you sit at the outer edge of a pattern or in the thick of it, so I'd go with each grazed bullet making a difference but they are made permanently or temporarily un-grazeable after being grazed.
Last edited by ciox on Fri Nov 09, 2012 9:45 am, edited 1 time in total.
User avatar
railslave
Posts: 505
Joined: Fri Oct 26, 2012 8:38 pm
Location: Abertillery , South Wales

Re: Trigonometry Wars 3 Redux: The Revengeoning

Post by railslave »

Hi i enjoyed that , it was educational for someone new to these kinds of games :) nice and easy to get into as well, which i think is an achievement in itself.

Could do with vastly improved graphics, those dont realy do it justice at all. And if there meant to be a certain style or whatever i dont think they realy pull it off to the point of being appealing.

Again, Well done on the learning curve!

i read on youtube that graphics isn't your thing ... id love to design some stuff for you if you want!! (im learning graphics techs atm but im naturally an artistic person ) would be amazing to help if your interested
"When I get my hands on some money
I'll kiss it's green skin
And I'll ask it's dirty face
"Where the hell have you been?" - Michael Gira (Swans)
Cagar
Posts: 2234
Joined: Fri Nov 25, 2011 5:30 pm

Re: Trigonometry Wars 3 Redux: The Revengeoning

Post by Cagar »

I'd post my shitty pink rose garden score if there was a hi-scores thread
User avatar
n0rtygames
Posts: 1001
Joined: Thu Mar 15, 2012 11:46 pm
Contact:

Re: Trigonometry Wars 3 Redux: The Revengeoning

Post by n0rtygames »

Time spent grazing is, as Trap said - hilariously abusable.

I've got grazing code in CB but to be honest, I'm not really a *huge* fan of grazing mechanics as a core focus - so I stripped it out. Best left to games that have more ingenious bullet patterns and center around this sort of thing - such as Touhou etc. My way was basically if a bullet comes in to your graze region - that's a successful graze. It gets flagged as having grazed you, so you can't trigger it again. A bullet just maintains two bools (one for each player).

It would be trivial to put it back in and add a few extra points here and there, but I guess I just want to focus more on shooting things with a few intense barrages of enemy fire as opposed to pretty bullet patterns. My bullets travel a little faster than is ordinary as that's just the way I want to go with the game.

Where as for your game, you've stuck to the slower moving bullets in dense and more attractive formations. It might work better for you than it did for me. As Trap said - you have to experiment really :)

Hope that helps!
facebook: Facebook
User avatar
Giest118
Posts: 1042
Joined: Wed May 02, 2012 1:50 am

Re: Trigonometry Wars 3 Redux: The Revengeoning

Post by Giest118 »

n0rtygames wrote:Time spent grazing is, as Trap said - hilariously abusable.
Only if being next to several bullets at once stacks; in TW4 it didn't, and I was satisfied with the result.

To those suggesting that making each bullet grazeable would work better: I used this exact sort of mechanic in the Extra mode of PRGT, and you could break the absolute living SHIT out of the game by, while you're invincible from taking a hit, going right on top of the boss and grazing EVERY bullet they spit out. Now, the result is very fun. But it's very abusable.

Making it based ONLY on time spent next to at least one bullet at least puts a definite cap on how much you can get out of the mechanic at any point in the game, while still being risk/reward-y by making it so you need to be next to bullets in order to get hypers faster.
railslave wrote: Hi i enjoyed that , it was educational for someone new to these kinds of games, nice and easy to get into as well, which i think is an achievement in itself.

Could do with vastly improved graphics, those dont realy do it justice at all. And if there meant to be a certain style or whatever i dont think they realy pull it off to the point of being appealing.

Again, Well done on the learning curve!

i read on youtube that graphics isn't your thing ... id love to design some stuff for you if you want!! (im learning graphics techs atm but im naturally an artistic person ) would be amazing to help if your interested
I appreciate the offer, but I do prefer doing things myself. It means I don't have to rely on anyone else to get stuff done, and I have complete control over the sizes of sprites and such. Also, the Trigonometry Wars series has always used this basic sort of graphic design; it'd be weird if I suddenly changed it. :V
User avatar
n0rtygames
Posts: 1001
Joined: Thu Mar 15, 2012 11:46 pm
Contact:

Re: Trigonometry Wars 3 Redux: The Revengeoning

Post by n0rtygames »

Giest118 wrote: Making it based ONLY on time spent next to at least one bullet at least puts a definite cap on how much you can get out of the mechanic at any point in the game, while still being risk/reward-y by making it so you need to be next to bullets in order to get hypers faster.
Image

A sudden herp derp moment has been felt. I've always been making the bullets keep track of whether or not they're grazing the player currently. What I should have done was basically have the ship declare this to be false before running graze checks... then true if any bullet was grazing. This is so obvious, that I should be taken outside and shot.

Then you only get one condition - are we grazing bullets or not? Where as I was working with it stacking.

Yeah.. don't ask me for advice. I'm stupid. :-)
facebook: Facebook
User avatar
ciox
Posts: 1001
Joined: Sun Feb 12, 2012 5:29 pm
Location: Romania

Re: Trigonometry Wars 3 Redux: The Revengeoning

Post by ciox »

There's so many ways to go about this though, like simply capping the reward you get from buzzing many bullets at the source (ex: even if you get a super hyper very quickly from doing that, you have to use it before you get another, and while it's active you also can't get another super hyper, so you can't chain hypers/invincibility and graze infinitely)

In Psyvariar buzzing boatloads of bullets from the source is the whole point since you don't get anything overpowered for doing it, just 10 points per graze and some very brief invincibility while you're doing it.
Post Reply