A replacement for Danmakufu?

[MaronaPossessed]

Well, here's my second  danmaku.  Unlike the last one, this one isn't terrible. 

Something I noticed: A GetAngleToPlayer() or a GetAngleToObj() function would be really nice.  having to type:

Code: [Select]

if (player_id > -1)
{
xdiff = player_id->x - id->x;
ydiff = player_id->x - id->y;
if (xdiff == 0 && ydiff == 0) ydiff = 1;
angle - atan2(ydiff, xdiff)l
}gets tiring after a while.

I'll keep making stuff.  Have a nice day/night.

Keep getting errored when selecting it.

[phi2dao]

Do you have the "Shot" directory?  I thought it came with the Musuu download, but it doesn't seem to have.  I think it was in one of the other test danmaku.  I don't remember which one, though.  If you can't find it, I'll put up a download link to it.

[PT8Sceptile]

Well, here's my second  danmaku.  Unlike the last one, this one isn't terrible. 

This is pretty much excellent. Nice primitive version of a multi-spellcard boss. Excellent work (even if I miss my X-button while getting surprise-walled to death by phase 3 and phase 5 just outright murders me)!

Also, I don't think the Musuu download had the "Shot" -directory, since the default script doesn't reference it at all. It was probably in the example scripts.

[Danielu Yoshikoto]

Do you have the "Shot" directory?

Well i made one for the download in my script and i made some alternate colored Shot1.png.
I am confused now...

EDIT: looks like it was my bullets.
Seeing how others use "my" bullets now it would be best to tell the that these bullets have been used before downloading and having them download this first, to make sure the script works properly.

[phi2dao]

Okay, yeah, so the bullet graphics I used came from By's danmaku.  Sorry about that.  I wanted to use more than one color of bullet, and I didn't notice it wasn't part of the default package. 
So, If anyones having trouble with my danmaku, you can either download by's danmaku, or change wherever it says "Shot/shot1COLOR.png" to "shot1.png".
And by, if you don't want me using your bullets, just tell me.

I think I'll try my hand at a player script next, so expect something some time tomorrow.

Oh, and thanks for playing my danmaku PT8Sceptile!  I'm happy you enjoyed it.
And yeah, phase 3 (thats with two options, right?) is pretty nasty.  And stage 5 (no options) came straight from Subterranean Animism, so you know it's going to be bad.

[Danielu Yoshikoto]

[...] if you don't want me using your bullets, just tell me.

I actually made them to be used for Danmakufu Musuu No Danmaku scripts.
But i wasn?t expecting anyone to already use them this early... i might try to also make different colored versions of Shot2.png but i used it once and it wasn?t turning (all bullets pointed to the bottom while flying in any direction), preaty much just a bunch of "V"s on the screen.

[phi2dao]

Cool, I'm glad you don't mind me using your bullets.  And your problem with shot2 was probably that you used FireShot01S() instead of FireShot01().  FireShot01S() makes stationary bullets (thats what the S is for) and FireShot01() makes rotating bullets.  There are two options because circular bullets look better when they don't rotate.

[phi2dao]

Well, I finished my player early, so here it is.  It's nothing special, but it has a working hit box, startup invincibility, and it re-spawns after 2 seconds.  The hit box, invincibility, and re-spawner are inspired by PT8Sceptile's awesomeface player, but are, for the most part, coded differently.

The Mima sprite sheet came form Johnny Walker's Mima (Mystic Square) touhou danmakufu player script.  If using that was bad, well, I'm sorry!  I won't do it again!

More comments on Musuu no Danmaku itself:

• Needs a sqrt() function
• Or some other way to find the distance between objects
• Custom Player Shots

[Nuclear Cheese]

I used the one in the 4.1 release, downloaded the whole thing from the google code page.

Dang it.

I notice you're on a 'nix system.  I'm wondering if there's something else it's missing specific to that side of things.  Unfotrunately, I don't have any 'nix systems to even try this on (nor the experience with such systems) ... anyone else here have any advice?

Also, as for the To-Do -list for the initial release I suggested, here's something to start with (since no-one else is apparently creating one):

Thanks for putting this together.  Really good to get a list of what people want, so we can direct this program's development properly.

