A replacement for Danmakufu?

[Nuclear Cheese]

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:

Code: [Select]

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 like
While 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 curious
A 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 type


Start 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

[Dizzy H. "Muffin" Muffin]

My idea was actually more of a sort of hybrid: you'd define how many levels the player can handle in the player script, and the stage-script would define how many levels we're supporting in this game. If the stage-script has more levels, it doesn't level the player up until it's reached a level that does correspond with a player's level; it the player-script has more levels, it skips levels. The advantage is that, in this respect at least, all player-scripts will be compatible with all stage-scripts. The disadvantage is that the increase would be somewhat uneven if the player's number of levels and the stage's number of levels don't factor well with each other.

Regardless, I still say this should be part of a "default script which comes with the game" rather than making any of it hardcoded, since "hardcoded" by definition means "someone would have to do all sorts of unnecessarily-complex juggling with the scripts if they didn't want to do it the hardcoded way."

[anonl]

• 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

Never seen a language where you have to specify the scoping in your references. Variable shadowing is generally a good thing.

Also:

Code: [Select]

!a = true
!b = !!a
Or will there be no '!' operator?

[Nuclear Cheese]

... I should really be asleep right now, shouldn't I?

My idea was actually more of a sort of hybrid: you'd define how many levels the player can handle in the player script, and the stage-script would define how many levels we're supporting in this game. If the stage-script has more levels, it doesn't level the player up until it's reached a level that does correspond with a player's level; it the player-script has more levels, it skips levels. The advantage is that, in this respect at least, all player-scripts will be compatible with all stage-scripts. The disadvantage is that the increase would be somewhat uneven if the player's number of levels and the stage's number of levels don't factor well with each other.

Regardless, I still say this should be part of a "default script which comes with the game" rather than making any of it hardcoded, since "hardcoded" by definition means "someone would have to do all sorts of unnecessarily-complex juggling with the scripts if they didn't want to do it the hardcoded way."

In a way, this is pretty much what I was saying, albeit with a couple different details.  The way I suggested above also leaves all player scripts usable with all stage scripts - stage scripts controls how where player's power level is within a scale, and the player scripts then uses that value to determine how strong of an attack to fire.

As far as hardcoding things is concerned - if you don't want to use the hard-coded power system, just don't enable it and don't use the default, provided-by-the-program power items.  I do think, though, this system would be flexible enough to handle many variations on the Touhou-style power systems, at least; also, if there is demand other power system templates could be coded/scripted as well.

Never seen a language where you have to specify the scoping in your references. Variable shadowing is generally a good thing.

This is not what script file code will look like

As I mentioned before, mdBase is basically a direct translation of the internal structures used to hold code internally for the Execution Engine.  By the time the script reaches this point, all variable scoping has already been determined, so that the Engine can quickly know where to look for the value.

'Real' scripting languages, for which support will be added in, will not have this oddity.  At least the main one I have in mind won't - if someone else wants to create a higher level script language with this in it, they can, limited only on what structure we have for allowing add-on script languages (Not really sure why they'd want to do that, though).

For reference, in the 'real' scripting language that I have in mind, I'd declare variables something like this:

Code: [Select]

Musuu
Script[mdScript]

// Declare "difficulty" as a global variable - accessible everywhere
global difficulty;

Object_Type Enemy "Pyro-Reimu"
{
   // Declare "counter" as an object variable - accessible from all scripts on this object
   define counter;

   tick
   {
      // "temp" is a local variable - will be only accessible in this tick script
      let temp;
   }   
}
Note: If you want, you can even share global variables between scripts files by giving them the same name - in this way, they function much like Danmakufu's SetCommonData/GetCommonData functions.

Also:

Code: [Select]

!a = true
!b = !!a
Or will there be no '!' operator?

'!' can be whatever the hell the language syntax calls it out for.  You're associating it with the boolean NOT operator, which is what it is in several common languages (C, Java, Danmakufu, and the planned main scripting language for this program, at least).  However, this is not what it is used for in mdBase; rather, it is used (as described above) to declare variable scoping.
Side Note: in BASIC, ! is put at the end of a variable to denote that it is a single-precision floating point value.

