Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature] Scoring system #61

Closed
Amidweiz opened this issue Oct 18, 2019 · 5 comments
Closed

[Feature] Scoring system #61

Amidweiz opened this issue Oct 18, 2019 · 5 comments
Labels
enhancement New feature or request

Comments

@Amidweiz
Copy link

A possible implementation for this would be to have it contained within the mugen.cfg file under it's own section. It should be able to be utilized by the screenpack and the character itself (possibly with a sysvar of it's own)

[Score]
;Enables the scoring system
enable = 1
;Enables or disables addition of score with multi hit attacks
;such as kung fu man's crouching hard punch
multiHit = 1
;Sets whether the scoring system is counted by interegers or double values
scoreType = integer
;Sets the significant digits and the decimal place of the score counter
;integers will ignore the decimal place.
sigDig = (5,0)
;Enables or disables score rollover. Values will be saved as their true values
;in the save file
rollOver = 1
;normal score values
normalAttack = 50
normalProjectile = 50
normalThrow = 50
;special score values
specialAttack = 100
specialProjectile = 100
specialThrow = 100
;hyper score values
hyperAttack = 500
hyperProjectile = 500
hyperThrow = 500

@Windblade-GR01 Windblade-GR01 added the enhancement New feature or request label Oct 19, 2019
@K4thos
Copy link
Member

K4thos commented Jan 13, 2020

There are 2 approaches that I think we can follow to create a score system:

  1. Leave it all to an external CNS file (for example add004 style common1 that already has scoring) and just get the data stored in a character variable at the end of match (there is already a function that can be used for this purpose - getCharVar).

  2. Follow Amidweiz's suggestion and do the scoring calculations in-engine, using values customizable via DEF.

Not sure what would be better. Either way, I think add004 values could be used in either of these approaches - that system proved to work great in mugen environment, regardless of what characters are used, so instead of coming up with new values and formulas (or reverse-engineering some commercial games), we could just use add004 calculations (if author is not against it)

@K4thos
Copy link
Member

K4thos commented Jan 19, 2020

If someone finds how scoring systems works in some commercial games please post links. Here are my findings so far:

@K4thos
Copy link
Member

K4thos commented Jan 31, 2020

Here are values from Street Fighter Alpha 3:
SFA3.txt

@K4thos
Copy link
Member

K4thos commented Jan 31, 2020

I've finished implementing in-engine support for scores that is flexible enough to allow creating both CVS2 style GP System (float values, same move affecting both attacker's and opponent's score) as well as traditional SF style scores. Values can be assigned directly in HitDef sctrl, scores are remembered between matches, lifebar def file has now [Score] section, where we can adjust how it will be rendered in-game.

But that's stuff mostly for fullgame makers. When the score assignment is missing in HitDef the engine should still provide score calculation similar to above posted commercial implementations. The static values proposed by @Amidweiz is not really a good enough solution, imo. Every single hyper move worth exactly the same score? Light kick worth the same as Hard kick? No relation between combo score and/or hit damage with the score? It definitely ain't enough considering default values will be used by majority of the engine users. Leaderboards results out of static implementation like this would not resemble scores from fighting games at all, regardless of what values we assign in DEF file. It needs additional factors, damage multipliers, variations, time being taken into account etc.

As mentioned above, in order to create default score values system I'd prefer to base calculations on add004 implementation. Either by coding it in engine and externalizing formulas into DEF file parameters or by leaving the default values calculation to common1.zss distributed with engine (in such case the default score value will be assign via new ScoreAdd/TargetScoreAdd sctrls).

Alternatively similar formulas could be designed from scratch, if someone comes up with a new system.

My CNS knowledge is not good enough to figure out how Shiyo Kakuge calculates values in add004, so a help from experienced CNS coder is needed to extract these calculations from common1.cns distributed with add004. Also if anyone knows e-mail address to Shiyo, please let me know.

Scores and leaderboards code is currently on hiatus, since I can't push these changes to github without default customizable scoring working alongside it.

