Author Topic: A replacement for Danmakufu?  (Read 254277 times)

Re: A replacement for Danmakufu?
« Reply #90 on: September 18, 2009, 06:30:55 AM »
I think I kinda like "Infinite Danmaku" itself. It could grow on me. ``

Helepolis

  • Charisma!
  • *
  • O-ojousama!?
Re: A replacement for Danmakufu?
« Reply #91 on: September 18, 2009, 11:20:16 AM »
MUGEN is indeed horrible NC. Bad reputation :V though still funny to play now and then.

Drake

  • *
Re: A replacement for Danmakufu?
« Reply #92 on: September 18, 2009, 01:19:31 PM »
Just keep it as Musuu no Danmaku and be on with it lol.

A Colorful Calculating Creative and Cuddly Crafty Callipygous Clever Commander
- original art by Aiけん | ウサホリ -

Garlyle

  • I can't brain today
  • I have the dumb
    • Tormod Plays Games
Re: A replacement for Danmakufu?
« Reply #93 on: September 18, 2009, 06:06:58 PM »
Quote
I don't have muchany experience with coding player scripts in Danmakufu, so (I might have asked this already ... my brain is slightly fried at the moment) it would be helpful if people point out any particular issues they've had in Danmakufu.

Easier bomb coding dear lord that was my least favourite part.  Also, optional to disable/not disable regular shots during bomb.  (Alternatively, potential custom bomb system, should we opt for MoF/SA setup)

Also, homing code aides.

DarkslimeZ

  • A REIMU SLIME APPEARED.
  • COMMAND?
    • Eternal Temporality
Re: A replacement for Danmakufu?
« Reply #94 on: September 18, 2009, 09:01:42 PM »
Quote
I don't have muchany experience with coding player scripts in Danmakufu, so (I might have asked this already ... my brain is slightly fried at the moment) it would be helpful if people point out any particular issues they've had in Danmakufu.

Easier bomb coding dear lord that was my least favourite part.  Also, optional to disable/not disable regular shots during bomb.  (Alternatively, potential custom bomb system, should we opt for MoF/SA setup)

Also, homing code aides.

Unfortunately, if we want any sort of flexibility with bombs, it has to be complex. It seems that more flexibility = more complexity, and vice versa.

[14:12] <~BoredTSO> you need to have enough fissile material in a certain density to reach supercriticality

CK Crash

  • boozer
Re: A replacement for Danmakufu?
« Reply #95 on: September 18, 2009, 10:53:00 PM »
Also, optional to disable/not disable regular shots during bomb.  (Alternatively, potential custom bomb system, should we opt for MoF/SA setup)
ForbidShot(true/false); The bomb coding in Danmakufu is a bit difficult, especially with bombs technically being separate scripts, with you having to redeclare all the variables for your image paths and such. However, it's also very flexible once you understand how it works.

I do agree with you on post-IN stuff being available. 1-up and bomb pieces, and maybe even a power system. The player would have something like EnablePower(6/10/11/12);. 6 (EoSD) would make it a value from 0 to 128, 10 (MoF) would make it 0.00 to 5.00 and attach the bomb system to it, 11 (SA) would be the same but only go up to 4.00, and 12 (UFO) would go from 1.00 to 4.00 and make the bombs separate again. The CreateItem function would ignore spawning power items if the player didn't have power enabled, and bomb items if MoF or SA settings.

Re: A replacement for Danmakufu?
« Reply #96 on: September 19, 2009, 12:41:28 AM »
I do agree with you on post-IN stuff being available. 1-up and bomb pieces, and maybe even a power system. The player would have something like EnablePower(6/10/11/12)
Methinks you should go the "complexity" route of allowing the users to script that kind of thing themselves, so that e.g. we don't have to rework the EnablePower function and whatnot every time a new Touhou game is released. Much better to do a generic "item" superclass, and make the code flexible enough to do whatever you want when you collect a given instantiation.

8lue Wizard

  • Cobalt Magician
  • (Apparently)
Re: A replacement for Danmakufu?
« Reply #97 on: September 19, 2009, 12:45:30 AM »
*digs through back pages* On the subject of power/bombs, this needs to be rementioned:

Suggestion: rather than hardcoding things like power, bosses' health-meters, dying, etc., you include a bunch of "default scripts" which handle things like that, so that if someone doesn't want to use it or wants to use something different (i.e. an Imperishable Night-style game where one type of item is a powerup and another is a point-item for the human-character, and it's the other way around for the youkai-character; PCB-style "this boss has X number of health-meters" versus MoF-style versus EoSD-style; a health-meter for the player instead of a number of lives), they don't have to use scripts to fight an uphill battle against the hardcode.

The existing systems are great as a base, but it really should be flexible enough to handle just about anything you could think up. I say default scripts for 6/10/12 style, but paramaterize them so you can go from 10-style to 11-style as simply as "setMaxPower(400);", tweak power thresholds for 6-style and whatnot. And then if you wanna do something wacky, you can do a custom script and everyone's happy.

Nuclear Cheese

  • Relax and enjoy the danmaku.
    • My homepage
Re: A replacement for Danmakufu?
« Reply #98 on: September 19, 2009, 01:04:38 AM »
MUGEN is indeed horrible NC. Bad reputation :V though still funny to play now and then.

In theory its an awesome idea.  It tends to get ruined, though, by people (a) not putting effort into their creations, and (b) going for the arms race of who can create the most broken shit ever to exist.



I think I kinda like "Infinite Danmaku" itself. It could grow on me. ``

Just keep it as Musuu no Danmaku and be on with it lol.

無数の弾幕 ~ Infinite Danmaku

?



Easier bomb coding dear lord that was my least favourite part.  Also, optional to disable/not disable regular shots during bomb.  (Alternatively, potential custom bomb system, should we opt for MoF/SA setup)

Also, homing code aides.

Unfortunately, if we want any sort of flexibility with bombs, it has to be complex. It seems that more flexibility = more complexity, and vice versa.

Darkslime is right.  Due to the wide variety of what a 'bomb' can entail (homing orbs of colorful doom, giant freakin' laser beams, time-freezing all shots on screen, etc), it's hard to simplify bomb creation without limiting functionality unnecessarily.

The way I envision bombs working right now does involve scripting an object type for the bomb attack objects - I think it'd be hard to get away without doing so (at least without making your player script unnecesasrily complicated).

Again, this is one of the areas I don't have much knowledge from Danmakufu in, so I'm trying to evaluate the options.



I do agree with you on post-IN stuff being available. 1-up and bomb pieces, and maybe even a power system. The player would have something like EnablePower(6/10/11/12);. 6 (EoSD) would make it a value from 0 to 128, 10 (MoF) would make it 0.00 to 5.00 and attach the bomb system to it, 11 (SA) would be the same but only go up to 4.00, and 12 (UFO) would go from 1.00 to 4.00 and make the bombs separate again. The CreateItem function would ignore spawning power items if the player didn't have power enabled, and bomb items if MoF or SA settings.

Methinks you should go the "complexity" route of allowing the users to script that kind of thing themselves, so that e.g. we don't have to rework the EnablePower function and whatnot every time a new Touhou game is released. Much better to do a generic "item" superclass, and make the code flexible enough to do whatever you want when you collect a given instantiation.

*digs through back pages* On the subject of power/bombs, this needs to be rementioned:

The existing systems are great as a base, but it really should be flexible enough to handle just about anything you could think up. I say default scripts for 6/10/12 style, but paramaterize them so you can go from 10-style to 11-style as simply as "setMaxPower(400);", tweak power thresholds for 6-style and whatnot. And then if you wanna do something wacky, you can do a custom script and everyone's happy.

I can forsee some issues with just about any approach we take on this - here's some of my thoughts:

Power system is defined by the script being played
+ (Hopefully) Ensures better balance for all player types
- Will probably run into issues if a player type doesn't support the selected power system properly.  Can be mitigated to an extent.
- Will require program updates to add in new systems

Power system is defined by the player script (Onthenet's version)
+ Some handling of power system will be greatly simplified on the script side, since it will be built into the program
- Balance issues, especially if a boss/stage/game is specifically tailored to a particular power system
- Will require program updates to add in new systems

Power system is defined by the player script (KimikoMuffin's version)
+ Highly flexible, can add in new types without program updates
- Balance issues, especially if a boss/stage/game is specifically tailored to a particular power system
- Scripters will have to handle everything in their player scripts


... opinions?
to quote Naut:
"I can see the background, there are too many safespots."
:V

Re: A replacement for Danmakufu?
« Reply #99 on: September 19, 2009, 01:39:31 AM »
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.

Also, easier 3d. Danmakufu's 3d fails.

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.

As for a power system, I'll suggest Onthenet's. If we can manage to get the updates simple, it's worth it.
« Last Edit: September 19, 2009, 01:43:34 AM by Lishy »

8lue Wizard

  • Cobalt Magician
  • (Apparently)
Re: A replacement for Danmakufu?
« Reply #100 on: September 19, 2009, 01:44:10 AM »
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.
« Last Edit: September 19, 2009, 02:30:11 AM by Blue_Wolf »

Re: A replacement for Danmakufu?
« Reply #101 on: September 19, 2009, 02:49:10 AM »
Eh, I'm biased in favor of being able to make a complete game, with everything made specifically to fit with everything else.

That said, I think my suggestion could actually work for "script being played" or "player script." And why would the former require you make a program update to add new systems? :o

Nuclear Cheese

  • Relax and enjoy the danmaku.
    • My homepage
Re: A replacement for Danmakufu?
« Reply #102 on: September 19, 2009, 06:15:00 AM »
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)
Code: [Select]
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)
Code: [Select]
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? :o

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 Detection
Objects 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 Collide2

Collide 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.
« Last Edit: September 19, 2009, 06:29:42 AM by Nuclear Cheese »
to quote Naut:
"I can see the background, there are too many safespots."
:V

Re: A replacement for Danmakufu?
« Reply #103 on: September 19, 2009, 08:10:07 AM »
And why would the former require you make a program update to add new systems? :o

I think I slightly misinterpreted it, thinking of it as the script selecting one of multiple pre-defined types. :-\
That's what Onthenet was suggesting, but it's not intrinsic to "the level/pattern script handles it."

I think that anything which doesn't directly affect what the player is able to do (HP, maximum bomb capacity, etc) should be handled by the "level" script. While it's true that you won't be able to do things like giving different players different HP or whatever, I'd say this is a relatively small price to pay for being able to use any player script.

As for 3D ... hmm. Feel free to count this as one cent instead of two, since I have almost no experience working directly with the nitty-gritty details of how 3D stuff actually works (nor have I used Danmakufu's before), but ... I'm thinking, using polygons (rectangles?) in 3D space. Give each polygon width, height, texture, (tint, maybe?), X Y Z coordinates of the center, pitch/yaw/roll rotation, and ... that should handle a lot of things. Script camera-control, "fog" (i.e. the way things fade into a blank color in the distance), background image/color ...

I think that bombs are best served with, "When player uses a bomb, run player's bomb-script" and let the bomb script do anything any other script can.

Garlyle

  • I can't brain today
  • I have the dumb
    • Tormod Plays Games
Re: A replacement for Danmakufu?
« Reply #104 on: September 19, 2009, 02:21:01 PM »
I'll clarify what I found complex about bomb scripts: You have to use effect objects to create any visible effects during the bombs.  Offering a much simpler method that can use normal draw routines or standard bullet graphics drawing would be wonderful.  Yeah, keeping complexity is nice, but... srsly.

Also, I remember testing on Danmakufu and finding that although you could shoot as normal, damage added from the shots was auto-reduced... but I may have come upon an error there.

Re: A replacement for Danmakufu?
« Reply #105 on: September 19, 2009, 02:40:57 PM »
I think that bombs are best served with, "When player uses a bomb, run player's bomb-script" and let the bomb script do anything any other script can.

Always nice to see people who haven't used Danmakufu's Player Scripting functions... My my.

I'll clarify what I found complex about bomb scripts: You have to use effect objects to create any visible effects during the bombs.  Offering a much simpler method that can use normal draw routines or standard bullet graphics drawing would be wonderful.  Yeah, keeping complexity is nice, but... srsly.

Once you know how to use effect objects you'll they are infinately better than the shitty "draw from the center" style DrawGraphic functions, despite the steep learning curve.


Aaaand NC mentioned the coordinate system... Why do we have 0 pointing up? Why are we screwing up the degree system even further? Do you know how often I have to change my work on math exams because I keep using clockwise rotation...? Just keep it like it should be, I have no problem using 270 as down. It's how everybody is taught. Also, (0,0) -> bottom left. Why was this ever changed...

In addition to that, before you try to handle the program's player scripting functions, you might want to go through Stuffman's Player Script tutorial and see how it's done for yourself. There's not real easy way to explain how batshit player scripting is other than actually seeing for yourself.

Re: A replacement for Danmakufu?
« Reply #106 on: September 19, 2009, 03:54:43 PM »
I think that bombs are best served with, "When player uses a bomb, run player's bomb-script" and let the bomb script do anything any other script can.

Always nice to see people who haven't used Danmakufu's Player Scripting functions... My my.
I haven't used Danmakufu at all. Care to elaborate, since you'd apparently rather taunt me for my ignorance than try to correct it? ;P

As for the "draw-vs-effects," I submit that, again, having it do whatever you want and not requiring that the player do anything.

Also, I realized a problem with my Brilliant Plan for 3D: it would be extremely difficult to make, say, an octagonal pillar, because rotating a rectangle 45 degrees, to fit with anything else you'd need use the Pythagorean theorem to give it a helpful width. So, instead, how about, um, a "triangle" function where you specify the X,Y,Z coordinates of each corner (and the texture and all details about that), and a "rectangle/rhombus" function that where you specify the X,Y,Z coordinates of three of the coordinates, and extrapolate the fourth from that. Really, I think that no matter what we do, unless Nuclear Cheese is prepared to code an entire 3D GUI, there is no easy way of doing 3D.

Garlyle

  • I can't brain today
  • I have the dumb
    • Tormod Plays Games
Re: A replacement for Danmakufu?
« Reply #107 on: September 19, 2009, 04:52:57 PM »
Quote
Once you know how to use effect objects you'll they are infinately better than the shitty "draw from the center" style DrawGraphic functions, despite the steep learning curve.

Yeah, but you don't have the choice.  And that's where the problem lies - what commands you could use were limited by script 'type' in Danmakufu.

Re: A replacement for Danmakufu?
« Reply #108 on: September 19, 2009, 07:59:16 PM »
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?

That distorted area around the bosses of SA/UFO would be nice, if you could do that.

Cabble

  • Ask me about my Cat.
  • Not unwilling to shank you.
Re: A replacement for Danmakufu?
« Reply #109 on: September 19, 2009, 09:46:11 PM »
This sounds simply amazing. Have you already started?

If so, then what language are you using to program it?
I had a teacher who used to play radiohead during class once.

ONCE.

Nuclear Cheese

  • Relax and enjoy the danmaku.
    • My homepage
Re: A replacement for Danmakufu?
« Reply #110 on: September 20, 2009, 12:32:55 AM »
I think that anything which doesn't directly affect what the player is able to do (HP, maximum bomb capacity, etc) should be handled by the "level" script. While it's true that you won't be able to do things like giving different players different HP or whatever, I'd say this is a relatively small price to pay for being able to use any player script.

That is pretty much what I was suggesting, based on Blue_Wolf's suggestion.  The player scripts define how the player behaves, while the stage/game scripts define the power system, bombs/lives setup, etc. (Of course, with default settings for when the script doesn't define them).



As for 3D ... hmm. Feel free to count this as one cent instead of two, since I have almost no experience working directly with the nitty-gritty details of how 3D stuff actually works (nor have I used Danmakufu's before), but ... I'm thinking, using polygons (rectangles?) in 3D space. Give each polygon width, height, texture, (tint, maybe?), X Y Z coordinates of the center, pitch/yaw/roll rotation, and ... that should handle a lot of things. Script camera-control, "fog" (i.e. the way things fade into a blank color in the distance), background image/color ...

Also, I realized a problem with my Brilliant Plan for 3D: it would be extremely difficult to make, say, an octagonal pillar, because rotating a rectangle 45 degrees, to fit with anything else you'd need use the Pythagorean theorem to give it a helpful width. So, instead, how about, um, a "triangle" function where you specify the X,Y,Z coordinates of each corner (and the texture and all details about that), and a "rectangle/rhombus" function that where you specify the X,Y,Z coordinates of three of the coordinates, and extrapolate the fourth from that. Really, I think that no matter what we do, unless Nuclear Cheese is prepared to code an entire 3D GUI, there is no easy way of doing 3D.

All shapes in 3D are composed of triangles (in most realtime computer rendering, anyways) - your rectangle functions are basically drawing two triangles, for instance.  I could certainly add support for throwing in triangles and such, from which more complex shapes can be made.  The whole "position + pitch/yaw/roll" rectangle setup, though, is one of the things that I don't like in Danmakufu, and unless there's strong demand I don't see a reason to include it.



I think that bombs are best served with, "When player uses a bomb, run player's bomb-script" and let the bomb script do anything any other script can.

I'll clarify what I found complex about bomb scripts: You have to use effect objects to create any visible effects during the bombs.  Offering a much simpler method that can use normal draw routines or standard bullet graphics drawing would be wonderful.  Yeah, keeping complexity is nice, but... srsly.

Also, I remember testing on Danmakufu and finding that although you could shoot as normal, damage added from the shots was auto-reduced... but I may have come upon an error there.

I think that bombs are best served with, "When player uses a bomb, run player's bomb-script" and let the bomb script do anything any other script can.

Always nice to see people who haven't used Danmakufu's Player Scripting functions... My my.

My plan for bombs was basically to have a bomb script that would run for the player when the bomb button was pressed.  The main difference here would be that, rather than handling all of the objects and such itself, the bomb script's main purpose would be to spawn 'player shot' objects for the bomb.  These could be defined as custom object types to define the behavior.
Is there a better way to do this?  Of course, I wouldn't unnecessarily limit what can be done in said script.

And, Naut - play nice ;)



I'll clarify what I found complex about bomb scripts: You have to use effect objects to create any visible effects during the bombs.  Offering a much simpler method that can use normal draw routines or standard bullet graphics drawing would be wonderful.  Yeah, keeping complexity is nice, but... srsly.

Once you know how to use effect objects you'll they are infinately better than the shitty "draw from the center" style DrawGraphic functions, despite the steep learning curve.

Yeah, but you don't have the choice.  And that's where the problem lies - what commands you could use were limited by script 'type' in Danmakufu.

Shouldn't be an issue with my setup - like I said above, I intend to have no unnecessary limitations.



Aaaand NC mentioned the coordinate system... Why do we have 0 pointing up? Why are we screwing up the degree system even further? Do you know how often I have to change my work on math exams because I keep using clockwise rotation...? Just keep it like it should be, I have no problem using 270 as down. It's how everybody is taught. Also, (0,0) -> bottom left. Why was this ever changed...

In addition to that, before you try to handle the program's player scripting functions, you might want to go through Stuffman's Player Script tutorial and see how it's done for yourself. There's not real easy way to explain how batshit player scripting is other than actually seeing for yourself.

A few points, my friend -

  • Computer graphics pretty much always have (0,0) in the upper left.  It's how the screen buffer is addressed.  Location 0 is the upper left, incrementing are you increase X.  When you hit the end of the row, the next location is the leftmost pixel one row down.
  • With the Y inverted from how it usually is in math class, rotation is going to be inverted too.
  • I set up as zero because, to me, it makes more sense to have a vertical angle as zero (thinking like 0 = forward).  I can change this if people want.

Not trying to be condecending or anything here; I'm just explaining my reasoning.



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?

That distorted area around the bosses of SA/UFO would be nice, if you could do that.

Haven't played those two games yet (save for the SA demo once some time ago).  We'd need to figure out what, exactly, the effect is doing.  If we're lucky, it's simple enough that we won't need shaders and such.



This sounds simply amazing. Have you already started?

If so, then what language are you using to program it?

Yes, I have started programming.  As I mentioned above, I'm using C#, with SDL.NET and OpenGL for the input/output.



No new coding progress today; I did get a chance to start fooling around with ANTLR, which is a program that generates parsers - once I get the hang of using this I can get a parser up and running for actual script files (hopefully) in little time.
Translation: t3h program will read actual script files and run them OMG! O_O
to quote Naut:
"I can see the background, there are too many safespots."
:V

Drake

  • *
Re: A replacement for Danmakufu?
« Reply #111 on: September 20, 2009, 01:42:13 AM »
[/pirate]

Besides, just tack on "+90" for any angle if you want to calculate it starting at the right ? la unitary.

I like this coordinates setup too, so :P



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]
« Last Edit: September 20, 2009, 01:46:56 AM by Captain Drake I »

A Colorful Calculating Creative and Cuddly Crafty Callipygous Clever Commander
- original art by Aiけん | ウサホリ -

Re: A replacement for Danmakufu?
« Reply #112 on: September 20, 2009, 01:50:56 AM »
Hmm. "0 degrees = up" may make more sense for this if you've never used either system before, but "0 = right" seems to be what most people are actually used to. I know it might confuse me a bit in some cases ... um, no matter which version you ultimately use.

As for 3D, let's say the "triangle" method. And the texture should have its own X/Y coordinates, such that 0,0 is the upper-left corner of the triangle's total area (i.e. the leftmost point is the triangle's local "X = 0", and the uppermost point is the triangle's "Y = 0"). Also textures should probably have a "rotation" setting, too. This way, you could make a seamless rectangular shape with one triangle at (let's say) "0,0,0"/"0,5,0"/"5,0,0" and the other at "5,5,0"/"0,5,0"/"5,0,0" and give them identical texture settings.

Also: if you even consider the possibility of being able to animate the 3D elements beyond simply moving the camera past them, I recommend putting it way on the backburner for now, because can you say "WAY too much complexity all at once"?

Drake

  • *
Re: A replacement for Danmakufu?
« Reply #113 on: September 20, 2009, 01:56:05 AM »
Yes, 3D should be one of the last things done. Just stop worrying about it until later.

A Colorful Calculating Creative and Cuddly Crafty Callipygous Clever Commander
- original art by Aiけん | ウサホリ -

Re: A replacement for Danmakufu?
« Reply #114 on: September 20, 2009, 02:31:29 AM »
Sorry for my newbiness. I'm not the most experienced danmakufu user.

Anyways, the ability to show more dialogue would be fine.
However, maybe a way to activate a cutscene similar to the opening of IaMP and SWR could be useful for storytelling.
I imagine this could be done by temporarily disabling movement and having a layer of images+text ontop of everything.  Also being able to support cutins during those. Of course, music wouldn't take much to support either.

Drake

  • *
Re: A replacement for Danmakufu?
« Reply #115 on: September 20, 2009, 02:45:32 AM »
As he's adding a type of script for menus and such, that would be introduced there. You would just call a task at a certain point that cycles through images. Not that hard to pull off. (The intro for the two games use only images, not text, as well. They're cut into the image and text portion, though.) As you said, music would be just as easy as during a boss.

A Colorful Calculating Creative and Cuddly Crafty Callipygous Clever Commander
- original art by Aiけん | ウサホリ -

Re: A replacement for Danmakufu?
« Reply #116 on: September 20, 2009, 02:51:20 AM »
As he's adding a type of script for menus and such, that would be introduced there. You would just call a task at a certain point that cycles through images. Not that hard to pull off. (The intro for the two games use only images, not text, as well. They're cut into the image and text portion, though.) As you said, music would be just as easy as during a boss.
Thank you very much for explaining it properly for a newby like myself  ;D
And sorry for making such uninformed posts..

