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

Nuclear Cheese

  • Relax and enjoy the danmaku.
    • My homepage
A replacement for Danmakufu?
« on: September 07, 2009, 05:03:32 AM »
EDIT: I've been too lazy to update this post, so it's gotten rather out-of-date.  Please check the latest posts for up-to-date information.



Okay, so it seems that a few people think I should make a "better version of Danmakufu".  Stuffman is apparently even volunteering to pay me "... TWENTY BUCKS maybe!" (:V), so I figured I'd sit down and start to think out how it would be done.


Please note:
As of right now I have not started any actual work on this.  Like I said before, I do want to go ahead with this, but I need to make sure I can devote time to it - I wouldn't want to leave you guys with a half-finished program ;).



First Item: Things that could be improved from Danmakufu:
- No power items
- No easy way to modify the game frame (the graphics outside the play area)
- (IMO) Tasks
- Program freezes when a script infinite-loops
- Inability to specify what layer when drawing things
- Difficulty of putting together a stage or full game
- RGB(0,0,0) as transparency causes usability issues
- No easy way to do good looping music
- No easy way to enumerate enemies
- Pause music when game pauses; separate music on gameover/continue screen, resume music on continue
- Make player scripting easier (looking for specifics, if possible)
- Store dialog (and other?) text in a separate file, to facilitate making translations
- No way to change playfield size (low priority issue IMO)
- Compiled format to distribute scripts in (low priority issue IMO)

Feel free to contribute your thoughts to this list - it is one of the main driving lists for the feature set of the proposed new program.



Second Item: Structure:
Unlike Danmakufu, I would want to make this a purely event-oriented setup.  Here's how it would work:

1) We have several object types: player, enemy, enemy bullet, etc.

2) Each object type has several events, with script code for each of them.  These include:
  • Initialize - script run once when an object of this object type is created
  • Tick - script run once each frame for each object of this object type that is active (much like Danmakufu's @MainLoop, when you're not using tasks)
  • Draw - script run whenever we need to draw each object of this object type
  • Finalize - script run once, when an object of this object type is being deleted
  • Collide - script run whenever an object of this object type collides with another object.
    • We can specify different Collide functions for colliding with different object types

It should be noted that ...
  • Several of these can be pre-made (for instance, player collides with enemy shot = player dead X_X) and even hard-coded into the program itself.
  • You can create bullets with custom behavior (like Danmakufu's CreateShotA or Object shots) simply by defining a new bullet object type and giving it event scripts to behave as you want it to.

3) With the above setup, each object we create will have an object type assigned to it, and thus will have its behavior scripted by those events.

(do you hate the color yellow yet? :P)




Third Item: Code:
Overall, I like the C-style syntax that Danmakufu has, so the target code structure would probably be similar to that in many ways.  Suggestions for specifics are welcome at this point, since I don't have any finalized vision of how it'll be yet.

One idea I have is to contain the script for each object type in its own file.  This allows a good segmentation of functionality, although with a complicated script it may start to get messy with the number of files.

EDIT: The general consensus seems to be that being able to group together object types in the same file is better.  So that's how I'll make things.

Internally, the script will be converted into a binary code (or something similar) when the file is read in, to simplify execution.  I'm basically picturing this internal code to be much like machine/assembler code - each command is a single action, simple and straightforward.  In other words, if you had a formula "a =  (b + 7) * 3 + c", it would translate to something like:
  • calculate b + 7, and store it in temp1
  • calculate temp1 * 3, and store it in temp2
  • calculate temp2 + c, and store it in a
(Where temp1 and temp2 are internal temporary variables to store intermediate results)

The long-term goal is that script-writers won't have to even know about the internal code, although I may allow access to it in scripts anyways ...


Also, related to the code is what data-types the code will support.  I think we can get away with the following:
  • Number
  • String
  • Array
  • Boolean (true/false)



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.


To note:
As part of the imlpementation of the script parser, I plan on adding a feature to kill infinite loops.  The idea is that, if any single event script executes over, say, a million commands, it's up to no good and we need to kill things.  Exact limit is TBD, of course.



Fifth Item: Program's Name:

I'm thinking 無数の弾幕 ("Musuu no Danmaku" - "Countless Barrages") ... any objections/recommendations?



Sixth Item: An Idea for Bullet Graphics:

Know how right now we have a fixed set of bullet colors in Danmakufu?  And how you need a new image file if you want a different color?  I've got an idea that can simplify this a bit ...

First - by my observation, the (vast majorify of) bullets in Touhou and Danmakufu consist of the bullet's color, white, and shades between these two.  So, my plan is to color-code the image file:
- Use the green channel to indicate how strongly the bullet's color will be used at that pixel
- Use the red channel to indicate how strongly the white color will be used at that pixel
- Perhaps use the blue channel for a second color (do we have any two-color bullets?)

This way, we can use one bullet image and create any color of bullet with that shape!  Of course, to aid with easy operation, values for "regular" colors, such as red, orange, etc., will be included in the program.
Of course, there should still be a way to draw a image file normally for a bullet.

I could also write a quick program to take a normal bullet graphic, along with it's color, and generate a "generic" color-coded graphic like I describe above from it.



Seventh Item: Misc. Notes:

It is important to realize that this program will not be script-compatible with Danmakufu.  IMO, if we try to keep such compatibility, it'll stifle the ability for this program to rise above Danmakufu's limitations and quirks.
Though, it would certainly be possible to create a "script converter" that would be able to, at least in the case of simpler scripts, automatically convert them to this program's script language.  But I doubt it would be able to do anything that gets too complex.

It could be possible to implement a Danmakufu script interpreter within this program.  This would probably have to be implemented as an entire separate branch of execution from the execution engine described above, though, and I doubt it'd be top priority ...



Eighth Item: A Sample of How a Script Could Look:

Here's a sample of how a simple boss script could look - this script would just fire a bullet at the player every 1/2 second.  Please note that, as mentioned above, I don't have the syntax finalized in any way, so this is all speculative.

Code: [Select]
enemy_boss_object_type "Stupid_Boss"
{
   // typical counter variable
   count = 60;

   // holds the image file name for easier reference
   graphic = "teh_boss.png"

   Initialize
   {
      // Initialize necessary stuff
      SetLife(100);
      MoveTo(GetCenterX(), 100);
      SetCollisionSize(24);
      LoadGraphic(graphic);
   }

   Tick
   {
      count = count - 1;
      if (count <= 0)
      {
         count = 30;

         // Fire a blue shot at the player every 1/2 second
         FireShot(GetX(), GetY(), GetAngleToPlayer(), 2.0, Shot_Type_1, Blue);
      }
   }

   Draw
   {
      // Draw the boss
      DrawGraphic(graphic, GetX(), GetY());
   }

   Finalize
   {
      // Create some point items for the player at the end
      i = 0;
      while (i < 10)
      {
         CreateItem(Point_Item, GetX() + rand(-50, 50), GetY() + rand(-20, 20));
         i = i + 1;
      }
   }
}


And here's a speculative custom bullet script, which flies forward for a second, then stops and turns towards the player, then starts moving again:

Code: [Select]
enemy_shot_object_type "Silly_Shot"
{
   // Typical counter variable
   count = 60;

   // set to true once the bullet has stopped, so we won't keep stopping and restarting
   let already_stopped = false;

   Tick
   {
      count = count - 1;
      if (count <= 0)
      {
         if (!already_stopped)
         {
            spd = GetSpeed();
            if (spd > 0.1)
            {
               // We're still decelerating
               SetSpeed(spd - 0.1);
            }
            else
            {
               // We've stopped.
               SetSpeed(0);
               already_stopped = true;
            }
         }
         else if (GetSpeed() == 0)
         {
            // We've stopped, and haven't restarted yet.  Turn towards the player.
            ang_diff = GetAngleToPlayer() - GetAngle();
            if (abs(ang_diff) < 0.1)
            {
               SetAngle(GetAngleToPlayer());
               SetSpeed(2.5);
            }
            else if (ang_diff < 0)
            {
               SetAngle(GetAngle() + 0.1);
            }
            else
            {
               SetAngle(GetAngle() - 0.1);
            }
         }
      }
   }
}

Once again, please don't put too much value on the exact particulars of the scripts.  This is mainly meant to demonstrate what I mean by this whole "event-oriented" business.

The enemy boss script defines all of the necessary functions for our boss - in this case, it lines up exactly with Danmakufu's @Initialize, @MainLoop, @DrawLoop, and @Finalize.  There is no need for any Colliside handlers because the game already knows what to do when the player or a player shot hits the boss, and we're not defining any other interactions.

The bullet script only has a Tick handler - there is no need for Initialize or Finalize handlers, and it is using a default Draw handler that just draws the bullet's assigned graphic at the appropriate angle and position.  And, just like the boss script, there aren't any Collide definitions because we're only using the default collision behavior of the bullet (that is, kill the player on contact).



Ninth Item: Game Script:

One idea brought up is that, in Danmakufu , it is a bit of a pain to create a full game, especially things like menus and such.  So, my idea is to set up a "game script" file, which allows the scripter an easy way to define an entire game.
Here's an example of what I'm thinking of:

Code: [Select]
game "t3h hardest danmakuu evar lulz"
{
   // allow selection of difficulty for the main game
   Main_Game_Difficulty_Select(true);

   // define images for the difficulty selections
   Main_Game_Difficulty_Images("grade_school.png", "normal.png", "hard.png", "wtf.png");

   // enable the extra game
   Extra_Game(true);

   // allow selection of difficulty for the extra game
   Extra_Game_Difficulty_Select(true);

   // define difficulties for the extra game, in increasing order
   Extra_Game_Difficulty_List(["Extra", "Phantasm", "lulz", "OMEGA"]);

   // define images for the difficulty selections in the extra game
   Extra_Game_Difficulty_Images("extra.png", "yukari.png", "⑨.png", "Ω.png");

   // enable the music room
   Music_Room(true);

   // list of music for the music room
   music_files_list = ["01.ogg", "02.ogg", "03.ogg", "04.ogg", "etc.ogg"];
   music_names_list = ["Menu - Stuff Go Boom", "Stage 1 - Your Face", "Stage 2 - WTF Is This Shit?!",
                       "Final Stage - ZOMGWTFBBQ", "Extra Stage - lulz", "Credits - You'll Never Hear This"];
   Music_Room_Info(music_files_list, music_names_list);

   // disable spellcard practice.  Only n00bs use it anyways :V (Cheese: wait what?)
   Spellcard_Practice(false);

   // define the stages for the main game
   main_game_scripts = ["stage1_script.txt", "stage2_script.txt", "stage3_script.txt"];
   Main_Game_Scripts(main_game_scripts);

   // define the stages for the extra game
   Extra_Game_Scripts(["lulz.txt"]);

   // use EoSD-style power-up mechanics
   Power_Style(EOSD_Type);

   // define the in-between stages results screen image
   Mid_Game_Results_Screen("point_totals.png");

   // define the main game post-game script
   Main_Game_Ending("its_ovar.png");

   // define menu background image
   Menu_Background("lulz_title.png");

   // define menu option images
   Menu_Item_Images("new_game.png", "extra_game.png", "", // blank string for spellcard practice, since its disabled
                    "music.png", "highscores.png", "stage practice", "replay.png", "quit.png");
}

The idea with this is that the program will use this script to load the necessary resources for the menu, and then run the menu using its own built-in code, up until the point where it starts the actual game.  This can yield advantages, including:

  • Automatic handling of spellcard practices and high score records.
  • Replays will start where the actual game starts, not at the menu (plus, with the above structure, we could have replays selectable from the actual game's title screen, even).
  • With the proposed structure above, it'll automatically handle stage transitions with a results screen.
  • Defines game-wide behavior, such as how power-up items work (options include "No power up items" and "EOSD-Style" ... other suggestions?  How about a "Gradius Style" (hit once and you're back to zero ;))?)
  • Of course, easier creation of menus for larger scripts.

Update:
A better idea came up - create a separate "menu script" language which defines each menu the game needs.

Each menu can has a set of options, including images for selected/not selected, enabled/disabled, etc.  Each option can lead to either another menu or start up an actual game.





Like I said above, I need to make sure I can devote some time into this before I start.  In the meantime, please comment on what I've spec'd out, make suggestions, etc.



Once again, on an unrelated note, I would like to ask that, if anybody has musical talent they'd like to lend to what might be my last remaining Danmakufu epic, I'd appreciate it.

Holy crap longpost is long.
« Last Edit: October 31, 2009, 10:29:11 PM by Nuclear Cheese »
to quote Naut:
"I can see the background, there are too many safespots."
:V

Drake

  • *
Re: A replacement for Danmakufu?
« Reply #1 on: September 07, 2009, 05:10:01 AM »
I LOVE YOU

By your description, this sounds much easier to use than Danmakufu, and has less extraordinary limitations. As you're a scripter yourself, I'm sure if someone encountered an unsolvable problem within the program, you could even just program a solution.

The scripts are extremely similar to Danmakufu as well (of course which all look like C which is delicious), and I could probably pick it up in an afternoon.

If you go through with this I will *placeholder* make some music for your epic.
« Last Edit: September 07, 2009, 05:13:10 AM by Drake »

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

Stuffman

  • *
  • We're having a ball!
Re: A replacement for Danmakufu?
« Reply #2 on: September 07, 2009, 05:17:34 AM »
Oh boy oh boy oh boy

Your code example looks fine to me; I don't have any issues with Danmakufu's syntax, I think it's pretty clean and works well so no need to reinvent the wheel in that respect, so I appreciate having the same basic layout.

Having bullets being automatically geared towards being objects would be nice. Especially being able to change the size of their hitboxes and whatnot.

I think a big thing the engine needs is the capability to make a full game without having to hack in your own title screen and stage end screens through some obtuse method. Some sort of default title screen function where you can specify the path to the title screen image, paths to scripts you can run, maybe fonts for the text. Nothing too complicated, just enough to select player/difficulty inside the script, select the extra stage, maybe a music room. In-script replays would obviously be on the complicated side so no need to get into that just yet.

By the way, if you manage to go through with this and you've got a Paypal account I will gladly make good on my offer of 20 bucks.

Maybe.

Hat

  • Just an unassuming chapeau.
  • I will never be ready.
Re: A replacement for Danmakufu?
« Reply #3 on: September 07, 2009, 05:21:36 AM »
You DO realize I would worship you for the rest of my days if you actually did this. Picking up this new script format shouldn't be too hard for me, but it would definitely undermine all the work that's gone towards people making scripts for Danmakufu... The only way around this would be for there to be a way to boot Danmakufu scripts into this, but I'm not sure anyone would have the patience to DO that.

Making it easier to actually concatenate scripts into a game would probably be a crowning achievement, IMO, since Danmakufu requires so much indirect finagling to actually accomplish this. I'm not sure if anyone else would want this, though...

And Drake, you can make music? =0

EDIT: Argh, I should pay attention to that 'people have posted while you were replying' thing. I agree with Stuffman, though, Danmakufu's scripting works fairly well... maybe I'm still fairly novice with scripting, but I think a couple things could be ironed out. Exactly what... I cannot quite compile this late. =\
« Last Edit: September 07, 2009, 05:23:35 AM by Karfloozly »

Stuffman

  • *
  • We're having a ball!
Re: A replacement for Danmakufu?
« Reply #4 on: September 07, 2009, 05:23:01 AM »
I would be fully prepared to drop Danmakufu entirely and recode PoSR from scratch if a new better engine was available.

Not having to use Applocale to load it alone is a big improvement. Makes distribution much easier.

Hat

  • Just an unassuming chapeau.
  • I will never be ready.
Re: A replacement for Danmakufu?
« Reply #5 on: September 07, 2009, 05:24:40 AM »
Ooh, good point about Applocale. And if this actually went through, I think a title theme for Countless Barrages would be in order. =D I could attempt to write one, but I mostly lack the MIDI-synth programs to do actually produce such a thing.

Drake

  • *
Re: A replacement for Danmakufu?
« Reply #6 on: September 07, 2009, 05:31:53 AM »
Another thing Danmakufu is missing. Graphic layer settings for objects.

I can even see how Stuffman's suggestions can be brought into play. Like Danmakufu had different script types for enemies and bullet definitions and whatnot, you could define different script types for not only those, but outside-playing-field properties (and tasks such as the enemy marker), title screen/menus, etc. As such you wouldn't have to jumble the different code inside the same script.

and karfloozy hasn't been to cpmc recently

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

Nuclear Cheese

  • Relax and enjoy the danmaku.
    • My homepage
Re: A replacement for Danmakufu?
« Reply #7 on: September 07, 2009, 05:53:57 AM »
... I go away for half an hour, and there's already 6 posts ... jeez, you people need to go to sleep or something.  ... wait a sec, then what the hell am I doing still up? :vbang:


Glad to the the incredibly positive response so far. :D

If you go through with this I will *placeholder* make some music for your epic.

I find the irony in this amusing - "I'll make something for your Danmakufu script as soon as you make Danmakufu obsolete".

I just might hold you to this. ;)


I think a big thing the engine needs is the capability to make a full game without having to hack in your own title screen and stage end screens through some obtuse method. Some sort of default title screen function where you can specify the path to the title screen image, paths to scripts you can run, maybe fonts for the text. Nothing too complicated, just enough to select player/difficulty inside the script, select the extra stage, maybe a music room. In-script replays would obviously be on the complicated side so no need to get into that just yet.


I can even see how Stuffman's suggestions can be brought into play. Like Danmakufu had different script types for enemies and bullet definitions and whatnot, you could define different script types for not only those, but outside-playing-field properties (and tasks such as the enemy marker), title screen/menus, etc. As such you wouldn't have to jumble the different code inside the same script.

This is a good idea.  I will make note of it.

We could even give a simple set of flags to enable/disable various items ...
  • Difficulty Selection
  • Extra/Phantasm/etc.
  • Spellcard Practice
  • Music Room

Furthermore, we can have the "game script" file specify images and such, and run the menu as a hard-coded piece of the program itself (rather than as a script), meaning the only thing you'd have to worry about is the images and maybe where on the screen things are placed.

By the way, if you manage to go through with this and you've got a Paypal account I will gladly make good on my offer of 20 bucks.

Maybe.

You just can't drop the "Maybe", can you? :V


Making it easier to actually concatenate scripts into a game would probably be a crowning achievement, IMO, since Danmakufu requires so much indirect finagling to actually accomplish this. I'm not sure if anyone else would want this, though...

This ties in to what Stuffman mentioned above, with the whole "simplify creating a whole game" thing.  It's certainly something to look at in detail, and I think it wouldn't be hard to do something that makes it easy.


Not having to use Applocale to load it alone is a big improvement. Makes distribution much easier.

Cool thing is, the program should (hopefully) be perfectly workable without Applocale regardless of current computer settings, since the .NET framework is, by default, fully Unicode.


And if this actually went through, I think a title theme for Countless Barrages would be in order. =D

This would be awesome. =D


Another thing Danmakufu is missing. Graphic layer settings for objects.

Noted.  Would be a simple addition.




I'll update my first post with this stuff and some related brainstorming (mainly the "game script" idea) ...



EDIT:
First post updated.


While doing so, I realized there may be a slight issue in terms of fonts.  I haven't yet figured out a way to access actual fonts on the system through OpenGL.  This isn't a big deal; the worst case scenario is we use an image-based font - although that is sub-optimal, since the character set usable is limited to what ones you've defined an image for.
« Last Edit: September 07, 2009, 06:21:44 AM by Nuclear Cheese »
to quote Naut:
"I can see the background, there are too many safespots."
:V

Helepolis

  • Charisma!
  • *
  • O-ojousama!?
Re: A replacement for Danmakufu?
« Reply #8 on: September 07, 2009, 06:47:05 AM »
Regarding the bullets using colours to create the type of colour bullet you want is a good idea, but it will require too much colorcalculating + scripting while looking at the bullet in a sheet and simply using it's ID is easier. What I would like to see is being able to load more than 255 IDs for a bullet.

Also perhaps even the possibility to load ShotData inside tasks ( multiple shotdata ). Like in the same script:

Task Barrage1{ loadshotdata(CtC style);   CreateShot bla bla bla (make danmaku hell) }
Task Barrage2{ loadshotdata(User styles); CreateShot bla bla (fire fire!) }

Or is this already possible ( afaik , not )

CK Crash

  • boozer
Re: A replacement for Danmakufu?
« Reply #9 on: September 07, 2009, 11:52:20 AM »
Personally, now that I've figured out how they work, I like the way tasks are set up. Maybe you could include them with a different name, just for computability reasons. I'm also not sure why you would want to do that RGB thing with bullets, it would be overly complex when you could just change the graphics. A few other issues I have:

-Inability to change a lot of the default graphics and effects. It would be especially great if a full game script could have a few simple functions to completely overhaul the default graphics temporarily.

-Random incompatibility with MP3 files. Many times I have to change my desired BGM just because danmakufu refuses to play it for no visible reason.

-Issues with adding new shot data. There really shouldn't be an ID limit, and you should be able to use multiple files within a shot data file. In addition, you should be able to change the alpha of additive bullets, because the fire bullets from TH9.5+ look really terrible IMO. Perhaps a way to name the bullets beyond their ID, so I don't have to make a separate file with RED12 = 123, and such?

I would be glad to help make some menu graphics, default bullets, and such.

Hat

  • Just an unassuming chapeau.
  • I will never be ready.
Re: A replacement for Danmakufu?
« Reply #10 on: September 07, 2009, 03:16:23 PM »
and karfloozy hasn't been to cpmc recently
lol, I haven't been to COMPUTER recently, let alone MotK... =\

And any concept of an improvement to Danmakufu would OBVIOUSLY generate a positive response, Nuclear Cheese. XD I think we're all a little tired of "these numbers are too big, I'm going to stop working nao" or "bullet graphics? You mean fun white squares? I think you want fun white squares. Here's some fun white squares." (I refer to danmakufu's stupid alpha rendering... hm)
« Last Edit: September 07, 2009, 03:18:17 PM by Karfloozly »

Drake

  • *
Re: A replacement for Danmakufu?
« Reply #11 on: September 07, 2009, 04:40:17 PM »
Oh yes, proper music looping would be great.
Also just because I've had trouble with it in the past, a way to change the base angle of everything in the playable area such as SetShotDirectionType, but more controllable, would be fantastic. Of course this is relatively minor, just putting it out there.

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

Re: A replacement for Danmakufu?
« Reply #12 on: September 07, 2009, 04:59:01 PM »
Should this ever see a usable beta version, expect monies.

I'm really curious as to how you plan to handle tasks/micro-threads, since this is primarily how I code using Danmakufu nowadays. I'm a big fan of the "do this, wait x frames, do something else, repeat, etc" method, as opposed to the conditional statements and augmenting values method most people use.

Beyond that concern, everything else I had issues with has been mentioned. I'm really looking forward to seeing this program completed, so please keep us posted on your progress and let us know if you have any issues or requests. I'd like to help in any way possible, though my skillset may not be as diverse as Drake's musical or puremrz's bulletical graphical talents.

Helepolis

  • Charisma!
  • *
  • O-ojousama!?
Re: A replacement for Danmakufu?
« Reply #13 on: September 07, 2009, 05:18:58 PM »
Microthreading/tasking is seriously the best step I took on field of danmakufu. It makes me build complex scripts much much easier and it was hell of a help during my afro boss and also being hell of a help with my Kisume boss ( which is almost finished )

- Tasking for sure.
- Agreeing on Drake's two points: Music looping + ShotDirectionType handling.

Re: A replacement for Danmakufu?
« Reply #14 on: September 07, 2009, 05:21:50 PM »
Should this ever see a usable beta version, expect monies.

puremrz

  • Can't stop playing Minecraft!
Re: A replacement for Danmakufu?
« Reply #15 on: September 07, 2009, 05:46:14 PM »
If you make a function that can pick the music's startingpoint, endpoint and loop-beginpoint, you have my approval. :V
I'm used to working with midis in my early days of game-making, and the program I worked with (Zelda Classic) had such functions, so I'm kinda spoiled.

Will it be very hard to remake/modify danmakufu to let it become what you have in mind? At the moment danmakufu's English speaking audience seems rather small. But if you can manage to make it better usable, it'll probably get more crowded in here. I hope.
Full Danmakufu game "Juuni Jumon - Summer Interlude" is done!
By the same person who made Koishi Hell 1,2 (except this game is serious)
Topic: http://www.shrinemaiden.org/forum/index.php/topic,9647.0.html

Drake

  • *
Re: A replacement for Danmakufu?
« Reply #16 on: September 07, 2009, 05:49:10 PM »
Hell if you finish and douzo it to 2ch you'll be famous and stuff lol, never mind getting more english speakers.

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

Re: A replacement for Danmakufu?
« Reply #17 on: September 07, 2009, 05:55:30 PM »
Ah, thought of a new idea:

You should be able to change the size of the game field. The current is 448x480 (vertical style, touhou-like), you should be able to edit it at the start of a script to say, 556x400 (horizontal style, gradius-like shooter). I'd also like if the whole program was ran in a larger window -- instead of 640x480, it could be 800x600, which I think is still compatible with most computers and allows more room to work with.

Drake

  • *
Re: A replacement for Danmakufu?
« Reply #18 on: September 07, 2009, 06:05:02 PM »
Actually, Danmakufu's screen is too big, believe it or not. Touhou has always (Windows) been 384x448.
Either way the concept's practicality holds true.

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

Primula

  • EARL TYPE 222
Re: A replacement for Danmakufu?
« Reply #19 on: September 07, 2009, 06:39:00 PM »
I've been thinking, adding new cutins like Kaiedzuka(?), Fuujinroku, and Subtarranean Animism( Undefined Fantastic Object uses the same as SA).. 0.0 Though I'm not much of a expert coder.

Drake

  • *
Re: A replacement for Danmakufu?
« Reply #20 on: September 07, 2009, 06:54:05 PM »
But you'd think that the community would be able to do that ourselves. MoF's is just bottom-right to center, then up and fade, SA's is just center-right to center, and exit left, and UFO's is nearly the same, just starting higher and reaching lower.

There's no need to force just small things that we could do ourselves, right?

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

Primula

  • EARL TYPE 222
Re: A replacement for Danmakufu?
« Reply #21 on: September 07, 2009, 07:46:17 PM »
Well, I guess so...*stares at the DollTrial's scripts*

MCXD

  • Test
  • Light Sign "Heaven Engine"
Re: A replacement for Danmakufu?
« Reply #22 on: September 07, 2009, 07:46:54 PM »
Totally supporting this project 100% (Not sure about being able to chip in money though...)

I will echo other people's opinions of tasks though. I think the way Danmakufu handles them is fine, and a much easier way to use Danmakufu on a whole than the traditional method. Be careful when adding them into your replacement, as it's tough to improve them without really just adding lazy functions for people (inbuilt Wait, etc).

Also if there is one thing that I demand be changed, it's the handling of transparency. Do NOT make (0, 0, 0) the transparent color like the Danmakufu developers did. It's stupid, and causes problems.

EDIT: Also seriously? Separate files for every type of bullet in the game? I think you should make it so you can have multiple scripts inside one .txt, and import them into a spell script via some sort of #include, because there is no way in heck you can expect people to have 200 .txts lying around just for the bullets the bosses will be firing.
« Last Edit: September 07, 2009, 07:51:52 PM by MCXD »

CK Crash

  • boozer
Re: A replacement for Danmakufu?
« Reply #23 on: September 07, 2009, 08:12:39 PM »
Also seriously? Separate files for every type of bullet in the game? I think you should make it so you can have multiple scripts inside one .txt, and import them into a spell script via some sort of #include, because there is no way in heck you can expect people to have 200 .txts lying around just for the bullets the bosses will be firing.
Yeah, like the way you can have an enemy script within a boss script, to be used as a familiar. In fact, every type of "GetBlahFromFile" function ought to have a "GetBlahFromScript" counterpart, because if I want to use an enemy/bullet/whatever only once, why have it in a separate file?

Nuclear Cheese

  • Relax and enjoy the danmaku.
    • My homepage
Re: A replacement for Danmakufu?
« Reply #24 on: September 08, 2009, 12:16:05 AM »
Regarding the bullets using colours to create the type of colour bullet you want is a good idea, but it will require too much colorcalculating + scripting while looking at the bullet in a sheet and simply using it's ID is easier. What I would like to see is being able to load more than 255 IDs for a bullet.

I'm also not sure why you would want to do that RGB thing with bullets, it would be overly complex when you could just change the graphics.

The idea is that, you "look at the bullet sheet" to pick the bullet's shape, and then pick it's color in the script itself.  The scripter won't need to worry about the details of how it works - that'll be handled entirely in the program's code itself (probably with a simple GLSL fragment shader).

The only time any work would need to be done is if you're creating a new bullet shape, and, like I mentioned above, I could create a utility that takes a "normal" bullet image and creates the "coded" version automatically, so I think it would be pretty trivial effort on the scripter's end either way.

Of course, I will still include a way to draw a bullet as an image directly, rather than with the whole color-coded business, for when it is needed.


Also perhaps even the possibility to load ShotData inside tasks ( multiple shotdata ). Like in the same script:

Task Barrage1{ loadshotdata(CtC style);   CreateShot bla bla bla (make danmaku hell) }
Task Barrage2{ loadshotdata(User styles); CreateShot bla bla (fire fire!) }

Or is this already possible ( afaik , not )

-Issues with adding new shot data. There really shouldn't be an ID limit, and you should be able to use multiple files within a shot data file. In addition, you should be able to change the alpha of additive bullets, because the fire bullets from TH9.5+ look really terrible IMO. Perhaps a way to name the bullets beyond their ID, so I don't have to make a separate file with RED12 = 123, and such?


My idea was to have the "ShotData" loaded more on-the-fly - all you'd need to do is reference what type of bullet is needed when you fire it, and it'll load it up when that comes along.  If I have them defined as names, you won't even need to worry about overlapping ID numbers.  (For instance, if we make a CtC bullet pack, their names could all start with "CtC_".  That way, to use a CtC-style bullet, just tell it to fire a shot of type, say, "CtC_01").

The most you'll have to do have a quick pointer to where the data is defined - a simple command to say "Load the shot images defined at ___".

EDIT:
To clarify -
Each bullet needs at least the following info:
- image
- collision size

... so, I'm suggesting we have some way of defining that for each bullet.  The main difference between my approach and Danmakufu's approach is, rather than using numeric IDs, we'll using strings to name them.  This allows us to combine bullet packs more easily (as long as names don't overlap), and also gives us a much larger amount of possible IDs to work with.