Or, if you're asking whether boolean inversion will be included in the capabilities of the engine - of course it will be.



Also, quick little hint for you mdBase crazies (all zero of you, I'm sure :V):
add not only adds numbers, but will also concatenate strings and perform a boolean OR on a pair of booleans.  Furthermore, it's not implemented yet, but add will also be able to add strings with numbers or booleans, which will convert the latter to their string representation and then concatenate the strings.
Similarly, once implemented, mul will not only multiply numbers, but do a boolean AND operation on a pair of booleans.

... as far as higher level languages are concerned, the + operator will probably see some extra functionality out of this with the string concatenation parts, but I still think we'll have the || and && operators for OR and AND (even though they might end up translating down to the same add operation in the end).

[anonl]

As I mentioned before, mdBase is basically a direct translation of the internal structures used to hold code internally for the Execution Engine.  By the time the script reaches this point, all variable scoping has already been determined, so that the Engine can quickly know where to look for the value.

So:

Code: [Select]

script --[compiles_to]--> mdBase --[lex,parse]--> interpreter

That still leaves the question of shadowing

Code: [Select]

var a;
var b;
if (blah) {
    var a; //Is this decl allowed?
    b = a; //How would you compile this line to mdBase?
}


[Dizzy H. "Muffin" Muffin]

In a way, this is pretty much what I was saying, albeit with a couple different details.  The way I suggested above also leaves all player scripts usable with all stage scripts - stage scripts controls how where player's power level is within a scale, and the player scripts then uses that value to determine how strong of an attack to fire.

Hmm. If I'm interpreting this right, this actually works better than the way I had it in some ways.

As far as hardcoding things is concerned - if you don't want to use the hard-coded power system, just don't enable it and don't use the default, provided-by-the-program power items.  I do think, though, this system would be flexible enough to handle many variations on the Touhou-style power systems, at least; also, if there is demand other power system templates could be coded/scripted as well.

Well, one of the things I had a problem with was hardcoding the number of power levels, which would restrict things.

And by "not wanting to use it" I meant "not wanting to use a Touhou-style power system." Granted, with only a few minor adaptations you can make it into ... well, just about any other power system. I mean, you couldn't really do a Suguri-style energy-system with it, but ...

[Helepolis]

[/pirate]
Just about the effects that surround the boss, it's obvious what the spell circle does, first of all.


The ones surrounding the boss are in here. Slightly different in each game, but the middle one kind of blurbs around the middle of the character and the top four bits start off big, then shrink towards the center, creating some sort of weird effect. A red version of the left thing starts flat and grows upwards. All this together makes the aura thing.

Upon analysis of the distorting space, it comes down as an asymmetrical pattern. I'm fairly sure it's a near-perfect circle. The "Border of Spell" circle that surrounds it is just the same graphic but rotating. It's not affected by the distortion. In fact, the only thing affected is the background. Although considering I don't know how the effect works, I don't know if he has a graphic associated with it.

Also, upon more analysis Hele's cut-in script still needs some work :V

Also, the collision detection sounds great.

[pirate]

The distortion/bending/blurring of the background is caused by the middle sprite texture? Though I still don't get how a texture covering the background can cause the background to distort. Or am I being an super idiot here in understanding english.

And you are a bit wrong about the distortion. The red spellcircle causeses the entire distortion. The outer two border circles shrink as the timer goes down. Even when these circles enter the red circle dimension they get distorted.

[Drake]

The ones surrounding the boss are in [image]. Slightly different in each game, but the middle graphic kind of blurbs around the middle of the character and the top four bits start off big and outside the character, then shrink towards the center. The left thing starts flat and grows upwards. All this together makes the aura thing.

Sorry, this was the only part that you needed to pay attention to. I wasn't sure on anything about the distortion.

[Helepolis]

Yes I noticed the aura textures you mentioned. My guess is the following by analysing your story and given textures:

ZUN seems to spawn multiple sprites behind the enemy having a  Y-scaling stretching the texture making it "burn". If you do this with an additive blend and fast sprite spawning it will look like the burning effect ingame I guess.

But I don't want STOP HELEPOLIS so I made my own sprite with a particle flare and mass spawn it in different X-offset.

[Nuclear Cheese]

So:

Code: [Select]

script --[compiles_to]--> mdBase --[lex,parse]--> interpreter


Well, I'd put it more like:

high-level script --[lex,parse,compile,etc]--> mdBase --[translate]--> internal format for interpreter
... but the basic idea is there.

Depending on how things go, though, the high-level script parsing/etc might go straight to the internal format instead.

That still leaves the question of shadowing

Code: [Select]

var a;
var b;
if (blah) {
    var a; //Is this decl allowed?
    b = a; //How would you compile this line to mdBase?
}


mdBase will have no problem handling shadowing between globals, object vars, and locals, since they are stored separately; I will probably disallow this in the high-level scripting language, though, since it leads to code ambiguity.

Is far as shadowing a local with another local, I don't really like that myself, but it could be done if people want.  Internally, the variable name for at least one of them would need to be changed - this would make the parser a bit more complicated, I believe.
What do people think?

Well, one of the things I had a problem with was hardcoding the number of power levels, which would restrict things.

Well, how many levels do you really think you'd need?  We could set a larger number of levels.

Only downside with setting lots of levels is that, say the limit is 65535.  Stage script defines first power items sets level to 255, but the first player script level-up threshold is 256 - player gets screwed out of the first level-up on the first item.
(bit of an over-the-top example, but I think you'll get my point)

And by "not wanting to use it" I meant "not wanting to use a Touhou-style power system." Granted, with only a few minor adaptations you can make it into ... well, just about any other power system. I mean, you couldn't really do a Suguri-style energy-system with it, but ...

Having never played Suguri, I'm not sure what the power system is like there.

Any suggestions for further generalizing the current model we have?




Some quick progress with the Execution Engine tonight; got a bunch more operations implemented, including the rest of basic math and some get/set operations for object properties (angle, speed, sizes, image, player movement).

Honestly, once I add in object creation/deletion commands and get some of the default behaviors implemented, we could have some basic danmaku patterns flying about in the engine.  Main limitation on that, of course, is that we don't yet have a scripting language to write the fun stuff in.  I mean, we have mdBase, but seriously, I wouldn't want to write anything big in it. :V



Oh, and does anyone have experience with ANTLR or a similar program?  I may have asked this before ... it'd be better if someone already knows how to handle it, rather than me beating it with a binary polearm until it follows my instructions.

[Dizzy H. "Muffin" Muffin]

Well, the way Suguri's "power" system works is more like a fighting game: as you attack enemies, a gauge fills up, and you can use it to do super-moves, but your actual attack-power doesn't change or increase. This also replaces bombing.

I've also played an R-Type (I think) fangame in which, depending on what powerup you collected, your actual shot-type changed, but this would probably be best saved for collaboration between player-script and stage-script ...

As for the level-skipping issues, I don't particularly mind that much. So it skips straight from level 0 to level 2. Or, indeed, if the stage's max is 4, it skips from 0 to 64. I think that's a relatively small price to pay for complete-compatibility here ...

[8lue Wizard]

Well, the way Suguri's "power" system works is more like a fighting game: as you attack enemies, a gauge fills up, and you can use it to do super-moves, but your actual attack-power doesn't change or increase. This also replaces bombing.

That would actually be pretty simple to implement. The stage could use a default "always max power" setting, so that it can play around with the power variable without changing your attack level, then have its bomb system tied into power like MoF/SA-style. As for getting power by attacking, well, you usually get score when you destroy shit, why not power, too?

As for the power issue, I haven't seen anything that I like better than how we originally had it. (recap for those that don't want to read back:) The player script has some finite number of level definitions between 0 and whatever we decide for the maximum (I chose 7 arbitrarily, if we want to go to 8 or 10 or whatever, it still works) and the stage script tracks its numbers however the hell it wants to, and calls up the power levels as defined in the player script; if the stage calls a power level that doesn't exist in the player script, it falls down the the next lowest one that is defined.

Also, I haven't worked with DMF's player scripting, so I dunno if it does anything like this, but I'd like to suggest having a whole bunch of optional identifier tags so the stages can do cool things like

Code: [Select]

If (PlayerName == "Reimu") {
<load Satori boss graphic>
} Else {
<load Reimu boss graphic>
}or

Code: [Select]

If (PlayerShoelaceIsUntied) { blahblahblah } Or whatever. (Also, this way, we could have a tag like "PlayerHasSuperPower" that identifies power definitions above whatever we decide as a max. :V No ulterior motives here! >.>;; )

[Stuffman]

I'm trying to think of a system for handling power levels that's going to allow us to standardize our player scripts and have them function correctly despite having different numbers of power levels.

Perhaps power levels should be tracked by percent? i.e. the stage script defines the maximum amount of power you can have, and the player script bases its current power level on how much of a percentage of that maximum they have. Like for instance the player script will say,
if(PowerRatio()>=0.5 && PowerRatio()<0.75){PowerLevel=2;}
where PowerRatio represents the percentage (0.5 being 50%).

Like, say a given stage script has a maximum of 400 power.
PCB-style Reimu has 8 power levels past 0, broken up into 12.5% increments.
SA-style Reimu has 4 power levels past 0, broken into 25% increments.

That way when they're at 200 power, PCB-Reimu will have her level 4 shot and SA-Reimu will have her level 2 shot, which are supposedly equal in effectiveness despite different numbers of levels.

[Byakuren Hijiri]

I just want to say this looks pretty much awesome, I have some problems with Danmakufu so this could be really good.

[Helepolis]

For the sake of Danmakufu and Touhou and everything that is holy, don't make SA system a default. Either make it PCB/IN or UFO.

[Lishy1]

Hey, any chance we may see support for menu scripts?
So far in danmakufu, I know there are different typrs. But none specifically for menus (Is there?)
So I figure, why not a menu type for scripts that will allow us to select character, difficulty, etc.?
In other words, to tweak variables and to load up stage scripts, as well as allowing activation of other scripts once a requirement has been met (Such as extra/phantasm stages)

If I didn't put this in the right words, could a moderator please help? Because custom menus in danmakufu is currently hard as heck to make, and this could really take away from the stress if support is pre-built  :V

[Drake]

It'll be all included by default.

[8lue Wizard]

>.< Blargh. Yet more proof that I shouldn't be allowed to post at 4 AM. Lemme try this again:

I think player scripts should be allowed to define a slew of tags that stage and menu scripts can tweak on. For example, a player script might have a section that looks something like this:

Code: [Select]

AddTag("Reimu")
AddTag("Homing")
AddTag("Human")
AddTag("Solo")
AddTag("Superpower")And then menu scripts can filter the player lists based on tags that are/aren't included, stages can have different things happen depending on what properties the player has, and generally there's a lot more room for creativity.

[Dizzy H. "Muffin" Muffin]

>.< Blargh. Yet more proof that I shouldn't be allowed to post at 4 AM. Lemme try this again:

I think player scripts should be allowed to define a slew of tags that stage and menu scripts can tweak on. For example, a player script might have a section that looks something like this:

Code: [Select]

AddTag("Reimu")
AddTag("Homing")
AddTag("Human")
AddTag("Solo")
AddTag("Superpower")And then menu scripts can filter the player lists based on tags that are/aren't included, stages can have different things happen depending on what properties the player has, and generally there's a lot more room for creativity.

... now that would be badass.

[Nuclear Cheese]

I'm trying to think of a system for handling power levels that's going to allow us to standardize our player scripts and have them function correctly despite having different numbers of power levels.

Perhaps power levels should be tracked by percent? i.e. the stage script defines the maximum amount of power you can have, and the player script bases its current power level on how much of a percentage of that maximum they have. Like for instance the player script will say,
if(PowerRatio()>=0.5 && PowerRatio()<0.75){PowerLevel=2;}
where PowerRatio represents the percentage (0.5 being 50%).

Like, say a given stage script has a maximum of 400 power.
PCB-style Reimu has 8 power levels past 0, broken up into 12.5% increments.
SA-style Reimu has 4 power levels past 0, broken into 25% increments.

That way when they're at 200 power, PCB-Reimu will have her level 4 shot and SA-Reimu will have her level 2 shot, which are supposedly equal in effectiveness despite different numbers of levels.

Am I missing something?  This sounds pretty much like the idea we've been throwing around, except you're using a percentage rather than a set of numbers.

Hey, any chance we may see support for menu scripts?
So far in danmakufu, I know there are different typrs. But none specifically for menus (Is there?)
So I figure, why not a menu type for scripts that will allow us to select character, difficulty, etc.?
In other words, to tweak variables and to load up stage scripts, as well as allowing activation of other scripts once a requirement has been met (Such as extra/phantasm stages)

If I didn't put this in the right words, could a moderator please help? Because custom menus in danmakufu is currently hard as heck to make, and this could really take away from the stress if support is pre-built 

As was discussed some number of pages back, there is a plan to have game scripts, which allow custom menus and such to be scripted, allowing selection of game type, difficulty, etc.

To be fair, though, while I agree that it's more complicated than it needs to be, I don't really think custom menus in Danmakufu are that hard to code.  Just a bit tiring, because of how much script is needed.
(Then again, my opinion might be a bit biased <__<)

>.< Blargh. Yet more proof that I shouldn't be allowed to post at 4 AM. Lemme try this again:

I think player scripts should be allowed to define a slew of tags that stage and menu scripts can tweak on. For example, a player script might have a section that looks something like this:
Code: [Select]
AddTag("Reimu")
AddTag("Homing")
AddTag("Human")
AddTag("Solo")
AddTag("Superpower")
And then menu scripts can filter the player lists based on tags that are/aren't included, stages can have different things happen depending on what properties the player has, and generally there's a lot more room for creativity.

This person is thinking.  I like it.

_{Must. Stop. Hitting modify instead of reply. - Stuffman}

[Chronojet ⚙ Dragon]

Hmmmmmm...
Life piece enabling/disabling, like in Chireiden/Seirensen (enabling) or in Koumakyou/Youyoumu/Eiyashou (disabling)

[Dizzy H. "Muffin" Muffin]

Hmmmmmm...
Life piece enabling/disabling, like in Chireiden/Seirensen (enabling) or in Koumakyou/Youyoumu/Eiyashou (disabling)

Could you be a bit clearer about what you mean?

[Stuffman]

Am I missing something?  This sounds pretty much like the idea we've been throwing around, except you're using a percentage rather than a set of numbers.

Maybe I'm misunderstanding, but it sounded like people were suggesting the stage script would track power thresholds and tell the player script what power level they were supposed to be at? I'm saying the stage script should just tell the player how much of the maximum power they have and the player script should figure out its own power level.

[Chronojet ⚙ Dragon]

Could you be a bit clearer about what you mean?

Um, you know about those purple stars that the enemy characters drop (and even that one fairy in SA stage 4)?

[Kylesky]

Could you be a bit clearer about what you mean?

I think he means the life parts that the SA bosses drop whenever you finish a non-spell or spell card without dying or the ones that the red UFO drops in UFO...

[Chronojet ⚙ Dragon]

I think he means the life parts that the SA bosses drop whenever you finish a non-spell or spell card without dying or the ones that the red UFO drops in UFO...

Yeah, what Kyle said. Also, I don't think it appears in MoF.

[Dizzy H. "Muffin" Muffin]

Ah, I see, yeah.

[Chronojet ⚙ Dragon]

Ah, I see, yeah.

Hmmmm... thanks for reminding me, I just finished an experiment with common data, and this thing that works ALMOST like the life pieces.

[ChaoStar]

Honestly, something that would make me super, super, happy... would be that this version be compatible with Mac OS X, and Linux.

[MCXD]

Honestly, something that would make me super, super, happy... would be that this version be compatible with Mac OS X, and Linux.

Fourth Item: Implementation:

As I mentioned previously, this would be implemented using SDL.NET and OpenGL in C#.  The main advantage of this is that it should be entirely cross-platform portable (without even recompiling!) using Mono.