• Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.

Skullgirls |OT| New age of Heroines

Ravidrath

Member
Really hate to be the annoying one all the times... :p

Is it normal that neither Squigly and the alt colors are free on the EU Store? The 2 DLCs are both priced 5 euros.
Not a big deal, maybe the promotion was meant to be for the US only?

EDIT - Nevermind, just read on Skullgirls' Facebook that it's a known issue, going to be fixed asap.

No, that's not how it was supposed to work and we're already yelling at SCEE about it.
 

Galdelico

Member
I was finding this really odd too (along with the preview videos last week, but no actual available updates).

Opened the game, but saw no sign of updates or an "Encore" in the logo - not sure if I'm supposed to redownload and reinstall, or if it's plain all SG SNAFU when it comes to release/publishing issues...

Yeah, that's it basically.

On XBLA the game will receive a regular title update, which will bring vanilla Skullgirls up to Encore (this update is still TBA though).

On PSN things went differently and what you have to do - assuming you're an eurogaffer - is to go in your account informations thingamajig, open your 'downloaded content' list and look for Skullgirls Encore trial/full game unlock notifications (they should be right on top of the list).
Once you have downloaded and installed both, you can delete original Skullgirls, since Encore works as a whole brand new game (new savedata, restored trophies...).

That said, Squigly and the alt colors are regular DLCs, which will be free for a limited time (Squigly for 3 months, colors for 1 month) as soon as SCEE fixes their mistake (they didn't make the DLCs free yet).

Hope it clears it all up.
 

Beats

Member
I think Mike said on Salty that Big Band could possibly come out on April 1st if things go smoothly with the patch.
 

Ravidrath

Member
What what? Are all consoles going to get him in a week or two, then?!

Possibly, yes.

It's always a crap shoot with submission, because we might not pass on the first try, etc.


I think Mike said on Salty that Big Band could possibly come out on April 1st if things go smoothly with the patch.

That is the SUPER IDEAL NOT GONNA HAPPEN scenario.

It's technically feasible, but really unlikely.
 

shaowebb

Member
Odd question but is there any potential that Lab zero will sell folks licenses to their engine? Lots of us would fall all over ourselves to throw money into their hands for that...even if it is entirely in C# or something without a UI.
 

TheOGB

Banned
First finished frame for Eliza (sort of).
BjTZW3tCMAAMSLc.jpg:large
All of my hnnnnnggg
 

shaowebb

Member
There's some implication that the engine might be opened to the public at some point, but that's probably not for a long time.

Also it's made in C++ and scripting is done in Lua.

Im honestly wondering how hard it'd be to pipeline GGPO into a Unity engine I'm going to be using since it takes C#. I'm not certain though if it'd be anything like getting it to work was for Lab Zero in there engine since I have no idea if it'd be able to compile the same in C# or not.

My kingdom for Lab Zero's skullgirls engine with a UI and commercial license.
 
Im honestly wondering how hard it'd be to pipeline GGPO into a Unity engine I'm going to be using since it takes C#. I'm not certain though if it'd be anything like getting it to work was for Lab Zero in there engine since I have no idea if it'd be able to compile the same in C# or not.

My kingdom for Lab Zero's skullgirls engine with a UI and commercial license.

The main requirements for GGPO to work:

  • The game must be deterministic(should be a given for fighting games); as in if you perform the same action any number of times it should behave exactly the same way each time. This shouldn't be a problem if you're implementing the physics by hand.
  • The relevant parts of the game need to be serializable; as in, the state of the game at any given moment should be capable of being saved as data and/or loaded. You need to be able to save and load the state of the game at the drop of a hat for GGPO to work, and you have to make sure that the frequent use of saving/loading does not impact performance.

IIRC there is a GGPO port in the works for Unity by the Cannon brothers, but I don't know what the status of that is nowadays(it's not publicly advertised AFAIK but you can email them for info).

I believe that some developers have had success implementing rollback-based netcode on their own in Unity as well, but again, I'm not up to date there.
 

Chev

Member
Yeah, specifically, for rollback-based code in c#, there are the following caveats:

-you can't trust floating point operations to be deterministic across different machines in c#. That's something you can force with compiler flags in c++ for example but it c# it's entirely out of your control. So stick to integer operations for math and/or grab a fixed point lib. Fancy physics are probably out unless unity already made them deterministic but for custom fighting game box-based collisions it's fine.
-it follows you can't trust the default random number generator (grab a mersenne twister off the net and make sure the internals are using integer types and you'll be OK) or sin/cos operations for gameplay stuff either (go oldschool on those, precompute tables and use those only)
-fast save/restore done naively will thrash your memory and confuse your GC, so look into c# generic memory pools (basically instead of creating/deleting objects, which is bad for your memory, you keep track of them by class and request/release them instead, so instead of deleting you can just reinit an object and recycle it.)

Beyond that the principles of rollback are reasonably simple but you should make sure every new class you add to gameplay will play fair and be both deterministic and pooled. Dunno about Unity networking and memory management so dunno it it's easy to integrate or not.
 

shaowebb

Member
The main requirements for GGPO to work:

  • The game must be deterministic(should be a given for fighting games); as in if you perform the same action any number of times it should behave exactly the same way each time. This shouldn't be a problem if you're implementing the physics by hand.
  • The relevant parts of the game need to be serializable; as in, the state of the game at any given moment should be capable of being saved as data and/or loaded. You need to be able to save and load the state of the game at the drop of a hat for GGPO to work, and you have to make sure that the frequent use of saving/loading does not impact performance.

IIRC there is a GGPO port in the works for Unity by the Cannon brothers, but I don't know what the status of that is nowadays(it's not publicly advertised AFAIK but you can email them for info).

I believe that some developers have had success implementing rollback-based netcode on their own in Unity as well, but again, I'm not up to date there.

Yeah, specifically, for rollback-based code in c#, there are the following caveats:

-you can't trust floating point operations to be deterministic across different machines in c#. That's something you can force with compiler flags in c++ for example but it c# it's entirely out of your control. So stick to integer operations for math and/or grab a fixed point lib. Fancy physics are probably out unless unity already made them deterministic but for custom fighting game box-based collisions it's fine.
-it follows you can't trust the default random number generator (grab a mersenne twister off the net and make sure the internals are using integer types and you'll be OK) or sin/cos operations for gameplay stuff either (go oldschool on those, precompute tables and use those only)
-fast save/restore done naively will thrash your memory and confuse your GC, so look into c# generic memory pools (basically instead of creating/deleting objects, which is bad for your memory, you keep track of them by class and request/release them instead, so instead of deleting you can just reinit an object and recycle it.)

Beyond that the principles of rollback are reasonably simple but you should make sure every new class you add to gameplay will play fair and be both deterministic and pooled. Dunno about Unity networking and memory management so dunno it it's easy to integrate or not.

Thanks for this...and ouch was this ever some stuff I was hoping to avoid. Floating points (decimals) are pretty much something I could try to avoid mostly with just normal int (integer) stuff so that doesn't sound bad, but making certain everything is saving and loadable and not impacting performance is something I'm betting the current considered prebuilt engines were likely not setup for. Pretty certain that rules out the current build of the Universal Fighting Engine I was considering modding as well as EF 12. Old fashioned Sin Cos stuff , as you put it, shouldn't be unthinkable...just takes awhile making certain I get them vecters setup right. One more thing to test is just a drop in the bucket though so thats just par for the course really. Not gonna kill us. Pretty certain Unity did not make any of its physics deterministic so it'll all need done old school with good old Trig. I'd like to look into those Unity GGPO builds that were mentioned though and talk to the folks involved to hear some of their experiences on the matter of this problem.

I think I could use a skype with Mike Z or something for some deep engine talk for my project. He's been through it all at this point...he'd be the man to really research this from. I'd honestly like a chance to talk to him and Tony Cannon as well since one made GGPO and the other made the first large scale fighter using it. Having the advise of those that tread this sort of path before is a big thing to try and shoot for.
 

Chev

Member
Thanks for this...and ouch was this ever some stuff I was hoping to avoid. Floating points (decimals) are pretty much something I could try to avoid mostly with just normal int (integer) stuff so that doesn't sound bad, but making certain everything is saving and loadable and not impacting performance is something I'm betting the current considered prebuilt engines were likely not setup for.
I'm gonna stop derailing the thread with the programming stuff after that, but here's links to get you started:
http://forum.unity3d.com/threads/34582-Stop-wasting-memory-recycle-your-objects!
http://www.scrapsgame.com/object-pools-in-unity/
http://www.gamasutra.com/blogs/Wend...nagement_for_Unity_Developers_part_3_of_3.php
http://unitygems.com/saving-data-1-remember-me/

Basically you need to set up some pools for all classes that need to be quickly saved/loaded, because that way objects will just be repurposed instead of deleted/recreated, and that makes the process lightning fast. The snapshots themselves are achieved by serializing all the objects you want to preserve to a memory stream and, for loading, returning everything to the pools and deserializing the data back into objects pulled from the pools. I haven't examined the links in detail but seems like you can set up memory pools reasonably easily in Unity so it should be fine.
 
BigBand news ... he's done!

Minus his story mode the current iteration of the Endless Beta will be what's added to the official game / console release in the coming weeks. There's a host of extra balance changes to go along with his inclusion which you can check out ...

