May I suggest more capabilities for dialogue? Maybe a way to implement cut scenes as well?
As it is, working with text is really annoying in danmakufu since it is so limited and shows so little at once.
People like me who're story whores really have trouble writing for danmakufu because we have to chop up dialogue so much. So something to help with storytelling is HIGHLY appreciated. Even if it is a selfish request of mine.
... anything in particular? Ability to show larger text boxes would probably help with your high volume of text, I think.
Also, easier 3d. Danmakufu's 3d fails.
Personally, I don't think there's any real "easy" way to do 3D. The simplest way would be to just give the scripter the ability to throw down triangles directly to the renderer, but even that's not particularly easy to use.
Any wants in this area?
Perhaps even an Hp system to. A good thing to remember is we should aim to make this tool universal for danmaku and not just touhou. Touhou will probably be the biggest use, but options to disable is preferred.
An HP system could most likely be handled by this - the main question (just like with the power system debate) is where and how to handle it.
Do we code it into a player script file? Should it be handled in the program itself, and specified by the stage? etc ...
Brain wave: What if we have the player scripts define some arbitrary number of power levels (I'm thinking 0-7, for 8 levels total; I can't imagine anybody realistically needing more than that) and have the enemy/stage script track power however it wants to, and tells the player which power level to execute?
Bonus: not all 8 power levels need be defined by player scripts. You could define, say 0/1/3/5/7, and if a script goes looking for 4, it defaults to the next one down that is defined, 3. (0, of course, would have to be required)
EDIT: Elaborating on this a bit...
Internally, power is just an integer, so all we need is a section of stage scripts to define the thresholds for each power level, and optionally a custom display method (If we leave bombs, score, and whatever else to stage scripts, too, we could lump this all into some kind of "resource management" section). Player scripts can also include their own version of this in case the stage script doesn't really care and omits this part. If neither of them has a power definition, it can default to "always max (7) power" like DMF does now.
Ooooh, I like this idea. With this, a stage/game script could define how to display the power meter, how much power each item gives, etc. It could look something like this:
(EoSD style)
Power_Meter_Max(128); // max power = 128
Power_Meter_Display(Integer); // display power as an integer
Small_Power_Item_Value(1); // small power item gives 1 unit
Large_Power_Item_Value(8); // large power item gives 8 units
Bomb_Cost(0, 1); // Bomb uses 0 power and 1 bomb
Miss_Cost(24); // power lost of miss
Power_Threshold(1, 8); // Set power thresholds
// ...
Power_Threshold(8, 128);
Start_Power(0); // start at zero(MoF style)
Power_Meter_Max(5); // max power = 5
Power_Meter_Display(Decimal); // display as a decimal number
Small_Power_Item_Value(0.05); // small power item gives 0.05
Large_Power_Item_Value(1); // large power item gives 1.00
Bomb_Cost(1, 0); // bomb costs 1.0 power and 0 bombs
Miss_Cost(2);
Power_Threshold(2, 1.0); // Set power thresholds
Power_Threshold(4, 2.0);
Power_Threshold(6, 3.0);
Power_Threshold(8, 4.0);
Start_Power(0); // start at zero(numbers may not be exact)
.. of course, the details would need to be refined, but this would allow us to quickly and easily define many different power systems while maintaining player scripts compatibility. Although, having MoF-style bombs (simple little ring thing) vs. EoSD-style bombs (taste the rainbow, t3h sparkz, etc) would still be left up to the player script.
btw - the zero threshold would always be the lowest value, right? I think we can get away without defining that one at all.
And why would the former require you make a program update to add new systems? 
I think I slightly misinterpreted it, thinking of it as the script selecting one of multiple pre-defined types.
EDIT: forgot to mention - a bit more progress.
Collision DetectionObjects can now trigger scripts when they collide with other objects.
Each object has
two sizes to it - labeled size_1 and size_2 (how original :V). Generally, size_2 will be larger than size_1.
All objects, for collision purposes, are circular (same as it is in Danmakufu, and probably official Touhou too), and the size values give the radius of collision.
Every
object type can define two types of collision scripts -
Collide and
Collide2Collide is for when two objects are within the sum of their size_1 apart.
Collide2 is for when two objects are within the sum of their size_2 apart, and no corresponding
Collide triggers.
For the most part, we can stick to just using
Collide functions, but there are a couple legit uses for
Collide2, including
- Player Collide2 with an enemy bullet = graze, but Collide is miss
- In Danmakufu, you can define a boss as having a different size for the purpose of player shot hit detection as opposed to player collision. This is another Collide2 and Collide situation, in my view.
Furthermore, unlike other event scripts,
Collide and
Collide2 scripts can be defined for collisions with certain other
object types or base types.
For instance, you could define, in one
object type script:
- A Collide for collisions with an object type called "t3h d00d"
- A Collide for collisions with a shot object type called "super bullet"
- A Collide fol collisions with any enemy shot type (which will not trigger when colliding with a "super bullet", since that has its own handler)
Let me know what you guys think about this setup.
