Here's a thought: instead of a mandatory specific number of levels, have the player-script specify a "max power" and (maybe/optionally) a "minimum power" like how UFO has 1.00 as its minimum, and when the stage-script calls for a power-level change, round it to the nearest available fraction-of-the-max-level in the player-script. So, let's say, if a stage-script was expecting 0-7, and the player-script had 1-4, then:
When the stage-script asks for: | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
... the player-script returns: | 1 | 1 | 2 | 2 | 3 | 3 | 4 | 4 |
Also, maybe some sort of multiplier for how much point-items are worth, like how in SA, Marisa-Alice gains a level for every 12 point-items, but everyone else gains a level every 20 point-items.
In a way you don't really need a min power; Its probably better to just keep power as a variable unsigned byte int (considering UFO). I think its easier to just to set a game var "number of power items to max" and player script to assign "X number of levels" so all the game needs to do is "game p items to max" divided by "X levels per player" to find how many items it takes to level up. The whole thing with 1.00 starting power, or decimals for that matter is pure aesthetics, it can be probably be handled in the game ui ? taking "x powerups to level up" divided by say ... 20. and you'll have MoF style output. divided by 100 + 1.00 and you got UFO.
Its still problematic should someone want to create a non straight forward power up system though; like if you use different item power up items that does different things. The assumption on that I guess is if someone is going to use a very unique power up system for their game, its going to be restricted to their own custom player scripts anyway. Leaving default power up handling like so, for the one shot stage creations.
The way we were discussing before is that we'd set a "max power" value, as well as the amount each power item gives.
MoF, for instance:
Max = 5
Small_Item = 0.05
Large_Item = 1;Then, you'd set the thresholds for each of a set number of "power levels" - each level corresponding to a possible level that the player script can use.
MoF again:
Level_2_Threshold = 1
Level_4_Threshold = 2
Level_6_Threshold = 3
Level_8_Threshold = 4(assuming level 8 is the highest - remember that MoF your firepower maxes out at 4.0 ... unless I'm remembering wrong).
With this, you're player script would be at power level 0 for [0,1), power level 2 for [1,2), power level 4 for [2, 3), power level 6 for [3, 4), and power level 8 (max) for [4, 5].
As far as displaying integers vs. decimals, we could just have a command that lets the script set how many decimal places to show; same with starting power amount.
This is basically what Muffin describes, except it sounds to me like Muffin was saying to define it in the player script, while my approach defines it in the stage script (save for the part of actually deciding on and firing player shots, which need to be in the player script). I think this is better, since then a game script will have a consistent power system for all player types.
(... please let me know if I'm misinterpreting what you're saying
)
The powerup multiplier idea is good, though. Didn't know about that myself, haven't played anything beyon MoF to date (work, fighting game tournaments, laziness, etc >__> ).
Supporting 2+ cutins on each side of a talk event.
(Lyrica's scenario in Touhou Kaeidzuka)
I'll make a note of that.
v.v If you must. Though I'd still like to see the hard max a notch or two above the conventional max.
Well, we don't have any max defined currently. Not sure what you were considering the "conventional max". I just chose 8 for giving examples 'cause it's a nice, round number (in binary, anyways :V).
A bit of code progress tonight, mainly focusing on scripts:
I've started to add the base framework for reading in script files. Right now, it's limited to reading in a language that I call
mdBase, which is basically a text transliteration of the Execution Engine commands - it looks much like assembly code and, in general, isn't intended for large-scale usable, but rather to test things in the Engine.
As a sample, here's the script file the program is currently set to read in:
Musuu
Script[mdBase]
/ A thing
Object_Type Effect A thing
/ initialize script
Script initialize
/ Initialize the global a
add #a, 1.0, 1.5
/ Set our size
obj_get_id !tmp
obj_set_size !tmp, 100, 150
/ tick script
Script tick
/ change the value of the global a
sub #a, #a, 0.1
/ collide1
Script collide Effect
/ change the value of the global a
add #a, #a, 100000
/ collide2
Script collide2 A thing
/ change the value of the global a
add #a, #a, 100
/ Player type
Object_Type Player A player
Script initialize
obj_get_id !tmp
obj_set_size !tmp, 5.0, 7.0
obj_set_image !tmp, "test1.png"
/ Pyro-Reimu :V
Object_Type Enemy Pyro Reimu
/ initialize script
Script initialize
obj_get_id !tmp
obj_set_size !tmp, 5, 8
obj_set_image !tmp, "reimu1.png"
(Emphasis added for those of you skimming:) This is not what script file code will look likeWhile you
could write script files in this, there will be a much better way of doing it once I get the script parser in place.
While it probably isn't important to dwell on the details of these scripts (since they're not really 'complete' anyways - there's still several things in the program code), there are a few things to note about the file:
- First line: Musuu
this marks the file as a Musuu no Danmaku script file (much like #TouhouDanmakufu) - Second line: Script[mdBase]
this tells the program that this script file is written in mdBase
other script languages will have their name in this field instead - Every line after the first two are processed by the specific interpreter/parser for the selected script language
- For mdBase, every line starting with a / is a comment
- In case you're wondering, this was a lot easier for me to implement than a full parser; the incredibly simple syntax makes it easy to interpret with my own code.
For the curiousA crash-course in
mdBase:
Start the definition of an
Object Type with a line that reads:
Object_Type <base type> <name>... where
<base type> is one of the object base types (
Effect,
Enemy,
Player, etc.) and
<name> is the name of the new
object typeStart the definition of a script for the current
object type with a line:
Script <script type>... where
<script type> is the type of script, such as
initialize or
tick. For
collide and
collide2 scripts, put the name of the
object type or object base type that the collision script is for
For each command in a script, have a line as follows:
<command> <args>... where
<command> is the command mnemonic for the command to execute, and
<args> is a comma separated list of arguments, in the following format:
- Boolean literal: true or false
- Numeric literal: just the number - 5.0, 65536
- String literal: string in doublequotes - "A string"
- Local variable reference: !variable_name
- Object variable reference: @variable_name
- Global variable reference: #variable_name
Local variables are only for the currently-running function. Object variables persist for each object, and can be accessed by all functions running for that object. Global variables are defined globally, and can be accessed anywhere.
Commands seen in the above sample:
- add - adds the second and third argument, and stores the result in the first
- sub - subtracts the third argument from the second, and stores the result in the first
- obj_get_id - gets the current object's ID number, and stores it in the specified variable
- obj_set_size - sets the sizes of the object whose ID is given in the first argument to the values of the second and third arguments.
- obj_set_img - sets the image of the object whose ID is the first argument to the second argument
Once again,
mdBase isn't intended for writing full scripts, but rather for testing the functionality of the Execution Engine.
(of course, if you're
crazy enough, you
can write full scripts in this. Emphasis on
crazy.)
One thing to note is that, depending on how my adventures in learning ANTLR go, the parser for the real (better) scripting language(s) may end up just converting those scripts to
mdBase internally, rather than going straight to the internal script data structures. I still need to figure a few things out with ANTLR, so we'll have to see how that goes; anyone here know about using ANTLR already?
EDIT: Yay page seven