Here!

But take some of the highlights anyway.
MikeZ said:
Cerebella
- She is able to reflect projectiles from the 1st frame of Diamond Deflector, rather than having 4f at the start where she can't.
Filia
- Airball on block -5 -> -9.
Fortune (nerfs nerfs nerfs)
- Can cancel Zoom or Headbutt into head's Cat Call recall, only if not blocked. The cancel adds 75f of cooldown (same as Sneeze/Nom add) if the head is not actually recovered by the body.
- Headless Fiber Upper is only throw-invincible, not hit-invincible; assist version keeps full invincibility even if headless. HK Fiber makes opponent land slightly sooner if airblocked.
- Head now always has 15f of cooldown after being hit by the opponent at any time. No more, no less.
Painwheel
- Can unfly by pressing PP while flying; she maintains her forward momentum on unfly, and keeps half momentum backward.
Peacock
- Argus Agony startup invincibility reduced.
Squigly
- H Seria Draugen Punch is invincible.
Valentine
- Mortuary Drop startup 6f faster, dmg 2050->1200, no longer super-cancellable on or after the active frames on whiff. Still super-cancellable on hit.
 
- All Lv1 supers have 1f active frames that are unblockable post-flash...didn't like always-blockable versions, but I do like the shorter hitstop. Air Scalpels still reaction-blockable and counterable even point-blank. Sing->Opera is reaction blockable if not doing anything, but not counterable.
Ugh. I hate this change so much. It completely fucks over Painwheel.
 
Ugh. I hate this change so much. It completely fucks over Painwheel.

I didn't really understand it, post flash unblockable means that you can't reaction block something if you weren't blocking before the flash right? How is that different from the 5-6 frame hitstop shenanigans we had before with post flash stuff?
 
I didn't really understand it, post flash unblockable means that you can't reaction block something if you weren't blocking before the flash right? How is that different from the 5-6 frame hitstop shenanigans we had before with post flash stuff?
I can't answer that, but I remember the last time I played on the Beta Cerebella could do her arm-spin hyper (Gorilla Go Round?) any time I flew over her, and there wasn't anything I could do about it. Total BS. I am reading this as incorporating that as a permanent and awful change. Random hypers should NOT be rewarded!
 

Mr. X

Member
I can't answer that, but I remember the last time I played on the Beta Cerebella could do her arm-spin hyper (Gorilla Go Round?) any time I flew over her, and there wasn't anything I could do about it. Total BS. I am reading this as incorporating that as a permanent and awful change. Random hypers should NOT be rewarded!

Before the 8f hitstop meant that you had to be blocking before the flash and the super would be 8f in before the victim could do anything.

Now it's until the 1st active frame that the victim can't do anything.

Why does anyone still think being able to have a 60f cue (aka the super flash) to tell them to block or mash a counter super was good?

Mike even left the super flash on/off setting in training mode. Without the super flash, they are faster than jabs and you can't react to them, hence the addition of the hitstop to counterbalance the super flash.
 
Before the 8f hitstop meant that you had to be blocking before the flash and the super would be 8f in before the victim could do anything.

Now it's until the 1st active frame that the victim can't do anything.

Why does anyone still think being able to have a 60f cue (aka the super flash) to tell them to block or mash a counter super was good?

Mike even left the super flash on/off setting in training mode. Without the super flash, they are faster than jabs and you can't react to them, hence the addition of the hitstop to counterbalance the super flash.
It is good because random invinsible moves should not be encouraged. It should be a read or a response to an unsafe activity from your opponent.

I don't understand the change, though.
 

remz

Member
It is good because random invinsible moves should not be encouraged. It should be a read or a response to an unsafe activity from your opponent.

I don't understand the change, though.

flying over someone that has a meter is an unsafe activity though
 

Mr. X

Member
It is good because random invinsible moves should not be encouraged. It should be a read or a response to an unsafe activity from your opponent.

I don't understand the change, though.

Everything is super cancelable, even if you make the read, every attack can be cancelled into super and the 2nd super wins more often than not. This turned anything you wanted to punish with Super that wasn't 0f (Showstopper or Fenrir Drive), into a Super countersuper DHC counter DHC until you reached your third or ran out of meter.

The hitstop made it so if you read a dash or a special or a normal thrown out or they were doing something other than blocking from up close, they could not cancel it into something to beat your read if they were hit within this 8f period.

The change is instead of 8f post super flash that you can't move, you can't move until active frame 2 of their super. This keeps the up close, you'll get hit for doing anything that isn't blocking but remedies the supers that traveled far within the old 8f hitstop that were like half screen unblockable.
 
Top Bottom