• Bullet definition files

Planned, of course.  We need to agree on what info is needed and how to format it.

• Additional functions for:
• Random numbers

Of course.

• Improved audio control (loop points, pausing/resuming, possibly fadein/fadeout)

Planned.

• Possibly some improved bullet shooting functions like CreateShotA to avoid having to script overtly simple patterns with objects

Can be done.  Do we want something specifically mirroring CreateShotA, or something similar, but with some differences?

• Default support for:
• Lives/respawning

Of course.  Need to plan this out a bit, but I'm planning on adding a miss script, for player scripts to take action to animate their "ONOES I DEAD" and such, with a default for when there isn't one specified by the player script.

• Points/Graze (partially implemented with -dt, but needs to be shown on the interface and lack handling functions like GetGraze() and SetPoints())

As you mention, the numbers are there, but they're not shown in-game.  This is pretty much just defining where and how they're shown.

• Bombs (altough I could see these being already scripted with some cleverness in player scripts, these probably need a default implementation, too)

Yeah, a default implementation is definitely needed.  Will most likely add a bomb script for this.

• Power system

Planned, based on the discussion that was going down earlier in this thread.

• Plural files, stage files, possibly game files?

Certainly planned.  We need to nail down the formatting for how these'll work ... there were some ideas thrown around earlier, I remember.

• Dialogue events

Planned, although these are probably gonna take back-seat to the more gameplay-related items.

• Lasers

These are gonna be a bit tricky to implement, but I'm sure they'll get in there.

• Effect objects with vertices, possibly 3D drawing (altough I'm not sure if 3D drawing needs to be in the initial release, but that's your call).

I'd say this is lower-priority, but certainly planned at some point.

• User-defined functions/subroutines (tasks can probably be simulated well enough with dummy objects).

Functions are definitely planned.  I do plan on adding tasks later on, but they will work a bit differently than Danmakufu's tasks.

• Inter-object messaging

Already possible via global variables.  I do, however, have plans for an actual implementation of this type of thing specifically.  Probably low priority, though.

• Replays

Of course!  Lower priority, but definitely on the list.
NTSD for MnD hopefully never have the replay problems of its Danmakufu sibling.

• Various bugfixing

Definitely.  Any bugs I can iron out, I will.

• Code optimization to make the program run faster

Definitely planned.  Like I mentioned, the collision routines could use some decent optimization.  Right now, it is pretty good performance-wise (none of the posted scripts have any slowdown, so long as I don't have other stuff running), but better performance is always a good thing to aim for.
Figuring out multi-threading for this project could also fall under this.

• Better error handling

For script errors, definitely.  I plan to give a major overhaul in that area, such that you'll have a better idea of what occurred, including where the error occurred, a decent description of the error that occurred, and probably even a stack trace of where the scripts were.
For program errors, I can look at what further steps can be taken to get good error handling.  I do feel that overall this area is pretty solid already, though.

All I would add to that would be:

• Custom collisions

Could you please elaborate on this?  There is plan to have more than just circle collision types evetually - is that what you're asking for?

• Documentation

SonicBHOC has volunteered to work on this.  Like I mentioned, I've been keeping in touch with him via email.

• More bullet graphics

Of course.  Will probably come with or shortly after the bullet definition files.  The ones in the test releases are just quick samples.  I suck at making graphics anyways.
There's also my idea that would allow the use of one graphic to create bullet graphics of any color, most likely using shaders.

More comments on Musuu no Danmaku itself:

• Needs a sqrt() function

Will need to add in exponent functionality - this'll simply by "X ^ 0.5".

• Or some other way to find the distance between objects

Could be calculated by a script once we have exponents in, but we can also add in a helper function for this.

• Custom Player Shots

You can already script custom player shots by using the Player_Shot base type, much like using Enemy_Shot for a custom enemy shot.

Well, I finished my player early, so here it is.  It's nothing special, but it has a working hit box, startup invincibility, and it re-spawns after 2 seconds.  The hit box, invincibility, and re-spawner are inspired by PT8Sceptile's awesomeface player, but are, for the most part, coded differently.

The Mima sprite sheet came form Johnny Walker's Mima (Mystic Square) touhou danmakufu player script.  If using that was bad, well, I'm sorry!  I won't do it again!

This is pretty cool.

Well, here's my second  danmaku.  Unlike the last one, this one isn't terrible.

This is pretty cool as well.  Nice job with the hackjob plural boss scripting.

Something I noticed: A GetAngleToPlayer() or a GetAngleToObj() function would be really nice.  having to type:

Code: [Select]

if (player_id > -1)
{
xdiff = player_id->x - id->x;
ydiff = player_id->x - id->y;
if (xdiff == 0 && ydiff == 0) ydiff = 1;
angle - atan2(ydiff, xdiff)l
}gets tiring after a while.

I'll keep making stuff.  Have a nice day/night.

I can add a helper function for this.  Only question is - what should be used when there is no player object to get an angle to?  Should we return any specific default value?

Do you have the "Shot" directory?  I thought it came with the Musuu download, but it doesn't seem to have.  I think it was in one of the other test danmaku.  I don't remember which one, though.  If you can't find it, I'll put up a download link to it.

There are no subdirectories in the test release.  The "Shot" directory was added in by someone's scripts (By's, I think).

I actually made them to be used for Danmakufu Musuu No Danmaku scripts.
But i wasn?t expecting anyone to already use them this early... i might try to also make different colored versions of Shot2.png but i used it once and it wasn?t turning (all bullets pointed to the bottom while flying in any direction), preaty much just a bunch of "V"s on the screen.

For shots that rotate, use FireShot01 instead of FireShot01S.  The provided sample script doesn't give a good indication of this, admittedly, since shot2.png is only used with a custom shot currently.

That's pretty much all I can think of in the moment that Musuu needs to obsolete Danmakufu. If I've forgotten something, just add it to the list, and if you consider something on the list too irrelevant/tricky to implement for the first release, feel free to exclude it. This is just something to help people get a better idea on the amount of work left.

...Also, considering that this has been worked on for about half a year pretty much only during weekends, I'm really surprised on how short that list is.

Glad to hear the feedback!

[phi2dao]

Okay, by "Custom Collisions" I just meant letting us script what happens when one object hits another.
I can't remember what I wanted it for though.  Hmm...  It probably wasn't important.

[Nuclear Cheese]

Okay, by "Custom Collisions" I just meant letting us script what happens when one object hits another.
I can't remember what I wanted it for though.  Hmm...  It probably wasn't important.

Writing this off the top of my head, might not be exactly correct:

Code: [Select]

// stuff
{
   // stuff

   collide "SomeObject"
   {
      // do stuff here
   }

   collide_2 "SomeOtherObject"
   {
      // do stuff here
   }

   // stuff
}
The name in quotes can be a specific defined object type, a base type ("Player", "Enemy_Shot", etc), or it can be an empty string ("") to specify collision with all objects (avoid doing that though, it means it collision checks with everything).

collide is a first-size collision (for instance, player gets hit by a bullet), collide_2 is a second-size collision (grazing, for instance).

In these, it automatically defines a local variable called collided_with_id, which gives the ID number of the object that was collided with.


This functionality should be working just fine in the current test release.  Sorry if it hasn't been discussed.

[PT8Sceptile]

Can be done.  Do we want something specifically mirroring CreateShotA, or something similar, but with some differences?

Danmakufu's CreateShotA -system works decently. However, Musuu might be able to get away with less thanks to being able to modify the properties of ordinary non-object shots in the main script just by saving the ID returned by the CreateShot-function in a variable.

Of course.  Need to plan this out a bit, but I'm planning on adding a miss script, for player scripts to take action to animate their "ONOES I DEAD" and such, with a default for when there isn't one specified by the player script.

Sounds good.

Yeah, a default implementation is definitely needed.  Will most likely add a bomb script for this.

Yes. Won't be a major problem since this only needs the same treatment as lives with just a "triggers when X is pressed" -script added to player objects.

Certainly planned.  We need to nail down the formatting for how these'll work ... there were some ideas thrown around earlier, I remember.

Yes, I recall you making a post on how plurals could be done and your plans looked pretty good.