K4thos added a commit to K4thos/Ikemen_GO that referenced this issue Feb 15, 2020
This build is not ready yet for general use due to missing default score calculation. Related posts:
- ikemen-engine/Ikemen-GO#61 (comment)
- http://mugenguild.com/forum/msg.2468026
Once someone contribute above mentioned code (don't count on me writing it) new build will be released with working leaderboards and score counter.
Keep in mind that regressions are to be expected (this is not a stable release)

Changelog:
- changed repository name from Ikemen GO Plus to Ikemen GO
- support for victory music that kicks right after the match's K.O. like in this video: https://www.youtube.com/watch?v=vIrfCs_O47Q&start=42
implemented the same way as all the other music types (stage DEF file parameter, select.def rivals/character/stage parameters, support for more than 1 track for random selection)
- round music extended to victory and result screens if no unique track is assigned (dummy track can be used to force silence)
- new Lua functions for handling text rendering, coded by Wintermourn (@ambonmibable)
- all main.lua modes externalized to separate functions for easier overwriting via external modules
- new mode: Time Attack, inspired by Tekken implementation: https://www.youtube.com/watch?v=7Qcu0PBPxqQ
- new mode: Time Challenge, inspired by SF2 implementation: https://www.youtube.com/watch?v=oPgBb5sjVj0
- new mode: Score Challenge, inspired by SF2 implementation: https://www.youtube.com/watch?v=DE3n0q81S34
In order to use new modes both screenpack and lifebar needs updating (displaying mode item in main menu screen as well as adding missing lifebar parameters in order to render time and score counters)
- screenpack: support for all mugen [Continue Screen] parameters
- screenpack: fixed typos (looser => loser)
- screenpack: changed default fadein times to 0 for continue and results screens in motif.lua
- screenpack: support for mugen 'winquote.textwrap = w' parameter (auto wrapping text at the end of line)
- screenpack / storyboard: changed _length parameter to wrap text when reaching set pixel width rather than after exceeding fixed amount of symbols (this way individual symbol width no longer matter)
- lifebar: added missing [Round] section background icon parameters (bg0)
- lifebar: re-implemented match end [Round] section events
- lifebar: first attack flag and counter counting  (not used yet, will be enabled once support for other damage/combo messages is in)
- lifebar: final round anim/text/sound support
- lifebar: time rendering (timer enabled by default in Time Attack and Time Challenge modes)
- lifebar: score rendering (score counter enabled by default in modes like Arcade, Versus, Score Challenge etc.)
- lifebar: match number rendering (enabled by default in modes like Survival, VS 100 Kumite, Boss Rush)
- lifebar: AI level rendering (support for both numerical and percentage value)
- lifebar: [Mode] section that allows to render lifebar element that will show up only in particular mode (e.g. Game Over text during demo etc.)
- better ESC support in start.lua arcade and arranged loops
- fixed "Here comes a new challenger" crash when exiting it via ESC
- game data saved into save/stats.json (for now just a few stats crucial to new modes, more general ones will be implemented in future). These stats are ready for leaderboards rendering (sorted depending on values important for particular modes, capped etc.)
- new triggers: p5name-p8name, more win types recognized by Win trigger, new triggers related to detecting score, time, and combo damage
- new state controllers: scoreAdd, targetScoreAdd, roundTimeAdd, roundTimeSet
- sys.JoystickConfig => sys.joystickConfig (for consistency sake, all sys vars start lowercased)
- Continue screen, Victory screen, Results screen are now rendered on top of stage and character (related Go <-> Lua functions: charChangeState, lastMatchClearance, lastMatchClear, lastMatchRender, drawCharSprite)
- victory portraits now rendered directly from loaded characters instead of pre-loading them at game start (old implementation removed from source code)
- moved continue.snd and continue.sff to external screenpack repository (no longer used by default by the engine, all parameters related to animated continue screen still work of course)
- footer engine version and infobox link are read from releaseconf.xml by default (if not replaced by parameters in screenpack def file)
- missing save/config.json entries automatically written on startup instead of crashing the engine
- updated Readme_Features.md
@Tabris666
Copy link

The only way to make a scoring system is using common1.cns there is no other way to get it
this is a way it was implemented in old winmugen https://mugenguild.com/forum/PHPSESSID.b8gp27p4fhosd3bdhvrh1cht14/topics/score-system-147166.0.html

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants