A replacement for Danmakufu?

[Dizzy H. "Muffin" Muffin]

Then I shall concern myself no further with the Braid idea. (I'd imagine that it has something to do with "everything is fugging deterministic" and built an engine specifically for time-reversal shennanigans.)

I think "start from arbitrary point in music" would be highly useful, though. I suspect one of the reasons ZUN made you start over levels when you used a continue in MoF (the first game to feature game-over music) was that he couldn't be assed to add support for "stop music A, play music B, then stop music B and possibly resume A from where it left off."

Hmm. I'm toying with other ideas, such as (basically) Variable Mix _{(beware, TVTropes)} but, um, it can wait.

[Nuclear Cheese]

Then I shall concern myself no further with the Braid idea. (I'd imagine that it has something to do with "everything is fugging deterministic" and built an engine specifically for time-reversal shennanigans.)

Either everything needs to be, as you said, deterministic, such that the game engine could calculate the rewind, or you'd literally need to save the game's state at a regular interval (ideally every frame, but that would probably be overkill), such that you can "rewind" by loading up an earlier state.  Given the user-scripted nature of a project like Musuu, the latter would probably be the only "reasonable" option.



A bit of progress today - I added in support for traversing directories in the menu.  This almost finishes up support for multiple directories, except it doesn't properly set up paths yet when loading and playing sound files.  Unfortunately, I'm a bit too fried to work at that one tonight, so it'll have to wait until next weekend or so.

The way it is right now, the program can traverse to any directory - it lists directories in a light green color in the menu (to distinguish them from the files, which are a light blue), and you just select one to change to that directory.  You can also indicate different paths for included scripts and images, and it'll act accordingly.

The way it works, effectively, is that each loaded object type is labelled with the directory of the file it is loaded from.  That directory is used as the base directory for all file references made in that type's scripts.


Finally, I should emphasize at this point that people should use the forward slash ("/") to separate directory names in a path, rather than the backwards slash ("\").  The backwards one is only used as such on Windows platforms, while the forwards one works on all platforms (that I know of, anyways).  Using the forward slash should ensure that scripts will work properly on all platforms.

While I'm on the topic of platform-independant file access, I'd also like to remind you that some operating systems have case-sensitive file naming; some others don't.  Script accordingly.

[phi2dao]

It took me long enough, but I finally made a shot script for the shot sheet posted earlier.  Here it is.  The .rar contains the shot sheet, the shot script, and the ruby program that I used to create the shot script.

To use this, just unpack it in your Musuu folder, and put

Code: [Select]

include("sheet.txt") in your Musuu script.

NOTES:  There is something weird with how Musuu selects rectangles.  Sometimes colors bleed into each other.  I think the problem isn't on my end though.

PS: I actually have ideas for Danmaku, so I might actually post something sometime soon!

[SupahVee1234]

Hey Nuclear, I'm trying to make my own Danmakufu-clone with C#, SFML and LuaInterface, but I can't figure out how to implement a "yield / wait" function in my scripts. Do you run the script in a separate thread? How do you handle the wait function?  :blush:

[anonl]

I'm trying to make my own Danmakufu-clone with C#, SFML and LuaInterface, but I can't figure out how to implement a "yield / wait" function in my scripts.

I used LUA in TouhouDS -- you can implement yield using lua threads and coroutine.yield()

[Nuclear Cheese]

It took me long enough, but I finally made a shot script for the shot sheet posted earlier.  Here it is.  The .rar contains the shot sheet, the shot script, and the ruby program that I used to create the shot script.

To use this, just unpack it in your Musuu folder, and put

Code: [Select]

include("sheet.txt") in your Musuu script.

NOTES:  There is something weird with how Musuu selects rectangles.  Sometimes colors bleed into each other.  I think the problem isn't on my end though.

PS: I actually have ideas for Danmaku, so I might actually post something sometime soon!

The color bleeding issue probably has something to do with the blending function - it sounds like it's starting to blend into the next pixel on the image.  I might be able to tweak the texture coordinates slightly to fix this (in the engine code), but if nothing else it could most likely be solved by just adding a one or two pixel of empty buffer zone between each bullet image.

Hey Nuclear, I'm trying to make my own Danmakufu-clone with C#, SFML and LuaInterface, but I can't figure out how to implement a "yield / wait" function in my scripts. Do you run the script in a separate thread? How do you handle the wait function?  :blush:

Musuu no Danmaku doesn't have separate script tasks, nor does it have the yield/wait functions.  There are plans to implement such, however, and if I remember correctly there was an idea how to do it earlier in the thread (although it may be more applicable to my custom script engine than your Lua-based one).

As far as running scripts in separate threads - this can get really ugly.  If you have multiple threads running scripts, you lose deterministic behavior, since you can't be guarenteed that one thread will finish processing X before or after another thread finished processing Y.  Right now Musuu runs everything in a single thread; there was talk of moving the rendering side of things to a separate thread, but that's on the backburner for now.


(PS - how many Danmakufu clones in progress are there?  Mine, Blargel's, SupahVee's, ... did I start a fad or something? :/)



Multiple directory support is FINALLY done in MnD.  Took me far too much longer than it should have, but it should work fine now.

I moved point_item.png into a subdirectory called basic, which will be the place to store common engine assets (now that I think about it, the background image should probably go there, too).


Once again, I must emphasize that, when writing in any directory names, scripters should use the forward slash ('/') instead of the backward slash ('\') to ensure cross-platform compatibility.

[Nuclear Cheese]

Hey again people.  Just bumping in here to mention that I've started working on updated script error reporting code.

Right now it has specific error messages for the following conditions:

• Attempt to read the value of an undefined value or constant
• Attempt to call an undefined function
• Attempt to give an invalid parameter when calling a function (for instance, something like: UseRadians("lol");)

The way it is right now, you can only get the full error description in the log file - the menu only shows a one-liner indicating the outermost script from which the error occurs.  My current plan is to add a button press or option in the menu that will allow the user to see the full info from the last script error that occured, and maybe also to save that info to a file.


The error reports look something like this (not exact, as the reporting isn't final):

Error in TheEnemy.initialize ...
Variable not defined: some_other_stuff

It will retain call stack information, so scripters will have a bit more context to help them debug their scripts.


There's still some work to do with it, though.  At the very least, it still needs messages for when it can't load a file (image, sound, music, etc) and when it hits the infinite-loop protection.  Am I missing other ones?


On the bright side, I've got some extra time this week, so I might be able to get something done before the next weekend.


EDIT:

So much for that extra time ...
Work, finding out my website hosting expired, work, L4D, work, ... oh right MnD! :derp:


Got some more done with the error reporting tonight.  It will now also create error messages if you try to load a non-existant file (image, sound, or music) as well as if you hit the infinite loop protection.
To note - since the image files are loaded right when they're needed in the graphics engine, rather than during script execution, the code can't (currently, at least) give script context for a missing image file.

I also moved the code that spawns the initial player and enemy objects so that it runs on the first game tick, rather than right after it finishes loading everything in the menu.  This shouldn't have any visible effects, but it makes things more straightforward in the code (and gets rid of a bit of duplicated code).


Still need to get the "hey here's that error you just had" option into the menu, but then I think the new error reporting scheme is pretty much good to go for the time being.



Oh, crazy idea I just had while typing this - in addition to the option of saving the error report like described above, perhaps I could also add the option of saving the complete game state to a file.  This would mainly include a listing of all objects currently in the game (position, image, type, object variables, ...) as well as global variables and, once they're implemented, similar information for tasks.

[PT8Sceptile]

Oh, crazy idea I just had while typing this - in addition to the option of saving the error report like described above, perhaps I could also add the option of saving the complete game state to a file.  This would mainly include a listing of all objects currently in the game (position, image, type, object variables, ...) as well as global variables and, once they're implemented, similar information for tasks.

This sounds really interesting and potentially useful. Once this thing has gotten to a somewhat stable point definitely experiment with that.

Checklist update:

• 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 (mostly done)
• *Low priority* Dialogue events.
• *Low priority* Effect objects with vertices*, 3D drawing.
• *Low priority* Replays.

*Concerning lasers, they need 3 things to match DMF:s
- Elliptical/line segment with radius/some other laserlike collision type.
- Stretching effect similar to verticed effect objects.
- ADD rendering.

Number two somehow suggests that verticed effect objects should be higher than low priority, even if 3D certainly is such. Another assistive feature is that they are something that OpenGL practically does for us, the only things required are creating a list of vertices and a variable to save the vertice data interpretion type (for example, TRIANGLEFAN, TRIANGLESTRIP, or the one MnD is currently using in it's draw function: QUADS). Then just add a new draw function or modify the existing one to use vertice data instead of rectangle bounds, and scripting functions to modify these variables.

Collision is however tricky: It's quite easy to approximate elliptical collision, but getting exact results is most certainly not easy. This raises the question of how accurate should MnD:s collisions be (since more accuracy means less efficience). This is especially problematic with small elliptical bullets because there are often hundreds of objects on the screen and if most of them were elliptical, using accurate collision checking methods without a lot of pruning first may result in a noticeable performance drop.

[Azure Lazuline]

Danmakufu's lasers use line segment collision, not elliptical collision. Or at least, I think they do. Either way, it would be nice to have that option - that will work much better for long, thin lasers than an elliptical collision box would. You could perhaps have that plus two types of elliptical collision (accurate/efficient), even if that gets a bit complicated; that way every situation is handled and the only downside is having an extra parameter in the shot definition file or laser-creation function (which you could even overload so it's not always needed).

[SupahVee1234]

Uh, are you looking for another programmer? I don't really like working alone on a big project.

So, can I give you a hand?  :ohdear:

[Nuclear Cheese]

*Concerning lasers, they need 3 things to match DMF:s
- Elliptical/line segment with radius/some other laserlike collision type.
- Stretching effect similar to verticed effect objects.
- ADD rendering.

Number two somehow suggests that verticed effect objects should be higher than low priority, even if 3D certainly is such. Another assistive feature is that they are something that OpenGL practically does for us, the only things required are creating a list of vertices and a variable to save the vertice data interpretion type (for example, TRIANGLEFAN, TRIANGLESTRIP, or the one MnD is currently using in it's draw function: QUADS). Then just add a new draw function or modify the existing one to use vertice data instead of rectangle bounds, and scripting functions to modify these variables.

Collision is however tricky: It's quite easy to approximate elliptical collision, but getting exact results is most certainly not easy. This raises the question of how accurate should MnD:s collisions be (since more accuracy means less efficience). This is especially problematic with small elliptical bullets because there are often hundreds of objects on the screen and if most of them were elliptical, using accurate collision checking methods without a lot of pruning first may result in a noticeable performance drop.

Based on the discussion earlier, we're going to go with a line segment-based collision setup for lasers, with some algorithm to check if something is within X distance from a line segment (or if two line segments are within X distance of each other) ...

Uh, are you looking for another programmer? I don't really like working alone on a big project.

So, can I give you a hand?  :ohdear:

The google code page is here.  Take a look at the codebase - if you're up to it, I can add you to the developer list.



Sorry, no new progress today since I instead decided to go and buy a new computer.  Silly me. :3

[Nuclear Cheese]

Bumping to let you guys know that the error handling code is in place and checked into the codebase.

The way it works is as follows:

• When a script error occurs, it dumps you back to the menu.
• There is a new entry in the menu, "Error Information".  This will persist until you either start up a new script or exit the program
• Selecting "Error Information" will give an overview of the error that occured, including the script stack
• Pressing SHOT will save the overview information to a file.  Holding SLOW and pressing SHOT will save a full dump of all game information.

I decided to just go ahead and implement my full-dump idea from before, since it wasn't much more than I was already implementing.


The overview looks something like this:

Code: [Select]

Error in TheEnemy.tick ...
Error in PlaySfx ...
Attempted to load unknown file: C:\Documents and Settings\NuclearCheese\My Documents\Visual Studio 2005\Projects\Musuu no Danmaku\Musuu no Danmaku\bin\Debug\Shot9001.wav
(sample is from a script I wrote to test error handling, which deliberately tries to load a non-existant sound file)

What this gives is a simple stack trace of the script execution, up to where the error occurred.

The full dump looks like this:

Code: [Select]

Error in TheEnemy.tick ...
Error in PlaySfx ...
Attempted to load unknown file: C:\Documents and Settings\NuclearCheese\My Documents\Visual Studio 2005\Projects\Musuu no Danmaku\Musuu no Danmaku\bin\Debug\Shot9001.wav

Object types loaded:
BasicEnemyShot
BasicPlayerShot
PointItem
TheEnemy
EvilShot
AnotherPlayer


Globals:
- point_value [Number_Literal] = 10000


Objects:

0 - TheEnemy
Location: (243, 100)
Angle: 0
Speed: 0
Life: 146.7 / 150
Image: C:\Documents and Settings\NuclearCheese\My Documents\Visual Studio 2005\Projects\Musuu no Danmaku\Musuu no Danmaku\bin\Debug\reimu1.png
Local variables:
- parameters [Array] containing 5 entries
  - entry 1 [String_Literal] = reimu1.png
  - entry 2 [Number_Literal] = 60
  - entry 3 [Number_Literal] = 0.5
  - entry 4 [Number_Literal] = 150
  - entry 5 [Number_Literal] = 75
- num_bullets [Array] containing 4 entries
  - entry 1 [Number_Literal] = 3
  - entry 2 [Number_Literal] = 7
  - entry 3 [Number_Literal] = 5
  - entry 4 [Number_Literal] = 7
- num_bullets_index [Number_Literal] = 1
- count [Number_Literal] = 60
- move [Number_Literal] = 0.5

1 - AnotherPlayer
Location: (241, 379)
Angle: 0
Speed: 0
Life: 0 / 0
Image: C:\Documents and Settings\NuclearCheese\My Documents\Visual Studio 2005\Projects\Musuu no Danmaku\Musuu no Danmaku\bin\Debug\test1.png
Local variables:
- count [Number_Literal] = -7

5 - BasicPlayerShot
Location: (241, 152)
Angle: 0
Speed: 8
Life: 1.1 / 1.1
Image: C:\Documents and Settings\NuclearCheese\My Documents\Visual Studio 2005\Projects\Musuu no Danmaku\Musuu no Danmaku\bin\Debug\player_shot1.png
Local variables:

6 - BasicPlayerShot
Location: (241, 192)
Angle: 0
Speed: 8
Life: 1.1 / 1.1
Image: C:\Documents and Settings\NuclearCheese\My Documents\Visual Studio 2005\Projects\Musuu no Danmaku\Musuu no Danmaku\bin\Debug\player_shot1.png
Local variables:

7 - BasicPlayerShot
Location: (241, 211)
Angle: 0
Speed: 8
Life: 1.1 / 1.1
Image: C:\Documents and Settings\NuclearCheese\My Documents\Visual Studio 2005\Projects\Musuu no Danmaku\Musuu no Danmaku\bin\Debug\player_shot1.png
Local variables:

8 - BasicPlayerShot
Location: (241, 251)
Angle: 0
Speed: 8
Life: 1.1 / 1.1
Image: C:\Documents and Settings\NuclearCheese\My Documents\Visual Studio 2005\Projects\Musuu no Danmaku\Musuu no Danmaku\bin\Debug\player_shot1.png
Local variables:

9 - BasicEnemyShot
Location: (243, 100)
Angle: 2.36336282618944
Speed: 2.5
Life: 0 / 0
Image: C:\Documents and Settings\NuclearCheese\My Documents\Visual Studio 2005\Projects\Musuu no Danmaku\Musuu no Danmaku\bin\Debug\shot\shot1.png
Local variables:
- this_bullet_grazed [Boolean_Literal] = False

10 - BasicEnemyShot
Location: (243, 100)
Angle: 3.14876098958689
Speed: 2.5
Life: 0 / 0
Image: C:\Documents and Settings\NuclearCheese\My Documents\Visual Studio 2005\Projects\Musuu no Danmaku\Musuu no Danmaku\bin\Debug\shot\shot1.png
Local variables:
- this_bullet_grazed [Boolean_Literal] = False

11 - BasicEnemyShot
Location: (243, 100)
Angle: 3.93415915298433
Speed: 2.5
Life: 0 / 0
Image: C:\Documents and Settings\NuclearCheese\My Documents\Visual Studio 2005\Projects\Musuu no Danmaku\Musuu no Danmaku\bin\Debug\shot\shot1.png
Local variables:
- this_bullet_grazed [Boolean_Literal] = False

In addition to the overview, you get information on all loaded types, global variables, and the details for every individual object currently in the game.  It can get to be a lot of information, but I can see it helping scripters debug their scripts.

[phi2dao]

Could you release a new version with all of this new stuff?  Or tell me how I could compile it myself?

[PT8Sceptile]

Could you release a new version with all of this new stuff?  Or tell me how I could compile it myself?

For compiling it yourself (this is at least what I've done and succeeded in doing, but I'm no expert on C# stuff, so someone else might know an easier way or better programs for the job):

1. Get the necessary programs: A SVN client (I used TortoiseSVN), a C# Compiler/IDE (in my case SharpDevelop) and a tool for converting the ANTLR file into C# (again in my case, ANTLRworks). Install whichever ones need installing
2. Create a folder where you'll store the code and use the SVN client to checkout a copy of the code into the folder.
3. Use whichever ANTLR tool you have to convert the mdScript_to_mdBase.g -file into the C# lexer/parser files (they should have a similar file extension as the other code files).
4. Open up the IDE and then either:
  4a. Use one of the preconfigured project files. The repository seems to have some for Visual studio and they may work, but seeing as I used SharpDevelop, I can't really give you advice on them.
...or if that doesn't work:
  4b. Create a new project for Musuu. Add all the files you checked out with SVN into your project files. Then, add all the .dll -files distributed with Musuu, including the SDL.NET -dll you probably have installed on your computer to get Musuu working, into your project references.
5. Compile. It should show some warning/ToDO - messages, but if there are no errors that prevent compiling, you've probably succeeded.
6. Take the compiled file and put it into the Musuu folder (don't delete the old one incase the new one doesn't work for some reason). Run the file.

Afterwards when updating, you only need to do a SVN-update to your files, reconvert the .g -file, add any new files into your list (if you're not using an existing project file), add any new .dlls (again, if you're not using the existing project files) and compile.

I've succeeded in this, so it certainly should work in compiling the files, but I can't guarantee that I can remember every single step I've taken (at least I haven't had to edit the files at all, though). Again, if anyone knows an easier way or better programs to use, go ahead and correct me.

[Nuclear Cheese]

Could you release a new version with all of this new stuff?  Or tell me how I could compile it myself?

I could put together a new testing release later in the week or the weekend.  Too busy with work and family stuff during the week (fortunately, it looks like this'll start taking less of my time soon).

For compiling it yourself (this is at least what I've done and succeeded in doing, but I'm no expert on C# stuff, so someone else might know an easier way or better programs for the job):

1. Get the necessary programs: A SVN client (I used TortoiseSVN), a C# Compiler/IDE (in my case SharpDevelop) and a tool for converting the ANTLR file into C# (again in my case, ANTLRworks). Install whichever ones need installing
2. Create a folder where you'll store the code and use the SVN client to checkout a copy of the code into the folder.
3. Use whichever ANTLR tool you have to convert the mdScript_to_mdBase.g -file into the C# lexer/parser files (they should have a similar file extension as the other code files).
4. Open up the IDE and then either:
  4a. Use one of the preconfigured project files. The repository seems to have some for Visual studio and they may work, but seeing as I used SharpDevelop, I can't really give you advice on them.
...or if that doesn't work:
  4b. Create a new project for Musuu. Add all the files you checked out with SVN into your project files. Then, add all the .dll -files distributed with Musuu, including the SDL.NET -dll you probably have installed on your computer to get Musuu working, into your project references.
5. Compile. It should show some warning/ToDO - messages, but if there are no errors that prevent compiling, you've probably succeeded.
6. Take the compiled file and put it into the Musuu folder (don't delete the old one incase the new one doesn't work for some reason). Run the file.

Afterwards when updating, you only need to do a SVN-update to your files, reconvert the .g -file, add any new files into your list (if you're not using an existing project file), add any new .dlls (again, if you're not using the existing project files) and compile.

I've succeeded in this, so it certainly should work in compiling the files, but I can't guarantee that I can remember every single step I've taken (at least I haven't had to edit the files at all, though). Again, if anyone knows an easier way or better programs to use, go ahead and correct me.

This sounds about right for a general-case.  One thing to note, though, is that I read that SharpDevelop can read Visual Studio project files - not sure if it requires anything special myself, since I mainly use Visual C# Express.

To note, the main project file was made in Visual C# Express 2005; there is also a project file from 2008 in the repository as well.

[PT8Sceptile]

One thing to note, though, is that I read that SharpDevelop can read Visual Studio project files - not sure if it requires anything special myself, since I mainly use Visual C# Express.

To note, the main project file was made in Visual C# Express 2005; there is also a project file from 2008 in the repository as well.

I've tried opening the main project file once (they had the same file extension as the project files SharpDevelop saves, so I thought it might have a chance of working), but unfortunately it was unable to open it properly. Haven't tried with the 2008 one, though.

But whatever, I've got my workarounds working so the project file isn't really an issue. More like a convenience if it actually decided to work.

[Foremoster]

I dream of a drag and drop system. Kinda like RPG maker.
Sticks and stones can break my bones, but words may hurt your brain :derp:
" eh wonder how that will work "

[GenericTouhouFailure]

I know I'm being a complete ⑨ for:
1. Not searching this thread for a Downloadz link hard enough
2. not understanding how the heck am I supposed to "Edit the /Library/Frameworks/Mono.framework/Versions/Current/etc/mono/config file to include the entries from the SdlDotNet.dll.config and Tao.Sdl.dll.config files." what the shit do i add?!? *internal raging from unability of running danmaku*

Ps: this mac user has sum ugly as fuck star graphics that causes puking (made for a danmaku test project in flash)
comes in 7 colors (take a look first)

[Nuclear Cheese]

I dream of a drag and drop system. Kinda like RPG maker.
Sticks and stones can break my bones, but words may hurt your brain :derp:
" eh wonder how that will work "

You mean a way to just drag-and-drop to design danmaku patterns?  I believe there was another project around here to do that for Danmakufu scripts, but (unless I missed sometihng) there isn't such a thing for Musuu no Danmaku yet.  At this point the main focus is getting the game engine itself in working order with all of its desired features, but if someone wants to take a shot at desiging such a program for MnD (or if they want to add to/modify the aforementioned Danmakufu-targetting program to work with MnD as well), feel free to give it a go.

I know I'm being a complete ⑨ for:
1. Not searching this thread for a Downloadz link hard enough
2. not understanding how the heck am I supposed to "Edit the /Library/Frameworks/Mono.framework/Versions/Current/etc/mono/config file to include the entries from the SdlDotNet.dll.config and Tao.Sdl.dll.config files." what the shit do i add?!? *internal raging from unability of running danmaku*

Download links generally are found on the Google Code page for this project.  I also post links for individual Test Releases as they are releases.

Spoiler:

(such as below)

As far as configuring Mono for whatever, I'm not particularly familiar with that end of things, since I don't use Mono myself, but I know some people around here have run this program with Mono - perhaps they can help?
My understanding is that, once you have Mono installed, you'd just need to navigate to the directory you unzip'd the Musuu no Danmaku files into and run it something like:
mono "Musuu no Danmaku.exe"

... I could be wrong on that, though. :/



Test Release 6

Now contains directory navigation and support for multiple directories, as well as much improved script error handling and reporting.

[Nuclear Cheese]

Hey guys, remember me?

I've been a bit busy the past few weeks, so there hasn't been any updates.  But that all changes today!

I just added in support for lives and respawning.  It works as follows:

• There is a new command, HitPlayer, which causes a miss on the player (this is already set up in the default scripts for objects that normally kill the player).
• There is a new script type, miss, which will be triggered whenever the above function is called.  While it is normally only meant for the player object, it can be used on any type of object.
  The main intention of this script is to set up whatever is necessary to animate the player character dissapearing/exploding/etc., but you could also use it for other silly things, such as having the boss stop to taunt you. :3
• There is another new command, RespawnPlayer, which subtracts a life from the player and respawns them if they have any lives remaining.
  Right now, it just deletes the current Player object and creates a new one.
• Finally, there is a third new function, SetPlayerInvul, which sets the number of frames the player is invulnerable (starting immediately).
  This invulnerability period stops the game from calling any miss scripts like it normally would as mentioned above.

The way this is designed to be used is something like this:

• The Player object type defines a miss script.  In this script, it sets up the player object to animate it getting killed.
  
  • Right now, this animation needs to be done in the tick script for the object, but once tasks are implemented it could be handled there as well.
  • Note that this script should also set it so the object no longer moves with player input, and sets a flag to disable it from shooting.  That is, unless you want your player script to still be able to move and shoot as it is dieing.
  • Also, make sure that the miss script disables collision with the player (by using SetSize(0,0);) ... otherwise, the program might keep detecting collisions and restarting the death animation over and over again (it may be worthwhile to add in-code logic to prevent this)
• When the player's death animation script has run its course, it will then call RespawnPlayer and SetPlayerInvul to reset the player.

While this approach is a bit more cumbersome than Danmakufu's, it allows player scripts to give customize miss animations and such.


Right now, the default script I put in there just respawns the player immediately, with 300 frames of invulnerability.  But I put in custom scripts into the two sample player scripts, which has them freak out in place for 90 frames (set the image to a random angle every frame) before respawning with 240 frames of invulnerability.


I'm planning to do something similar with bomb scripts by adding a bomb script that gets called whenever the player hits the bomb button (inventory and "no-bomb" settings notwithstanding).




Also, I added in text display of score, graze, lives, and bombs while in-game.  Yay. :V

[Mjonir]

Sorry for not reacting to what you just posted, but I've got a general question:

Are you creating a new scripting language from the bottom up, or are you using parts of an existing language ?


If you're making a new one (I think it's the case), what were your reasons not to use an existing one?

[Nuclear Cheese]

Sorry for not reacting to what you just posted, but I've got a general question:

Are you creating a new scripting language from the bottom up, or are you using parts of an existing language ?


If you're making a new one (I think it's the case), what were your reasons not to use an existing one?

This engine has its own scripting languages, which were created from scratch.

The main one is mdScript, which is a script language using a C-like syntax, and is somewhat similar to what is used in Danmakufu's scripts.
This is interpreted using a parser built in ANTLR.  You can see the source on the Google code page - it's the file with the .g extension.  When an mdScript file gets read in, it is converted to mdBase, which is an internal script language used by the code itself during script execution.

There is also mdBullet, which is used for defining custom bullet information.
This has a simple enough syntax that it I just have code that interprets it directly.


The reasons I went down the path of creating a new scripting language are pretty simple:

• Creating our own script language allows us to custom-tailor it to our purposes.
• If something is broken in our scripting language, we can simply fix it, whereas if something is broken in someone else's script language, we'd need to rely on them to fix it (might not be entirely true, given the amount of open-source projects out there today).  This also applies to new features to be added into the scripting language.
• Call me crazy if you must, but I actually found it easier to set up my own scripting language than to use someone else's.

There's also the idea that, once the engine is more complete, we could add in support for other scripting languages as well (Lua has been brought up a few times in this thread, and the idea of reading Danmakufu scripts has appeared at least once or twice).

[Mjonir]

Thank you very much for your complete reply, I'll probably have a closer look at how it works later now that I get the idea

If something is broken in our scripting language, we can simply fix it, whereas if something is broken in someone else's script language, we'd need to rely on them to fix it (might not be entirely true, given the amount of open-source projects out there today).  This also applies to new features to be added into the scripting language.

I was told Lua was very easy to tweak and very reliable. For example somebody told me that an infinite loop protection would only require 5 added lines of code into Lua.

Call me crazy if you must, but I actually found it easier to set up my own scripting language than to use someone else's.

You're not, I also had this idea at first... and when I first looked at the principles of embedding, I thought making mine would be way easier


I asked this because I'm currently wondering what to do for my own project. Embedding another langage has the advantage of easily bringing a huge lot of advanced possibilities through the syntax itself (think of Python instructions for example, and object-oriented), and through third-party libraries (math/matrix functions for example).

I'm still thinking about all of this, but at the moment I think I'll embed Lua or Python (I really can't decide which :s). I'd give the game programmer 2 ways of using my engine: On one hand very simple instructions/functions which are completely coded in the C++ application, and on the other hand access to low-level functions of my engine (like direct-access to the object-manager or the sprite manager) which will allow the game programmer to bring the complexity in the script rather than in the C++ application so that he can choose exactly how things are done and even add the possibility of doing things that weren't implemented at all in the engine in the first place. For example the game programmer could decide to directly handle files using some Lua/Python libraries and save some permanent data if this is not impletemented in the engine.

Like I said I'm still it brainstorming about all this, it also brings more complication related to the embedding of the language and things like being in sync with the framerate (although I'll probably have to re-do this as well). I thought all of this may be solved in a standard Lua/Python library packed with the engine.


All of this to tell you that if it works like it should, it might be a very nice feature to have in your engine. It's worth thinking about it

[lumber_of_the_beast]

And today's dumb question:

Might it be possible to have two different power meters - one for your own shot, and one for options? Maybe by - and keep in mind I have never tried anything remotely like this before so I do not know if I am using the right words - defining Power1 and Power2 as opposed to just Power in the stage and player scripts, and then setting it up so that if the player script receives a Power boost instead of a Power1/2 boost, it applies to both, and if the stage script tries to give a Power1 or Power2 item to a shottype that lacks those, it'll instead dispense a Power item?

[Danielu Yoshikoto]

Might it be possible to have two different power meters - one for your own shot, and one for options? Maybe by - and keep in mind I have never tried anything remotely like this before so I do not know if I am using the right words - defining Power1 and Power2 as opposed to just Power in the stage and player scripts, and then setting it up so that if the player script receives a Power boost instead of a Power1/2 boost, it applies to both, and if the stage script tries to give a Power1 or Power2 item to a shottype that lacks those, it'll instead dispense a Power item?

I think it might be possible due to the Power (as in 0-127 or 0.00-4.00) for the Characters is actually manually scripting into the players (to my knowledge). Danmakufu doesn?t keep the variable for Power on it?s own and it doesn?t have any Power Ups build in. So they would have to be made manually for the script/stage/game as well as for the player. And yes... It should be possible to set up two variables with the name "Power1" and "Power2" then.

[Nuclear Cheese]

And today's dumb question:

Might it be possible to have two different power meters - one for your own shot, and one for options? Maybe by - and keep in mind I have never tried anything remotely like this before so I do not know if I am using the right words - defining Power1 and Power2 as opposed to just Power in the stage and player scripts, and then setting it up so that if the player script receives a Power boost instead of a Power1/2 boost, it applies to both, and if the stage script tries to give a Power1 or Power2 item to a shottype that lacks those, it'll instead dispense a Power item?

There is no built-in power system yet, although there was talk of having a setup which allowed the game scripter to set the value of power items and the thresholds for the different "power levels" which in turn define the power at which the player script should shoot.

Creating a second power level, even with the above idea implemented, wouldn't be too hard.  Just use a global for your Power2 level, and have your game/stage scripts adjust as necessary.  The only catch would be that, if you want your player to function with other scripts, you'll need to set up a default value for Power2, or detect that you're on a different script and base the Power2 off of the regular shot power level.

But, as Danielu Yoshikoto said, it's definitely possible to script in Musuu no Danmaku.



New stuff today: Bombs.

Bombs are triggered under the following conditions:
- Player presses bomb key
- Player has a bomb in stock
- Player is not in invulnerability

It'll subtract a bomb stock and run the bomb script.  Like miss, it's meant for the player object, but any object type can use it.

Bomb stock resets when the player misses (specifically, at the same time a life is deducted).


There is a built-in default bomb script that just gives the player script three seconds of invulnerability, but I added scripts to both of the sample player scripts:

• Spread type gets three seconds of invulnerability while it shoots out circles of shots.  At the moment, it is a bit overpowered since you can overlap with the boss and do rediculously massive damage (takes out the current sample boss in about one and a half seconds  :/).
• Simple type gets four seconds of invulnerability, during which it has a powered up shot - faster shots and a much faster fire rate.

PS - family obligations that kept me busy during the week have all but completely ended.  That means a bit more time for me to slack offwork on MnD.  Yay.

[Nuclear Cheese]

Hope you don't mind the bump ... this thread has gotten rather quiet in recent times.


I just implemented the majority of what's necessary for plural scripts.  This includes all of the necessary Script Engine items that are necessary for it.  Here's how it works:

The first script calls the function SetPlural, which takes an array of object type names that are used for the plural script.  Then, when each script has gone through its time/life/etc, it calls the function NextPlural, which reassigns the object to the next object type in the list given.  Additionally, I added the function LastPlural, which returns if the object is currently at the end of its defined plural list.


It works something like this:

Code: [Select]

Musuu
Script[mdScript]
Type[Enemy]

Plural "PluralEnemy"
{
   initialize
   {
      SetPlural(["TheEnemy", "AnotherEnemy");
      NextPlural();
   }
}

include("TheEnemy.txt");
include("AnotherEnemy.txt");
The above sample (written on the spot - might not be syntax-perfect) will set up the object to have two object types in its plural queue - first is TheEnemy, and then AnotherEnemy.  It then uses the NextPlural function to immediately switch over to the first type in the list - doing it this way allows TheEnemy to both stand on its own as a single attack as well as the opener for this plural.

Also note the include statements - the object types referenced by the SetPlural must be read in by the scripting engine too, or it'll error.


The big item left to add for plural scripts is a separate script language (which I'm calling mdPlural) which will be similar to Danmakufu's plural file syntax, so that scripters can more easily define plural scripts.


Just like the check for the deleting the boss when its life runs out, right now the script needs to manually call NextPlural when the boss's life hits zero.  However, this will change.

My plan is to add a zerolife script, which will be automatically run when an object's life is reduced from a positive value to a nonpositive value.  By default for a boss, it will clear enemy shots, and then either advance the plural or destroy the boss as appropriate.
Sound like a good plan?





Also, memo to self: get the program to catch errors from ANTLR, so we can report them correctly.

[Dizzy H. "Muffin" Muffin]

Er ... could you clarify what you meant by "plural script"? I can't remember if you explained it before and I'm slightly too brain-fogged to work it out on my own from the context ...

[Nuclear Cheese]

Er ... could you clarify what you meant by "plural script"? I can't remember if you explained it before and I'm slightly too brain-fogged to work it out on my own from the context ...

Plural script is a script that defines a sequence of attacks for an enemy, which are faced one after the other.  The term is used the same way in Danmakufu.


EDIT:

Added some new functionality with the new zerolife script.  This is called when an object's life is reduced from positive to nonpositive.  There is a default zerolife script given for all Boss object types, which will clear enemy bullets and either advance to the next script in a plural or destroy the object if there are no more scripts in the plural sequence.


I also added a small bit in the ANTLR grammar such that ANTLR now throws an exception when it encounters a syntax error, rather than trying to bullshit its way through it.  It doesn't give any details (line number, exact problem, etc) yet, but it'll get there.  For now, at least it no longer pretends to properly load scripts that it can't properly interpret.

[ray10k]

I am not sure if this is the right place to address this, but in the first post of this thread, under item number six, it was mentioned that bullets would be colored using only the red and green channel in a file. however, in mountain of faith and subterranean animism there are a few bullets using black parts.
my suggestion (and forgive me if it has already been made, or is simply ⑨ish) is to use
the red channel for opacity (or alpha),
the green channel for brightness (255: completely white/color, 0: completely black),
and the blue channel for the parts that need to be colored (assuming the pixel is set to 255 green, 0 blue would mean white, 255 blue would mean completely in the chosen color).

I hope this doesn't sound too stupid.