As for stages, a generic "Stage" -object could do this as long as it has the ability to play a plural file. All it really has to do is to draw the backgrounds, spawn the enemies, and start the boss fights.

I assume game scripts refer mainly to menus, which then proceed to play stages when certain menu items are selected. Probably needs a function for startting stages ( PlayStage(stage type, arbitary parameter) where the arbitary parameter is something is a value/array instructing the stage on how does it need to work, like for example determining has it been selected through stage practice or the real game, possibly what difficulty the stage is on etc... ) and some default implementation of a menu (a list of selections maybe, with up moving your selection up in the list and down moving you down, with the scripter being able to draw the menu himself while getting the current selection through some "GetSelection" -function for highlighting the current selection somehow. And in addition to that, scripts "Select" and "Deselect" triggering upon pressing X or Y respectively, altough maybe that isn't necessary since you can just follow these in the main loop with if-statements).

There's just some ideas to work with for starters regarding stages and such.

Planned, although these are probably gonna take back-seat to the more gameplay-related items.

True, since these can be custom-scripted with relative ease too. A default implementation is helpful, but lower priority than those things that are harder to custom-script.

These are gonna be a bit tricky to implement, but I'm sure they'll get in there.

They're pretty much "effect-objectlike bullets" with render-type ADD instead of ALPHA and vertices laid out so that the bullet image is "stretched" in Danmakufu. The same will probably work in Musuu, with possibly an option for a "repeat this graphic" -type laser, too. They just need their own rendering function (or a generic rendering function for effect objects that they use, too), and the collision types. Collision is annoying, though. It has to be an ellipse or a line segment with radius, like was already suggested before. In both cases collision-checking is a bit trickier than simple circular collision checking.

Also, considering collisions, I guess other collision types should be added to the list, too.

I'd say this is lower-priority, but certainly planned at some point.

3D can be of especially low priority, since you can create "3D-like backgrounds" with simple effect objects, too. As for effect objects, I'd assume it's just defining a list of vertices for both the initial image and the background (possibly relative to position like in Danmakufu) and giving those coordinates to GL's vertex-defining function instead of your default rectangular coordinates.

Functions are definitely planned.  I do plan on adding tasks later on, but they will work a bit differently than Danmakufu's tasks.

Well, adding Danmakufu-like tasks would be redundant since dummy objects can do pretty much everything they can, and the object-based programming Musuu's scripting language uses makes them somewhat obsolete.

Already possible via global variables.  I do, however, have plans for an actual implementation of this type of thing specifically.  Probably low priority, though.

...wait? You can define global variables in Musuu? Somehow like this?

Code: [Select]

define GlobalVar

Object "SomeObject" {
   
    initialize {
        //Do stuff to GlobalVar.
        GlobalVar = 5;
    }

}
Object "SomeOtherObject" {
   
    tick {
        //Do some other stuff to GlobalVar
        GlobalVar++;
    }

}

If that's possible, scripting with this just became about a million times more effective.

Also, I have a suggestion regarding the messaging system. Could we define a "dummy property" for each object that could be accessed with the property operator like ObjectID->arg , but doesn't have any direct effects on the behavior of the object like ObjectID->x, ObjectID->y, ObjectID->speed or ObjectID->angle have. This could serve as a simple "messaging system" between objects since you can pass arrays as the variable. This would be especially useful once Musuu can add and remove items in an array like array = array ~ [1] and array = erase(array, 3) in Danmakufu (if that hasn't been implemented yet), since then you could just have an object's dummy property be an array of arrays where you add arrays as "messages" and remove them in the object being messaged to after handling them properly (for example, if you want to inform an object you have made to start firing, you could in the boss object just code: Obj->arg = Obj->arg ~ [["FireStuff"], [true]]; The recipient object sees that the arg-array has an item. Checks arg[0][0], sees that it concerns "Firing stuff", checks arg[0][1], sees it's true, sets a local variable true to instruct it's tick-script to fire stuff, does the same for other "messages" in arg like arg[1][0], arg[2][0] etc... as long as arg has any messages and then cleans arg so that it's an empty array again).

More bullet graphics