Personally, now that I've figured out how they work, I like the way tasks are set up. Maybe you could include them with a different name, just for computability reasons.

I'm really curious as to how you plan to handle tasks/micro-threads, since this is primarily how I code using Danmakufu nowadays. I'm a big fan of the "do this, wait x frames, do something else, repeat, etc" method, as opposed to the conditional statements and augmenting values method most people use.

Microthreading/tasking is seriously the best step I took on field of danmakufu. It makes me build complex scripts much much easier and it was hell of a help during my afro boss and also being hell of a help with my Kisume boss ( which is almost finished )

- Tasking for sure.

I will echo other people's opinions of tasks though. I think the way Danmakufu handles them is fine, and a much easier way to use Danmakufu on a whole than the traditional method. Be careful when adding them into your replacement, as it's tough to improve them without really just adding lazy functions for people (inbuilt Wait, etc).

IMO, the event-oriented model I've set up above pretty much obsoletes tasks as I've seen them used around here.
For instance, tasks that control object shots are no longer needed, since now an "object shot" is defined as its own object type, and given its own code that is automatically run every frame.

I could add in a function called, say, Wait that will stop the object's Tick event from being called for X frames, to facilitate adding delays.

If you guys see an application for which tasks make sense, though, I can put such functionality in.


A few other issues I have:

-Inability to change a lot of the default graphics and effects. It would be especially great if a full game script could have a few simple functions to completely overhaul the default graphics temporarily.

This would likely be handled by the "Game Script" idea I threw out late last night.


-Random incompatibility with MP3 files. Many times I have to change my desired BGM just because danmakufu refuses to play it for no visible reason.

I doubt that SDL.net has any compatibility issues like this.  Unfortunately, this is one thing that would be a bit beyond my control.


I would be glad to help make some menu graphics, default bullets, and such.

Beyond that concern, everything else I had issues with has been mentioned. I'm really looking forward to seeing this program completed, so please keep us posted on your progress and let us know if you have any issues or requests. I'd like to help in any way possible, though my skillset may not be as diverse as Drake's musical or puremrz's bulletical graphical talents.

Cooltimes! :D


And any concept of an improvement to Danmakufu would OBVIOUSLY generate a positive response, Nuclear Cheese. XD I think we're all a little tired of "these numbers are too big, I'm going to stop working nao" or "bullet graphics? You mean fun white squares? I think you want fun white squares. Here's some fun white squares." (I refer to danmakufu's stupid alpha rendering... hm)

... "fun white squares"?  I've ... actually never heard of that problem.  Mind describing it a bit, so I can be sure to not make the same mistake?


