A replacement for Danmakufu?

[Nuclear Cheese]

Something I noticed when moving stuff to the new version.  Musuu no Danmaku can't look into subdirectories.  It would make organization much easier if it could.  I don't think we should have enforced subdirectories, like in Danmakufu, where players have to be in /player and scripts in /script, but some subdirectory crawling would be nice.

This is a known issue, and I'll be putting in code for this at some point.  It'll be able to traverse directories freely.

Related to this, right now if you try to include a file from within another file in a directory other than the current directory, it still looks for the include'd file in the current directory.  This will also be fixed.

EDIT: What's the optimal ratio of hitbox size to graze hitbox size?

I'd say it depends on the particular graphic.  I think generally the graze size is about as large as the sprite itself.

The hit size is probably much more variable, and depends on how big the "core" of the shot is, so to speak.

[PT8Sceptile]

Test Release 5.

Excellent, I've waited this for a long time. At last I can use shots with hitbox size bigger than the default one.

However, you made a tiny mistake. The program errored on me until I changed all the decimal part indicators in the shot definition file from '.' to ','. I assume you do know how to fix this, though, since this has caused you trouble before, too.

[Dizzy H. "Muffin" Muffin]

I think it'd be a good idea to give line-numbers at minimum when a script fatalerrors. I got "The given key was not found in the dictionary" when I tried to run Phi2Dao's boss-script, which is neither helpful nor informative. :<

[phi2dao]

The problem probably was that I used FireShot01S() a lot, and that function has been depreciated.  Change all FireShot01S() into FireShot01().

I'm planning on writing a bullet definition file for the shot sheet that PT8Sceptile posted earlier (if they don't write one first), and when I do I'll upgrade my old enemies and repost them.

[Dizzy H. "Muffin" Muffin]

Hooray, it wor-- AUGH SHE'S CHASING ME

Hmm. Maybe some system for "separate hitbox for items and bullets" maybe ... NO I DIDN'T SET THE HITBOX TO ZEROOOOO

[Nuclear Cheese]

Excellent, I've waited this for a long time. At last I can use shots with hitbox size bigger than the default one.

However, you made a tiny mistake. The program errored on me until I changed all the decimal part indicators in the shot definition file from '.' to ','. I assume you do know how to fix this, though, since this has caused you trouble before, too.

... fuck.  Stupid me forgot about that.

I'll have it fixed first opportunity I get (sometime this weekend, hardships notwithstanding) and I'll upload an updated release.

I think it'd be a good idea to give line-numbers at minimum when a script fatalerrors. I got "The given key was not found in the dictionary" when I tried to run Phi2Dao's boss-script, which is neither helpful nor informative. :<

This will be handled.  I have to throw together a ton of structure to get this in place, but once it is you'll get much more detailed error reports.

As phi2dao says, this is due to you calling FireShot01S, which was removed from the function list.  To clarify, the functions are stored in a Dictionary<string, function_definition>, where the key is the function name.  Right now, it doesn't have a "nice" check as to whether or not the list has the called function, so if it tries to grab something that isn't there, it asplodes and throws that exception.

Hmm. Maybe some system for "separate hitbox for items and bullets" maybe ... NO I DIDN'T SET THE HITBOX TO ZEROOOOO

Clarify?  Are you talking about player hitbox sizes?  Right now, if I'm remembering correctly, the player-item collision checking uses the same collision as the graze hitbox, which is larger than the actual hitbox used for "omg I dead" collisions.

[Dizzy H. "Muffin" Muffin]

Well, uh,

Spoiler:

when I did set the hitbox-size to 0

, it ceased to collect items.

Um, what's the exact syntax for setting size? |3

[phi2dao]

SetSize(size1, size2);

size1 is the collision size.  If it's 0, you can't be hit.
size2 is the graze size.  If it's 0, you can't graze or collect items.

So, for an invincible player that can still graze and collect items, you want SetSize(0, something); And not SetSize(0, 0);

[Dizzy H. "Muffin" Muffin]

Right, I did SetSize(0, 32); and I couldn't collect items for some reason.

[PT8Sceptile]

I'm planning on writing a bullet definition file for the shot sheet that PT8Sceptile posted earlier (if they don't write one first), and when I do I'll upgrade my old enemies and repost them.

You're not the only one doing that.

However, while you're doing that, you might as well use this newer version (remember, it's still in development, since I'm only now getting to see how these bullets actually look in danmaku patterns.):


No bullet locations have changed so whatever old data you've written will work.

However, on more important matters:

SetSize(size1, size2);

size1 is the collision size.  If it's 0, you can't be hit.
size2 is the graze size.  If it's 0, you can't graze or collect items.

So, for an invincible player that can still graze and collect items, you want SetSize(0, something); And not SetSize(0, 0);

Right, I did SetSize(0, 32); and I couldn't collect items for some reason.

Which brings us to some interesting points I stumbled upon when playing with hitbox sizes. There are three problems in total that I noticed and started figuring out explanations for. These problems are:

1 - Yes, making your hitbox size 0 will make you immune to both bullet collision AND item collection. Therefore I assume the collection function in the standard point item object is in collide1, not collide2. However, I can't say this for certain, since I have no idea where the default point item code is! I can find the functions it uses, but that doesn't specify is the function used in collide or collide2. Anyways, a simple switch fixes everything here (if I assume right).

Then:

2 - Actually, the bullet's collision size in the ShotData file is it's size_2, and not size_1. I noticed this when coding hitboxes for large bubble bullets (that are considerably smaller then the sprite). And lastly:
3 - I don't get any graze at all. Whenever I start musuu with -dt, the graze counter stays at 0, period.

However, 2 and 3 have a simple answer/solution. I took a look in the code for parsing bulletsheets and found this:

else if (line.ToLower().StartsWith("size1 "))
                {
                    // define the shot's size1
                    if (current_name != null)
                    {
                        current.size1 = double.Parse(line.Substring(5).Trim());
                    }
                }
                else if (line.ToLower().StartsWith("size2 "))
                {
                    // define the shot's size2
                    if (current_name != null)
                    {
                        current.size1 = double.Parse(line.Substring(5).Trim());
                    }
                }

Facepalm. Thankfully fixing that is pretty much trivial now that we know where the problem lies.

[Nuclear Cheese]

Right, I did SetSize(0, 32); and I couldn't collect items for some reason.

How odd.  Perhaps it's a bug in the collision algorithm.  I'll have to look into ...

Facepalm. Thankfully fixing that is pretty much trivial now that we know where the problem lies.

... it.

I reiterate ... fuck.


Memo to self - stop rushing to get code out for test releases.  It's making me look bad.

[8lue Wizard]

I would've expected Collide1 for item collection, leaving Collide2 for the magnetism effect...

no? o.o

[PT8Sceptile]

Yes, found it. Now, for whatever collision type point items use:

            collide2 = new Script.Instruction[1];
            collide2[0] = mdBaseReader.Parse_Instruction_Line("call \"point_item_collect\", !collided_with_id");
            point_item.Attach_Script(collide2, "collide Player");

While the variable name does indeed cause confusion, I believe this to be collide instead of collide2, since if it were collide2, the last line should be:

point_item.Attach_Script(collide2, "collide2 Player");

Therefore, calling SetSize(0, something) does prevent a player from collecting point items.

I would've expected Collide1 for item collection, leaving Collide2 for the magnetism effect...

no? o.o

This seems like the better idea. Actually, the way this probably should be coded is to leave the point item collect to collide and implement player invincibility through some other means than reducing the collide1 size to zero (most probably through overriding the default "player collided with enemy shot/enemy/boss" collide functions with custom ones on custom players, or perhaps implementing default ones that have inbuilt invincibility support and add a SetPlayerInvincibility function similar to Danmakufu).

[Azure Lazuline]