Of course.  Will probably come with or shortly after the bullet definition files.  The ones in the test releases are just quick samples.  I suck at making graphics anyways.
There's also my idea that would allow the use of one graphic to create bullet graphics of any color, most likely using shaders.

With image subrects in one could probably already use the existing shotsheets like the CtC one and such.

Also:

A bulletsheet I've been making for my upcoming game I've planned to make with Musuu. It's still not completely finished (it for example lacks big bubble bullets, fireballs, butterflies and stuff like that) but you may use whatever's on it for test script bullets (like I have done with my own test scripts).

Or some other way to find the distance between objects

Could be calculated by a script once we have exponents in, but we can also add in a helper function for this.

Actually, couldn't you currently use (x2 - x1)/cos(atan2(y2 - y1, x2 - x1)) as a workaround? Altough this will definitely be useful as a default function, since it gets used quite often.

You can already script custom player shots by using the Player_Shot base type, much like using Enemy_Shot for a custom enemy shot.

By the way, something about custom player shots that's interesting me: How does one define how much damage they do to the boss aside from using the parameter in the default player shot dreation function? Does that have some function of it's own that can set it or do we just have to custom-code the collide functions to damage the enemy?

I can add a helper function for this.  Only question is - what should be used when there is no player object to get an angle to?  Should we return any specific default value?

I'm suggesting downwards as the default value.

Also, concerning the To-do -list, I guess I forgot a simple item that should be added to it: Drawing functions. While effect objects can do most of the things they can, I'd guess adding them could be a major timesaver when scripting backgrounds. Just something to consider.

[Nuclear Cheese]

Danmakufu's CreateShotA -system works decently. However, Musuu might be able to get away with less thanks to being able to modify the properties of ordinary non-object shots in the main script just by saving the ID returned by the CreateShot-function in a variable.

Alright.  Once we decide exactly what it needed, it can be implemented.

They're pretty much "effect-objectlike bullets" with render-type ADD instead of ALPHA and vertices laid out so that the bullet image is "stretched" in Danmakufu. The same will probably work in Musuu, with possibly an option for a "repeat this graphic" -type laser, too. They just need their own rendering function (or a generic rendering function for effect objects that they use, too), and the collision types. Collision is annoying, though. It has to be an ellipse or a line segment with radius, like was already suggested before. In both cases collision-checking is a bit trickier than simple circular collision checking.

The collision checking is probably the roughest part of implementing lasers ... we need a good model of the laser shape and routines to collision-check it with the same as well as other shapes.  But, of course, we'll get there.

Well, adding Danmakufu-like tasks would be redundant since dummy objects can do pretty much everything they can, and the object-based programming Musuu's scripting language uses makes them somewhat obsolete.

I plan tasks to be a bit different compared to Danmakufu, like I said previously.  I think they'll still be useful for some things, and I'm sure it'll be more convenient in certain situations.

...wait? You can define global variables in Musuu? Somehow like this?

t3h codez

If that's possible, scripting with this just became about a million times more effective.

Almost.  You use the global keyword to define them instead of define.  I did it like this to make the syntax less ambiguous.

Another important note is that a global variable will only be recognized by scripts in a file that define it as a global.  With your example, for instance, if another code references a variable named GlobalVar without declaring it as global, it'll still be a local-scoped variable, even though it is a global defined elsewhere.  This is necessary so that we don't pollute one script's variables by defining globals in another.

Also, I have a suggestion regarding the messaging system. Could we define a "dummy property" for each object that could be accessed with the property operator like ObjectID->arg , but doesn't have any direct effects on the behavior of the object like ObjectID->x, ObjectID->y, ObjectID->speed or ObjectID->angle have. This could serve as a simple "messaging system" between objects since you can pass arrays as the variable. This would be especially useful once Musuu can add and remove items in an array like array = array ~ [1] and array = erase(array, 3) in Danmakufu (if that hasn't been implemented yet), since then you could just have an object's dummy property be an array of arrays where you add arrays as "messages" and remove them in the object being messaged to after handling them properly (for example, if you want to inform an object you have made to start firing, you could in the boss object just code: Obj->arg = Obj->arg ~ [["FireStuff"], [true]]; The recipient object sees that the arg-array has an item. Checks arg[0][0], sees that it concerns "Firing stuff", checks arg[0][1], sees it's true, sets a local variable true to instruct it's tick-script to fire stuff, does the same for other "messages" in arg like arg[1][0], arg[2][0] etc... as long as arg has any messages and then cleans arg so that it's an empty array again).