Oh yes, proper music looping would be great.

- Agreeing on Drake's two points: Music looping + ShotDirectionType handling.

If you make a function that can pick the music's startingpoint, endpoint and loop-beginpoint, you have my approval. :V
I'm used to working with midis in my early days of game-making, and the program I worked with (Zelda Classic) had such functions, so I'm kinda spoiled.

I can't 100% guarentee that I can do that, but, failing that, I do have a plan B:

Split the music file into two parts: "intro" and "loop".  The intro part plays once, then the program automatically switches to the loop part and loops that indefinitely.  Would be written in as something like:
PlayMusicLoop("intro.ogg", "loop.ogg");

Opinions on this?


Also just because I've had trouble with it in the past, a way to change the base angle of everything in the playable area such as SetShotDirectionType, but more controllable, would be fantastic. Of course this is relatively minor, just putting it out there.

Currently, I'm not sure if I'm going to include a command like SetShotDirectionType, but you'll be able to get the angle to the player from any object (while you're in that object's Tick event script, at least), so adjusting the angle towards the player (or some other base) shouldn't be difficult either way.


Should this ever see a usable beta version, expect monies.

Should this ever see a usable beta version, expect monies.

Totally supporting this project 100% (Not sure about being able to chip in money though...)

Umm ... okay? :V


Will it be very hard to remake/modify danmakufu to let it become what you have in mind? At the moment danmakufu's English speaking audience seems rather small. But if you can manage to make it better usable, it'll probably get more crowded in here. I hope.

I can't really modify Danmakufu as it is, since I don't have access to the source code.  The program I'm talking about would be built from the ground up.  The hardest part would be interpreting the scripts, and I've found a way to do that so it's just a matter of finding time to push through all of it.

And my intention is to make usability a top priority - many of the complaints about Danmakufu seem to stem from odd limitations and random quirks.


Hell if you finish and douzo it to 2ch you'll be famous and stuff lol, never mind getting more english speakers.

... wait, you mean I could be famous to the Japanese for more than my "Burn Everything" script?  Whoa ... O_O


Ah, thought of a new idea:

You should be able to change the size of the game field. The current is 448x480 (vertical style, touhou-like), you should be able to edit it at the start of a script to say, 556x400 (horizontal style, gradius-like shooter). I'd also like if the whole program was ran in a larger window -- instead of 640x480, it could be 800x600, which I think is still compatible with most computers and allows more room to work with.

Actually, Danmakufu's screen is too big, believe it or not. Touhou has always (Windows) been 384x448.
Either way the concept's practicality holds true.

My plan was to have the program's resolution changable - the user can select a resolution to run the game at and it would scale the graphics accordingly (no effect on gameplay).  800x600 is a good default in my mind.
The actual playfield size will need to be determined at some point; any particular preferences?

As far as switching to a different-sized gameplay field, I could add in a "horizontal mode", although at the moment I think that would be a lower priority.


I've been thinking, adding new cutins like Kaiedzuka(?), Fuujinroku, and Subtarranean Animism( Undefined Fantastic Object uses the same as SA).. 0.0 Though I'm not much of a expert coder.

Certainly could be done, although I'm no magician with graphical effects so I might not be able to duplicate it exactly.

... on that note - I need to actually get said games at some point :-\


Also if there is one thing that I demand be changed, it's the handling of transparency. Do NOT make (0, 0, 0) the transparent color like the Danmakufu developers did. It's stupid, and causes problems.

Does this also apply to image formats which do not support transparency, or images that have no transparency channel?  Perhaps an alternative to use for such image formats is instead to use "magic magenta" (255, 0, 255) - it's a kinda odd color to begin with, so it might be "safer" to use as a transparency key.


EDIT: Also seriously? Separate files for every type of bullet in the game? I think you should make it so you can have multiple scripts inside one .txt, and import them into a spell script via some sort of #include, because there is no way in heck you can expect people to have 200 .txts lying around just for the bullets the bosses will be firing.

Yeah, like the way you can have an enemy script within a boss script, to be used as a familiar. In fact, every type of "GetBlahFromFile" function ought to have a "GetBlahFromScript" counterpart, because if I want to use an enemy/bullet/whatever only once, why have it in a separate file?