You should use collide2 for the magnetism effect, but the actual item hitbox for collecting should be in the coding for the item, not the player. Things like how fast the item moves when it's "magnetized" should also be in the item code.

[Dizzy H. "Muffin" Muffin]

Maybe we should have a separate radius for magentism effect altogether -- it's much wider than grazing in MoF et al, i.e. when you Focus.

Or am I misunderstanding you?

[Nuclear Cheese]

I would've expected Collide1 for item collection, leaving Collide2 for the magnetism effect...

no? o.o

I think the "magnetism" effect should be separately implemented in the item's tick function, since it's not anywhere as universal as item collection and such.

And, in case you're wondering - the size1 and size2 parameters are per-object.  You can't set different sizes when colliding with different objects.

Yes, found it. Now, for whatever collision type point items use:

While the variable name does indeed cause confusion, I believe this to be collide instead of collide2, since if it were collide2, the last line should be:

Therefore, calling SetSize(0, something) does prevent a player from collecting point items.

... something like that.  When I'm finally back at my desk (and not totally fried mentally), I have to go back and kick some ASCII to make it work right.

This seems like the better idea. Actually, the way this probably should be coded is to leave the point item collect to collide and implement player invincibility through some other means than reducing the collide1 size to zero (most probably through overriding the default "player collided with enemy shot/enemy/boss" collide functions with custom ones on custom players, or perhaps implementing default ones that have inbuilt invincibility support and add a SetPlayerInvincibility function similar to Danmakufu).

You should use collide2 for the magnetism effect, but the actual item hitbox for collecting should be in the coding for the item, not the player. Things like how fast the item moves when it's "magnetized" should also be in the item code.

I think you guys are slightly misunderstanding how it works.  Setting the size1 or size2 effectively defines the object's collision as a circle (more shapes to come later!) of that radius.  When collision-checking between two objects, it (effectively) checks if the collision circles for the two are intersecting; that is, total distance from one object to the other is <= the sum of their size1 or size2 parameters.