Drake

  • *
Re: A replacement for Danmakufu?
« Reply #117 on: September 20, 2009, 02:55:23 AM »
Garrr, e'ery good pirate starts by cleanin' the barnacles off the hull.

A Colorful Calculating Creative and Cuddly Crafty Callipygous Clever Commander
- original art by Aiけん | ウサホリ -

Re: A replacement for Danmakufu?
« Reply #118 on: September 20, 2009, 03:43:20 AM »
That distorted area around the bosses of SA/UFO would be nice, if you could do that.

Haven't played those two games yet (save for the SA demo once some time ago).  We'd need to figure out what, exactly, the effect is doing.  If we're lucky, it's simple enough that we won't need shaders and such.

As far as I can tell it's simply offsetting vertices using a sinusoid. (Think of it like pushing a sphere through molten plastic).

Code: [Select]
pos: v3, vertex position
normal: v3, vertex normal
radius: float
amplitude: float, should be negative to mimic TH11/12

pos += amplitude * normal * (1 + cos(min(PI, PI * dist(vertex, boss) / range)))

Or something like that :V
« Last Edit: September 20, 2009, 09:11:18 AM by anoNL »

Re: A replacement for Danmakufu?
« Reply #119 on: September 20, 2009, 06:45:52 PM »
I think that bombs are best served with, "When player uses a bomb, run player's bomb-script" and let the bomb script do anything any other script can.