It's not a definite idea, and I could certainly see the problem you're mentioning.  Keep in mind, though, a couple things about bullet object types:

  • Basic bullets (fly forward until they're gone) do not need any special scripting - these encompass most bullets fired by most bosses, I believe
  • You'll only need one script for each type of bullet behavior - different bullet images that behave the same will not need separate scritps

Onthenet - the whole GetBlahFromScript idea could very well end up being redundant.  If I have a command that imports all bullet types from a script file, it would most like work even if said script file is actually an enemy script that includes some shot types with it.




... this thread is moving at the speed of light already, and I haven't even done any real work yet.  Wow. :o

I have some real-life things starting up soon, but I should be able to find a chunk of time to sit some and crank out some work on this in the near future.
« Last Edit: September 08, 2009, 12:22:02 AM by Nuclear Cheese »
to quote Naut:
"I can see the background, there are too many safespots."
:V

Zengar Zombolt

  • Space-Time Tuning Circle - Wd/Fr
  • Green-Red Divine Clock
Re: A replacement for Danmakufu?
« Reply #25 on: September 08, 2009, 12:23:32 AM »
... "fun white squares"?  I've ... actually never heard of that problem.  Mind describing it a bit, so I can be sure to not make the same mistake?
Instead of rendering the bullet, shit happens and you get a mass of squares chucked at you. Think on Drake's black squares of death mods.
Also,
You just can't drop the "Maybe", can you? :V
I will beat that.
I'll pay you 20 bucks!
Someday!

Primula

  • EARL TYPE 222
Re: A replacement for Danmakufu?
« Reply #26 on: September 08, 2009, 01:15:35 AM »
*whistle* I did not make the following...

Code: [Select]
let CUT_KOUMA = 0;
let CUT_YOUMU = 1;
let CUT_EIYA = 2;
let CUT_KAEI = 3;
let CUT_FUZIN = 4;
let CUT_TIREI = 5;

task SPELLCARD(let spell_type, let cutin_img, let l, let t, let r, let b, let arg_angle) {
let wait_time = 40;
cutin;
task cutin {
let cut = cutin_img;
// LoadGraphic(cut);
let obj = Obj_Create(OBJ_EFFECT);
ObjEffect_SetTexture(obj, cut);
ObjEffect_SetPrimitiveType(obj, PRIMITIVE_TRIANGLEFAN);
ObjEffect_CreateVertex(obj, 4);
ObjEffect_SetLayer(obj, 5);
let wh = [l ,t, r, b];
let xy = [-(wh[2] - wh[0]) / 2, (wh[2] - wh[0]) / 2, (wh[2] - wh[0]) / 2, -(wh[2] - wh[0]) / 2, -(wh[3] - wh[1]) / 2, -(wh[3] - wh[1]) / 2, (wh[3] - wh[1]) / 2, (wh[3] - wh[1]) / 2];
let uv = [wh[0], wh[2], wh[2], wh[0], wh[1], wh[1], wh[3], wh[3]];
ascent (i in 0..4) {
ObjEffect_SetVertexXY(obj, i, xy[i], xy[i + 4]);
ObjEffect_SetVertexUV(obj, i, uv[i], uv[i + 4]);
}
if (spell_type == CUT_KOUMA) {
let start_x = GetClipMaxX + (absolute(r - l) / 2);
let end_x = GetClipMaxX - (absolute(r - l) / 2) - 15;
let move_x = (end_x - start_x) / wait_time;
Obj_SetPosition(obj, start_x, GetCenterY);
ObjEffect_SetScale(obj, 1.3, 1.3);
let al = 255 / wait_time;
ascent (i in 0..wait_time) {;
ascent(j in 0..4) {
ObjEffect_SetVertexColor(obj, j, i * al, 255, 255, 255);
}
Obj_SetPosition(obj, start_x + move_x * i, GetCenterY);
wait(1);
}
wait(wait_time * 1.5);
ascent (i in 0..wait_time) {;
ascent(j in 0..4) {
ObjEffect_SetVertexColor(obj, j, 255 - (i * al), 255, 255, 255);
}
ObjEffect_SetScale(obj, 1.3 + i * (2 / wait_time), 1.3 + i * (2 / wait_time));
wait(1);
}
}
if (spell_type == CUT_YOUMU) {
let x = absolute(r - l) / 2;
let start_y = GetCenterY - 125;
let end_y = GetCenterY + 125;
let move_y = (end_y - start_y) / (wait_time * 3);
let get_y;
Obj_SetPosition(obj, GetClipMaxX - 5 - x, start_y);
ObjEffect_SetScale(obj, 1.3, 1.3);
let al = 255 / wait_time;
ascent (i in 0..wait_time * 1.5) {;
ascent(j in 0..4) {
ObjEffect_SetVertexColor(obj, j, i * al, 255, 255, 255);
}
Obj_SetPosition(obj, GetClipMaxX - 5 - x, start_y + move_y * (i * 0.75));
wait(1);
}
get_y = Obj_GetY(obj);
ascent(i in 0..wait_time * 1.5) {
Obj_SetPosition(obj, GetClipMaxX - 5 - x, get_y + move_y * (i * 0.75));
wait(1);
}
get_y = Obj_GetY(obj);
ascent (i in 0..wait_time * 1.5) {;
ascent(j in 0..4) {
ObjEffect_SetVertexColor(obj, j, 255 - (i * al), 255, 255, 255);
}
Obj_SetPosition(obj, GetClipMaxX - 5 - x, get_y + move_y * (i * 0.75));
wait(1);
}
}
if (spell_type == CUT_EIYA) {
let start_y = GetCenterY - 50;
let end_y = GetCenterY + 50;
let move_y = (end_y - start_y) / (wait_time * 3);
let get_y;
Obj_SetPosition(obj, GetCenterX, start_y);
ObjEffect_SetScale(obj, 1.3, 1.3);
let al = 255 / (wait_time * 1.5);
ascent (i in 0..wait_time * 1.5) {;
ascent(j in 0..4) {
ObjEffect_SetVertexColor(obj, j, i * al, 255, 255, 255);
}
Obj_SetPosition(obj, GetCenterX, start_y + move_y * i);
wait(1);
}
get_y = Obj_GetY(obj);
ascent(i in 0..wait_time * 1.5) {
Obj_SetPosition(obj, GetCenterX, get_y + move_y * i);
wait(1);
}
get_y = Obj_GetY(obj);
ascent (i in 0..wait_time * 1.5) {;
ascent(j in 0..4) {
ObjEffect_SetVertexColor(obj, j, 255 - (i * al), 255, 255, 255);
}
Obj_SetPosition(obj, GetCenterX, get_y + move_y * i);
wait(1);
}
}
if (spell_type == CUT_KAEI) {
let x = absolute((r - l) / 2);
let y = absolute((b - t) / 2);
xy = [-x, x, x, -x, -y, -y, y, y];
uv = [wh[0], wh[2], wh[2], wh[0], wh[1], wh[1], wh[3], wh[3]];
ascent (i in 0..4) {
ObjEffect_SetVertexXY(obj, i, xy[i], xy[i + 4]);
ObjEffect_SetVertexUV(obj, i, uv[i], uv[i + 4]);
}
Obj_SetPosition(obj, GetCenterX, GetClipMinY + 50 + y);
ObjEffect_SetScale(obj, 1.3, 0);
let change_scale = 1.3 / (wait_time * 0.22);
ascent(i in 0..wait_time * 0.25) {
ObjEffect_SetScale(obj, 1.3, 0 + change_scale * i);
wait(1);
}
loop (wait_time * 2.5) {
wait(1);
}
descent(i in 0..wait_time * 0.25) {
ObjEffect_SetScale(obj, 1.3, 0 + change_scale * i);
wait(1);
}
}
if (spell_type == CUT_FUZIN) {
let start_y = GetCenterY + 150;
let end_y = GetCenterY - 50;
let move_y = (end_y - start_y) / (wait_time * 3);
let get_y;
Obj_SetPosition(obj, GetCenterX + 50, start_y);
ObjEffect_SetScale(obj, 1.3, 1.3);
let al = 255 / wait_time;
ascent (i in 0..wait_time) {;
ascent(j in 0..4) {
ObjEffect_SetVertexColor(obj, j, i * al, 255, 255, 255);
}
if (i < wait_time / 2) {
Obj_SetPosition(obj, GetCenterX + 50, Obj_GetY(obj) + move_y * 0.5);
} else {
Obj_SetPosition(obj, GetCenterX + 50, Obj_GetY(obj) + move_y * 1.5);
}
wait(1);
}
get_y = Obj_GetY(obj);
ascent(i in 0..wait_time) {
Obj_SetPosition(obj, GetCenterX + 50, get_y + move_y * (i * 1.5));
wait(1);
}
get_y = Obj_GetY(obj);
ascent (i in 0..wait_time) {;
ascent(j in 0..4) {
ObjEffect_SetVertexColor(obj, j, 255 - (i * al), 255, 255, 255);
}
if (i < wait_time / 4) {
Obj_SetPosition(obj, GetCenterX + 50, Obj_GetY(obj) + move_y * 1.5);
} else {
Obj_SetPosition(obj, GetCenterX + 50, Obj_GetY(obj) + move_y * 0.5);
}
wait(1);
}
}
if (spell_type == CUT_TIREI) {
let set_x = GetClipMaxX + ((r - l) / 2);
let set_y = GetClipMinY - ((b - t) / 2);
let set_radius = (absolute(GetCenterX - set_x) ^ 2 + absolute(GetCenterY - set_y) ^ 2) ^ 0.5;
let start_x = GetCenterX + set_radius * cos(arg_angle);
let start_y = GetCenterY + set_radius * sin(arg_angle);
Obj_SetPosition(obj, start_x, start_y);
ObjEffect_SetScale(obj, 1.3, 1.3);
Obj_SetAngle(obj, atan2(GetCenterY - start_y, GetCenterX - start_x));
Obj_SetSpeed(obj, ((absolute(GetCenterX - start_x) ^ 2 + absolute(GetCenterY - start_y) ^ 2) ^ 0.5) / wait_time);
let al = 255 / (wait_time * 0.95);
ascent (i in 0..wait_time * 0.95) {;
ascent(j in 0..4) {
ObjEffect_SetVertexColor(obj, j, i * al, 255, 255, 255);
}
wait(1);
}
ascent(i in 0..wait_time * 1.5) {
Obj_SetSpeed(obj, 0.5);
wait(1);
}
ascent(i in 0..wait_time) {
Obj_SetSpeed(obj, 0 + i * 0.5);
ascent(j in 0..4) {
ObjEffect_SetVertexColor(obj, j, 355 - (i * al), 255, 255, 255);
}
wait(1);
}
}
Obj_Delete(obj);
}
}

Nimono

  • wat
Re: A replacement for Danmakufu?
« Reply #27 on: September 08, 2009, 03:15:47 AM »
I have a suggestion on something you might want to code in...maybe. Just...player homing. I'd honestly like an easier way than just factoring everything in and putting in a huge script. Like, I'd rather just have something like IsHoming(true); in the script, with, say, HomingType(REIMU_AMULET); or something to define how it'd home in. (Such that you could have different types of homing, such as true homing that follows until it hits, like Reimu's amulets, homing within a certain range, such as Sakuya's, except still true homing, etc. Maybe allow people to then code in their own homing styles, too?) At least have a homing function that picks the target itself without us having to make a lot of code to do so, and also stop the homing when there's nothing to hit, especially when a boss is dying. Just a thought, though I'm sure a few people might say that they'd rather script the homing themselves, but it'd be nice to NOT have to go through all of that.

Drake

  • *
Re: A replacement for Danmakufu?
« Reply #28 on: September 08, 2009, 03:24:03 AM »
I have a suggestion on something you might want to code in...maybe. Just...player homing. I'd honestly like an easier way than just factoring everything in and putting in a huge script. Like, I'd rather just have something like IsHoming(true); in the script, with, say, HomingType(REIMU_AMULET); or something to define how it'd home in. (Such that you could have different types of homing, such as true homing that follows until it hits, like Reimu's amulets, homing within a certain range, such as Sakuya's, except still true homing, etc. Maybe allow people to then code in their own homing styles, too?) At least have a homing function that picks the target itself without us having to make a lot of code to do so, and also stop the homing when there's nothing to hit, especially when a boss is dying. Just a thought, though I'm sure a few people might say that they'd rather script the homing themselves, but it'd be nice to NOT have to go through all of that.
Or at the very least keep the enemy enumeration easy.
As everything is done in objects, it would be easy enough to create your own homing shots with just that.

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

Hat

  • Just an unassuming chapeau.
  • I will never be ready.
Re: A replacement for Danmakufu?
« Reply #29 on: September 08, 2009, 03:26:11 AM »
I agree with the enemy enumeration thing. Once you actually get a good homing code down, there's not really that much use for it aside from one or two things. It took me nine million years to actually GET a good homing code down, but I did it, and it works perfectly. =D