Setting the size to zero is a special case that basically says "this thing can't collide".  Of course, it only affects the "collision layer" that is set to zero (size1 set to 0, size2 set to 5, you'll still get collide2 events).

The issue right here is that, as PT8Sceptile pointed out in the code, I mixed up the collide/collide2 on the default point item scripts.  Possibly when I was reworking the function definitions to allow specification of # and types of arguments.  Thus it tries to use size1 instead of size2 for collision-checking items with the player.


As far as invulnerability goes - I do agree that there should be a better way to implement invulnerability, and I do plan to implement such.  It'll probably involve a simple invulnerability frames counter, along with adding a function to "kill t3h player" which does nothing if the player is invulnerable.  This'll come about the same time as proper lives/bombs support does.

[Dizzy H. "Muffin" Muffin]

Just had a thought: a separate "framework" script-type, included by different stage/enemy scripts, and it would handle stuff like lives, score, UI, etc., and then stuff like lives/respawning would be handled in that instead of hardcoded.

Oh yeah, by the way, I forget if there was any plans for the level-script specifying the playing-field size ...

[Nuclear Cheese]

Just had a thought: a separate "framework" script-type, included by different stage/enemy scripts, and it would handle stuff like lives, score, UI, etc., and then stuff like lives/respawning would be handled in that instead of hardcoded.

There were some ideas that were kinda approaching this being thrown around previously ...

Oh yeah, by the way, I forget if there was any plans for the level-script specifying the playing-field size ...

This idea also got tossed in the pile.  Certainly possible to implement, although it'll be later on in development.




I just put together Test release 5.1 - this should fix the two issues that were brought up in 5.

[PT8Sceptile]

I just put together Test release 5.1 - this should fix the two issues that were brought up in 5.

Good news: Decimal annotation and point items work as supposed. Good work.

Bad news:

                else if (line.ToLower().StartsWith("size2 "))
                {
                    // define the shot's size2
                    if (current_name != null)
                    {
                        current.size1 = double.Parse(line.Substring(5).Trim(), number_format_info);
                    }
                }

is still looming there in the source code. Just a friendly reminder on the fact that there were actually three problems instead of two.

[Dizzy H. "Muffin" Muffin]

This is exactly why I feel like grazing etc. should be in scripts instead of hardcoded. |3

[Nuclear Cheese]

Good news: Decimal annotation and point items work as supposed. Good work.

Bad news:

is still looming there in the source code. Just a friendly reminder on the fact that there were actually three problems instead of two.

Memo to self: Arg stop rushing arg!

I fixed it in the codebase.  I kinda want to wait a couple days before putting up another updated build, incase something else pops up.

Besides, you can't see graze counts yet (except the debug info flag), so I don't think it's that big a deal.  And this bug only affects bullet definitions from mdBullet files, so we won't see it affecting other things.

This is exactly why I feel like grazing etc. should be in scripts instead of hardcoded. |3

Thing is, they are scripted.  There are functions defined in the default bullet behaviors, that can easily be overriddden by a custom-defined EnemyShot type.

You can see the functions defined in the Game class's initialization code.  These scripts are also put in place by default when a new enemy shot type is defined, but they can be overridden by defining new scripts for the same events.

[Prime 2.0]

Bullets should disappear when they hit the player by default. Preferably in a method tied to the sprite used.  :V

[Dizzy H. "Muffin" Muffin]

Oh right. *selfbap* I thought it was the source code for some reason ... I need to look through the not-source-codes some more |3

[Nuclear Cheese]

Hey guys, just poking in to say I haven't run away.
I started working on multiple directory support, but it's not complete yet.  It's got quite a few little details that need to be taken into account.

Bullets should disappear when they hit the player by default. Preferably in a method tied to the sprite used.  :V

Define "in a method tied to the sprite"?  I never really noticed this myself.
(Not an art person etc etc you all know this already I'm sure)

[Prime 2.0]

What I meant by that was that the default animation played by the dissipating bullet would be determined by the sprite used for said bullet. Different bullets dissapear in different ways, you see. :E

Also, if you want to notice it, just go through Kaguya's endgame gauntlet. The one with those quickly moving lines of bullets will make the dissipation rather obvious, if you get hit by said line of bullets.

[null1024]

Fired the example up to test, ran rather slow on my machine [at 800x600, sped up a bit at 640x480, problem went away at 320x240, but that's really small... but I'm so glad my laptop still supports fullscreen with such a low resolution...], and when the life display had a really small decimal part to it [like 50.00000000003], everything went even slower.

I'm on a laptop with a 2.1GHz Dual Core Pentium, 3GB RAM, and one of the Intel GMA things for my video accelerator.

[lumber_of_the_beast]

Bumping, with what's probably a stupid question, but I've never used this or Danmakufu before and I don't know if I should learn danmakufu or wait for this or use this as is please don't hurt me  :ohdear:

Will we be able to do complex, DoDonPachi-style backgrounds, with structures to blow up and ground-based enemies to hide behind them and under bridges and stuff? Or dink around with UI elements, like what bombs or the boss health bar look like?

[PT8Sceptile]

Bumping, with what's probably a stupid question, but I've never used this or Danmakufu before and I don't know if I should learn danmakufu or wait for this or use this as is please don't hurt me  :ohdear:

Will we be able to do complex, DoDonPachi-style backgrounds, with structures to blow up and ground-based enemies to hide behind them and under bridges and stuff? Or dink around with UI elements, like what bombs or the boss health bar look like?

Interactable backgrounds are under my understanding completely feasible even in DMF, and will be just as feasible in Musuu once it gets better drawing functions, verticed effect objects and possibly 3D, although that is only really required in extreme cases (and can actually be somewhat worked around if you're incredibly good with verticed effect objects). These interactable backrounds can be made with enemies that don't kill you on contact, but still have a certain amount of life before they die (and then trigger the destruction effect). The only thing required to make them is good enough scripting skills (which may be quite a lot depending how complex the backgrounds will be since more complexity = more code) and patience (and a fast enough engine, which might be the biggest obstacle of doing that in Musuu as of now since it's collision detection is still quite unoptimized, and there most probably are several other places in the code too that could be done better).

Also, concerning the UI, Musuu seems to be headed in a direction where everything is customizable, so yes. Removing the lifebar might be tricky at the moment but otherwise customizing lives/bombs/etc... should be completely possible even as of now. Just add some effect objects on a drawing layer above the border image (which, by the way, can also be changed by changing the border image in the folder). Just remember that using text images is oftentimes faster that drawing text, since both Musuu and DMF have somewhat slow text-drawing functions. You can also achieve similar results in DMF with a bit of effect objects and stuff, but customizing the default functionality is a bit trickier in DMF.

As for whether you should use DMF or Musuu, I'd say DMF is still somewhat better, but Musuu is well on it's way to overthrowing it. The biggest problem Musuu has as of now is it's unoptimized code, which severely limits what you can do, and lack of several useful things such as user-definable functions or stage scripts. If the engine can be optimized to even somewhat similar levels as DMF's and the lacking basic scripting functionality gets added in, I'd be ready to say that Musuu is at least as useful as DMF, if not more useful. However, even then it might be a question of taste. DMF has a lot more useful default features while musuu is more easily customizable, and their scripting languages are different. I'd say if you want to start scripting now DMF is better, but if you aren't in a hurry and can spend time designing graphics/BGMs/dialog for your game before starting to script it (like I'm doing at the moment), you should consider Musuu seriously. However, it all depends on how the development will proceed. Only time will tell.

Also, has there been any progress since last update? It's been quite a while and the topic had even fallen down to the second page during that time. I'm not hurrying you up or anything but I'm just curious about how things are proceeding.

[Dizzy H. "Muffin" Muffin]

A brainstorming-thought: allowing scripters to make a "game" file, which would consist of all the script/graphics/sound/music/EVERY files you want, in one (say) uncompressed zip file, to distribute games more easily.

Also, I kinda forget, but there was a "start music file from arbitrary point" function planned, wasn't there?

Another crazy idea I had recently was whether it might be somehow possible to do Braid-style time-reversal, here or in Danmakufu. I'm really just tossing out ideas as they come to me.

[Nuclear Cheese]

Hey guys, I still exist.

I gotta apologize; I haven't been able to get anything done in the last couple weeks. 

What I meant by that was that the default animation played by the dissipating bullet would be determined by the sprite used for said bullet. Different bullets dissapear in different ways, you see. :E

Also, if you want to notice it, just go through Kaguya's endgame gauntlet. The one with those quickly moving lines of bullets will make the dissipation rather obvious, if you get hit by said line of bullets.

Ah, I see. We'll need to decide how to setup this in the bullet definitions files - I'm not sure how much variability we could have here.  If nothing else, would could allow it to point to a series of image subrects to define an animation (but there is probably some other, simpler way that I'm not thinking of at the moment).

Fired the example up to test, ran rather slow on my machine [at 800x600, sped up a bit at 640x480, problem went away at 320x240, but that's really small... but I'm so glad my laptop still supports fullscreen with such a low resolution...], and when the life display had a really small decimal part to it [like 50.00000000003], everything went even slower.

I'm on a laptop with a 2.1GHz Dual Core Pentium, 3GB RAM, and one of the Intel GMA things for my video accelerator.

There's many possible factors that could be causing the slowdown here:

First, what other programs are you running at the same time?  Musuu tends to start slowing down for me if I leave my (20+ tabs of) Firefox open, but as soon as that closes it smooths out.

Second, what OS?  I don't think this'll make a huge difference, but some OSs may have worse overall performance than others.

Third, Musuu (currently, at least) does not support multiple cores, so it is only making use of one of the cores in your processor.  There has been talk of adding in multithreading, which will make it able to support multiple cores, but that is a rather complex thing to implement here.

Fourth, "Intel GMA things for my video accelerator" - this could be the biggest issue.  Quick google to wikipedia tells me that this is a low-end integrated video card.

Fifth, it should be noted that the engine still has a lot of optimization to go through, so there is definitely some performance improvement potential to be had down the line.


As far as the text slowing things down more - the text display algorithm (right now, at least) is a rather heavy processor-use piece of code, so when it gets to the "50.0000000003" case, where it has a bunch more characters to display, it has to put in a lot more work to show it (although I think yours is a bit extreme of a case).

Also, to note - the reason we get the "50.000000003" case to begin with is due to floating-point rounding.

Bumping, with what's probably a stupid question, but I've never used this or Danmakufu before and I don't know if I should learn danmakufu or wait for this or use this as is please don't hurt me  :ohdear:

That's a question that you'll have to decide on your own.  Danmakufu is out right now and has a (mostly) fine set of usable features, although with some annoying quirks and some strange limitations.  Musuu is still in development and will probably be for at least a few more months (don't take this as any indication of a release timetable, please), but hopes to be more powerful and flexible that Danmakufu in the long run.

It should be noted, though, that the two do (or will, for features not yet implemented in Musuu) share a fair bit of commonality at a higher-level view (IMO, anyways).

Will we be able to do complex, DoDonPachi-style backgrounds, with structures to blow up and ground-based enemies to hide behind them and under bridges and stuff? Or dink around with UI elements, like what bombs or the boss health bar look like?

Like PT8 said, ground-based enemies/objects are already possible in Danmakufu.  In Musuu, they're definitely doable as well right now - basically I'd think you'd just create an object that moves along the screen at the same rate as the background.

For the UI, I know Danmakufu lets you pick a custom border image.  I also know you can draw over the border in some way (I haven't looked at it, myself), as well as customize player life and bomb icons.  Musuu doesn't have any of this yet, but there is definitely plans to have a fully customizable UI.

Also, concerning the UI, Musuu seems to be headed in a direction where everything is customizable, so yes. Removing the lifebar might be tricky at the moment but otherwise customizing lives/bombs/etc... should be completely possible even as of now. Just add some effect objects on a drawing layer above the border image (which, by the way, can also be changed by changing the border image in the folder). Just remember that using text images is oftentimes faster that drawing text, since both Musuu and DMF have somewhat slow text-drawing functions. You can also achieve similar results in DMF with a bit of effect objects and stuff, but customizing the default functionality is a bit trickier in DMF.

Actually, not true regarding Musuu and drawing over the border - right now, all scriptable drawing in Musuu is done within the gameplay frame only.  Of course, this is a limitation that will be removed later on.

Also, has there been any progress since last update? It's been quite a while and the topic had even fallen down to the second page during that time. I'm not hurrying you up or anything but I'm just curious about how things are proceeding.

As stated above, I've been unable to make any updated in the last couple weeks.  Mainly due to more family crap and being even further behind on sleep that I usually am (which is quite an accomplishment, unfortunately).

A brainstorming-thought: allowing scripters to make a "game" file, which would consist of all the script/graphics/sound/music/EVERY files you want, in one (say) uncompressed zip file, to distribute games more easily.

We've had this idea before; I  don't know how easy/hard it'd be to write code that reads a .zip file, though.

At the very least, there is also the plan to create the compact script file format which could include all the necessary assets for a game.

Also, I kinda forget, but there was a "start music file from arbitrary point" function planned, wasn't there?

There might have been.  The only ones I remember were basic "play music" and "A-B repeat" (either in the same file, or with two files A and B).  What you mention is probably doable.

Another crazy idea I had recently was whether it might be somehow possible to do Braid-style time-reversal, here or in Danmakufu. I'm really just tossing out ideas as they come to me.

While I'm not sure how it's done in Braid (never played it), generally any time-reversal mechanic is, at best, a pain in the ass to impement and, at worst, nigh-impossible.