Always nice to see people who haven't used Danmakufu's Player Scripting functions... My my.
I haven't used Danmakufu at all. Care to elaborate, since you'd apparently rather taunt me for my ignorance than try to correct it? ;P

I love taunting people. That's how bomb scripts are handled in Danmakufu. Press x -> run separate bomb script. Sorry I sounded like an ass.

And, Naut - play nice ;)

Mnuh.

Aaaand NC mentioned the coordinate system... Why do we have 0 pointing up? Why are we screwing up the degree system even further? Do you know how often I have to change my work on math exams because I keep using clockwise rotation...? Just keep it like it should be, I have no problem using 270 as down. It's how everybody is taught. Also, (0,0) -> bottom left. Why was this ever changed...

In addition to that, before you try to handle the program's player scripting functions, you might want to go through Stuffman's Player Script tutorial and see how it's done for yourself. There's not real easy way to explain how batshit player scripting is other than actually seeing for yourself.

A few points, my friend -

  • Computer graphics pretty much always have (0,0) in the upper left.  It's how the screen buffer is addressed.  Location 0 is the upper left, incrementing are you increase X.  When you hit the end of the row, the next location is the leftmost pixel one row down.
  • With the Y inverted from how it usually is in math class, rotation is going to be inverted too.
  • I set up as zero because, to me, it makes more sense to have a vertical angle as zero (thinking like 0 = forward).  I can change this if people want.

Not trying to be condecending or anything here; I'm just explaining my reasoning.

Sounds good, I just wanted to know why we chose to mess it up further. <3