My plan was to allow a script to define functions that could be called by other script objects, with a syntax something like:
some_other_object_id->message_function(arg);
These would allow you to define object behaviors that can be called upon externally.

Sound like a good idea?

With image subrects in one could probably already use the existing shotsheets like the CtC one and such.

Could, yeah, but it would be better to create our own, so that we're not stealing other people's work.

By the way, something about custom player shots that's interesting me: How does one define how much damage they do to the boss aside from using the parameter in the default player shot dreation function? Does that have some function of it's own that can set it or do we just have to custom-code the collide functions to damage the enemy?

SetLife(#)

Since shots have no need for a life counter, I use the life value for the amount of damage a player shot will do to the enemy.

I'm suggesting downwards as the default value.

Also, concerning the To-do -list, I guess I forgot a simple item that should be added to it: Drawing functions. While effect objects can do most of the things they can, I'd guess adding them could be a major timesaver when scripting backgrounds. Just something to consider.

Ah, right.  Those will be in there.  Shouldn't even be that hard to implement.

[Azure Lazuline]

You could perhaps use my shotsheet when it's done. It was originally made just for my DMF project, but I'd love to see it used elsewhere. It would need to wait until your implementation of actual sheets is supported, though (and PNG alpha channel, if that's not already done).

[anonl]

The collision checking is probably the roughest part of implementing lasers ... we need a good model of the laser shape and routines to collision-check it with the same as well as other shapes.  But, of course, we'll get there.

You can take a look at the TouhouDS source code (specifically src/arm9/collision.cpp). It has functions for circle<->circle, line<->circle and line<->line collision checking. The rest of the code is also pretty well optimized.

[Nuclear Cheese]

You could perhaps use my shotsheet when it's done. It was originally made just for my DMF project, but I'd love to see it used elsewhere. It would need to wait until your implementation of actual sheets is supported, though (and PNG alpha channel, if that's not already done).

It should already support alpha transparency.  As far as support for sheets, it's sort-of there ... to use it right now, you'll need to define a custom enemy shot type so you can set the graphic properties.  Of course, this will change by the time we have bullet definition files.

You can take a look at the TouhouDS source code (specifically src/arm9/collision.cpp). It has functions for circle<->circle, line<->circle and line<->line collision checking. The rest of the code is also pretty well optimized.

Probably is worth a look.  I'll keep this in mind.




Quick update - just added random numbers.  Two functions:

rand() - simply returns a number in the range of [0.0, 1.0)
rand_int(low, up) - returns an integer in the range of [low, up)

Important to note that current implementation, at least, the upper bound on rand_int is a value it won't hit (this is how the underlying command, System.Random.Next(int, int) is implemented).  If there's demand, I can add in code to adjust for this behavior.

[PT8Sceptile]

Almost.  You use the global keyword to define them instead of define.  I did it like this to make the syntax less ambiguous.

Another important note is that a global variable will only be recognized by scripts in a file that define it as a global.  With your example, for instance, if another code references a variable named GlobalVar without declaring it as global, it'll still be a local-scoped variable, even though it is a global defined elsewhere.  This is necessary so that we don't pollute one script's variables by defining globals in another.

This will be ridiculously useful...

My plan was to allow a script to define functions that could be called by other script objects, with a syntax something like:
some_other_object_id->message_function(arg);
These would allow you to define object behaviors that can be called upon externally.

Sound like a good idea?

Well that pretty much does the same thing. These will also be really useful once implemented.

SetLife(#)

Since shots have no need for a life counter, I use the life value for the amount of damage a player shot will do to the enemy.

*PT8 suddenly remembers all the positive side-effects of having a good documentation.

Clever. However, no-one is going to figure that out on their own without some serious looking through the code...

It should already support alpha transparency.  As far as support for sheets, it's sort-of there ... to use it right now, you'll need to define a custom enemy shot type so you can set the graphic properties.  Of course, this will change by the time we have bullet definition files.

Wait what?

Code: [Select]

SetObjImgRect(FireShot01S(GetX(), GetY(), angle + tcount/2/90*pi + pi, 2, "sheet.png"), 16*8, 16*8 + 16, 0, 16);
All that is needed to get a specific bullet image out of a shotsheet is one line of code like this (it does, however, get a bit repetitive having to type all of this in so I'm eagerly waiting for the bullet definition files).

Quick update - just added random numbers.  Two functions:

rand() - simply returns a number in the range of [0.0, 1.0)
rand_int(low, up) - returns an integer in the range of [low, up)

Important to note that current implementation, at least, the upper bound on rand_int is a value it won't hit (this is how the underlying command, System.Random.Next(int, int) is implemented).  If there's demand, I can add in code to adjust for this behavior.

At last! These have been long waited for! Both implementations are fine for me.

Also:

• Bullet definition files
• Additional functions for:
• Random numbers
• Some more mathematical functions like the power function.
• The drawing functions.
• Improved audio control (loop points, pausing/resuming, possibly fadein/fadeout)
• Improved bullet shooting functions like CreateShotA to avoid having to script overtly simple patterns with objects
• Default support for:
• Lives/respawning
• Points/Graze
• Bombs
• Power system
• Plural files, stage files, possibly game files?
• Lasers
• User-defined functions/subroutines/tasks.
• Message functions for objects.
• Various bugfixing
• Code optimization to make the program run faster
• Better error handling
• *Low priority* Dialogue events.
• *Low priority* Effect objects with vertices, 3D drawing.
• *Low priority* Replays.

List updated based on whatever had been mentioned (low priority stuff marked, draw functions and math functions like the mentioned square root added, inter-object messaging changed to the object message function idea you have and random function striked over to signify being ready).

[Theme97]

Holy hell, it's been a while.

I've been busy lately and I stopped getting thread notifications, so this was pretty much left forgotten for a while.

At any rate, just wanted to say I'm not dead yet. I might not be able to do much for now, but I'm definitely going to try and get back into this.

Edit:

• Some more mathematical functions like the power function.
• Improved audio control (loop points, pausing/resuming, possibly fadein/fadeout)

I was working on these before I up and disappeared, so I can probably dig those back up.

[Nuclear Cheese]

*PT8 suddenly remembers all the positive side-effects of having a good documentation.

Clever. However, no-one is going to figure that out on their own without some serious looking through the code...

Yeah, that's one thing we certainly need to work on.  Like I said, sonicbhoc is looking at it.

Wait what?

Code: [Select]

SetObjImgRect(FireShot01S(GetX(), GetY(), angle + tcount/2/90*pi + pi, 2, "sheet.png"), 16*8, 16*8 + 16, 0, 16);
All that is needed to get a specific bullet image out of a shotsheet is one line of code like this (it does, however, get a bit repetitive having to type all of this in so I'm eagerly waiting for the bullet definition files).

... derp.  I forgot that function takes an ID parameter.  Go me.





Some quick progress tonight:
I refactored the function list code such that it explicitly defines the argument list for each function.  It doesn't give any visible changes in functionality right now, but it'll be necessary for implementing user-defined functions later on.

[Dizzy H. "Muffin" Muffin]

Can I make a suggestion? Don't use "life" for "this is how much damage it does" -- what if you want a shot to keep going after it hits something, and you want to specify "number of times the shot can hit something before dying"?

[Nuclear Cheese]

Can I make a suggestion? Don't use "life" for "this is how much damage it does" -- what if you want a shot to keep going after it hits something, and you want to specify "number of times the shot can hit something before dying"?

The you'll have to override the default "player shot collides with enemy" function anyways, since that not only deals out damage, but also deletes the shot.

A default "penetrating" shot can be added in as well, but I'd think there's a fair amount of potential for variety in that category, so custom implementations are probably gonna be necessary in some cases.

[Shockman]

you should also make different scoring systems available like normal bombing, MoF style power, and UFOs.

[arcanesign]

For documentation, you may want to skim through these articles, I found them helpful:

http://jacobian.org/writing/great-documentation/

[SupahVee1234]

Didn't feel like reading the whole thread, but are the shotsheets like in Danmakufu, or it's just a colour and you change Hue via code?

[Nuclear Cheese]

you should also make different scoring systems available like normal bombing, MoF style power, and UFOs.

There is plan to have a flexible power/bomb system in place.  It was discussed a few pages back.  We'll still need to nail down the exact details, but effectively a game script will be able to set the power/bomb item values and costs for bombing, etc.

For documentation, you may want to skim through these articles, I found them helpful:

http://jacobian.org/writing/great-documentation/

This looks like it could be useful.

btw - any luck on getting the latest test release to run?  Sorry I can't provide any advise or other help, but like I said I don't really have any applicable expertise when it comes to 'nix systems.

Didn't feel like reading the whole thread, but are the shotsheets like in Danmakufu, or it's just a colour and you change Hue via code?

Right now, bullet graphics are simply loaded as images.  It is possible to use a subrect of an image for a shot graphic, albeit a bit messy code-wise currently.

The plan is to give the scripter the ability to custom-define bullet data (image, hitbox, etc) using a script file.  This has not yet been implemented, however.

I also have an idea that will allow a scripter to provide a single bullet image (color-keyed) which the program can then use to create bullet graphics in that shape of any color on-the-fly.  This'll probably come later on, but if it works out like I think it will, it'll reduce graphic file memory consumption on disk as well as texture memory consumption.

[phi2dao]

If you could put out another test release with the random number functions or something, I would really appreciate it.  I've been trying to think of cool danmaku to create, but they all work best with random numbers.

[Nuclear Cheese]

If you could put out another test release with the random number functions or something, I would really appreciate it.  I've been trying to think of cool danmaku to create, but they all work best with random numbers.

I can look at putting together another test release this weekend.  Can't do it sooner since I'm too busy between work and other commitments (like usual >__>).

[phi2dao]

That's fine.  Don't stress yourself.

EDIT:
I just noticed that the Useful Miscellaneous Code Snippets thread seems to have a get distance to line segment function that could be used for laser collisions if you don't already have an idea on how to do that.

[Nuclear Cheese]

Incoming new stuff.  w00t!


I just finished implementing shot definition files.  It's pretty simple and straightforward:

Code: (shots.txt) [Select]

Musuu
Script[mdBullet]
Type[Shot]

shot Shot1
image shot1.png
size1 5.5
size2 7.5
rotate false

shot Shot2
image shot2.png
size1 5.5
size2 7.5
rotate true
rect_x1 0
rect_x2 -1
rect_y1 0
rect_y2 -1

It should be pretty straightforward, but here's a description anyways:

• shot - starts the definition of a new shot type, with the given name
• image - sets the shot's image
• size1 and size2 - sets the shot's collision sizes
• rotate - sets if the shot rotates with its angle or not
• rect_* - sets the image subrect.  Note that -1 is a shortcut to the highest coordinates in the image file.

Once this is set up, you simple need to include the shot description file as such in your script:

Code: (TheEnemy.txt) [Select]

Musuu
Name[Sample Enemy]
Type[Enemy]

// include the shot definitions
include("shots.txt");

// TheEnemy
// Enemy boss that makes some fucking danmaku.
Boss "TheEnemy"
{
   // etc ...

And then, when using FireShot01, instead of an image file name, give the shot type name defined in the file, such as:
FireShot01(id->x, id->y, angle, 2.5, "Shot1");

This will automatically pull the necessary details of the shot and apply it to the shot.

You can also use this setup for custom shots - in your custom shot scripts init, add a call to the function SetShotInfo("shottype") and it will load the same parameters to the object.



Note that I've removed the function FireShot01S, since its functionality is no longer necessary.



With that, here's Test Release 5.

Download is here.

In addition to the above-mentioned bullet definitions, there are also the random number functions added, and this time around I borrowed a couple of KimikoMuffin's sound effects for use as samples.

[phi2dao]

Awesome!  I can't wait to write danmaku using rand()...

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.

Thats all for now, expect some more danmaku from me soon!

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