A replacement for Danmakufu?

[MCXD]

Y should NOT be inverted. As it then contradicts the system which every programming language uses, which is the inverse to that used in math.

We are using a programming language here, so...

How about we have an option in the game config file, or the system config file, which allows the toggling of Y and Rotational inverting?

[Dizzy H. "Muffin" Muffin]

Mmm, bad idea. It might turn out to be the wrong one depending on what script you're using to run it.

[Stuffman]

There's no need to accommodate every single preference when it comes to scripting syntax. Consistency is better because it won't lead to confusion down the line.

Up as 0 is fine as it feels right to me, and right as 0 is also fine because I'm used to it in Danmakufu.  Just pick one or the other.

Y should definitely go from top to bottom though, I can't think of any programming language that doesn't do it that way.

[Nuclear Cheese]

Y should NOT be inverted. As it then contradicts the system which every programming language uses, which is the inverse to that used in math.

We are using a programming language here, so...

To clarify - Y isn't inverted from what is normally seen in programming.  Increase in Y is downward on the screen.

The zero angle, as I have defined it, is simply the vector (0, -1).  +angle being clockwise comes from the fact that angle vectors are calculated using the sine and cosine.

There's no need to accommodate every single preference when it comes to scripting syntax. Consistency is better because it won't lead to confusion down the line.

Up as 0 is fine as it feels right to me, and right as 0 is also fine because I'm used to it in Danmakufu.  Just pick one or the other.

Y should definitely go from top to bottom though, I can't think of any programming language that doesn't do it that way.

Thus spoketh the man of stuff, and thus defined how things shall be.

If there aren't any major objections, I'd like to stick with angle 0 = up, since that makes the most sense to me.  But if most people want the zero angle to be right, like in Danmakufu, (or perhaps, maybe downwards even), I can set it to that.  I agree with Stuffman, however, that we should have one consistent baseline to keep things from getting confusing (and to keep an unnecessary source of complication out of the program).



Like I mentioned in my other thread, I've been away from my desktop all day today (and will most likely continue to be so for most of the week), so I'll be returning to crack out some code later in the week.

[Dizzy H. "Muffin" Muffin]

Hmm. Now that I look at spriterips from Touhou games, "0 degrees = up" seems to be the way ZUN does things.

And I throw in my vote for (0,0) being upper-left.

[Kylesky]

Can you also fix the replay function? in danmakufu, when you speed up using the space bar while watching the replay, it won't show the exact replay anymore... usually it'll desync or something... example... there was once where I only wanted to see the latter part of a replay I saved, I sped up the replay using the space bar, but when it was speeding the player died... when I watched it without speeding, it went on normally without the player dying...

[Lawence Codye]

If there aren't any major objections, I'd like to stick with angle 0 = up, since that makes the most sense to me.

No objections here...makes more sense to me as well...
& I'm also for (0,0) being upper-left...oh, & the progress on this project is sounding great so far, Nuclear Cheese...
I joined this forum at a good time...

[Dizzy H. "Muffin" Muffin]

Can you also fix the replay function?

I don't think "fix" is exactly the right word, given that he's creating his own entirely new program, he isn't directly basing anything much on Danmakufu besides the basic purpose of the program.

[Lishy1]

One last uninformed suggestion by yours truly:
Could players be more flexible so that you would be able to switch them after a script/game has been activated? Say you want it to switch to a specific player when you reach a boss.
As it stands, in danmakufu you would have to add the code to the player you select when you load a script. Things get a little messy from there...

To sum it up: Being able to switch shot types.

[Chronojet ⚙ Dragon]

I suggest implementing that history thing ZUN uses in spell cards. With Danmakufu, there's no such thing, except through the use of common data functions... 

[Dizzy H. "Muffin" Muffin]

I suggest implementing that history thing ZUN uses in spell cards. With Danmakufu, there's no such thing, except through the use of common data functions... 

I suspect the reason Danmakufu doesn't have it is that it would be a logistical nightmare. Where would you store it? How would it handle two identical scripts with different filenames (i.e. for the spellcard Hax Sign "Burn Everything", "haxsign.txt" versus "hax sign burn everything.txt")? How would it handle different versions of the same script which noticeably alter the gameplay? What about two different versions where all that's changed is one line that only changes the background color?

And if that wasn't enough, ZUN has a separate history-counter for every character and shot-type. The issue is therefore multiplied by what player script you're using.

[Naut]

It's actually not that hard (comparitively), but it does involve saving common data.

And nobody really cares enough to have it.

In Danmakufu, all saved files are saved in xxxx_save.dat, where xxxx = filename of the script. The .dat file is stored in the same folder as the corresponding script. Two different versions of the script could cause desyncing replays or unintended results (depending on what kind of information you're getting). Changing background colour or other useless information that only pretties up cards will never desync a replay or mess up saved data, since it isn't information that is saved in a replay file (I've tested this).

[Nuclear Cheese]

Can you also fix the replay function? in danmakufu, when you speed up using the space bar while watching the replay, it won't show the exact replay anymore... usually it'll desync or something... example... there was once where I only wanted to see the latter part of a replay I saved, I sped up the replay using the space bar, but when it was speeding the player died... when I watched it without speeding, it went on normally without the player dying...

... wait, you can speed up the replays with whatnowhow?

This is one area that I intend to handle better than Danmakufu.  I don't think it'll be a top-priority feature, but I do intend to get replay functionality in there, and working consistently (so that replays don't desync and such).

One last uninformed suggestion by yours truly:
Could players be more flexible so that you would be able to switch them after a script/game has been activated? Say you want it to switch to a specific player when you reach a boss.
As it stands, in danmakufu you would have to add the code to the player you select when you load a script. Things get a little messy from there...

To sum it up: Being able to switch shot types.

This could be an interesting secondary feature, although it could easily break player balance by letting you keep switching to the 'optimal' shot type for the occasion.

I suggest implementing that history thing ZUN uses in spell cards. With Danmakufu, there's no such thing, except through the use of common data functions... 

I suspect the reason Danmakufu doesn't have it is that it would be a logistical nightmare. Where would you store it? How would it handle two identical scripts with different filenames (i.e. for the spellcard Hax Sign "Burn Everything", "haxsign.txt" versus "hax sign burn everything.txt")? How would it handle different versions of the same script which noticeably alter the gameplay? What about two different versions where all that's changed is one line that only changes the background color?

And if that wasn't enough, ZUN has a separate history-counter for every character and shot-type. The issue is therefore multiplied by what player script you're using.

This generalized score history idea is certainly doable, even with all of the "logistical nightmare" crap that would make it rough.  Basically, I'd think to store a score file alongside each script file, holding score records for each player script that has played it.  Perhaps, in the case of the compiled script format that has been mentioned, the score data could even be included right in the compiled file itself.  To curb "cheesing" the scorelist, we could also add in checksums of the scripts in use (player, enemy, etc), so if the checksums don't match it creates a different score file/entry or such.

Just a bit of brainstorming ...

[Suikama]

fyi danmakufu as a whole can be sped up using the spacebar of Page Up buttons.

[helvetica]

Couple of suggestions, sorry if it's a bit late as I just noticed this thread as I was perusing around the board.  I know this has been attempted in the past (RIP OpenDMF) so godspeed to you for working on a new replacement.

1) I wouldn't use C# for this mostly because although Mono is great, I wouldn't rely on it for graphical programs.  WinForms and other GUI things work DRASTICALLY different on Mono than on Windows .net to the point that you might as well use a third party toolkit, negating the whole point of using .net in the first place.  Also SDL is pretty crappy on all platforms, only really useful for having a single target to hook a window to for OpenGL (which after reading is all you're using it for anyways).  I would honestly look into using an existing crossplatform 2D/3D engine like Irrlicht or CrystalSpaces (definitely recommend CrystalSpaces) and just focus on coding the actual danmaku and hitbox framework.

I know you already got some code down but honestly maintainability in the long run will be MUCH easier if you stick to a preestablished engine and just code in C the object logic/patterning and hitboxing.  Especially for crossplatform compatibility and just future compatibility even in Windows (look how many issues DMF has :|)

2) Yes use an existing scripting engine/language rather than invent your own parser/lexer.  Lua was designed specifically for this, and it's stupid easy to embed it or something like Python or Ruby.  It's infinitely easier to just use an existing language and have people learn to use it rather than invent and maintain your own parser and lexer.  Maintainability comes back into play here, as you won't have to worry about making code binds for every little thing.  You just have to code key functions you want to expose to the scripts, and let the language handle the flow and logic.

Plus with older DMF scripts you can just build a conversion tool and then just hand-fix any oddities rather than trying to match DMF's syntax and usage word for word.

Basically what I'm trying to say is, it's great you're doing it, but you really don't have to reinvent the wheel.  Using already built stuff like the game engine and script language will let you focus more on what actually matters, coding the danmaku framework and script bindings, and will be much easier to maintain and complete and make crossplatform.  Good luck, and if you'd like some help I'd definitely be willing to throw a few programming hours into it, although I don't really have much time right now to devote to it.  I'd be willing to setup Mercurial repository and bugtracker for the project so people can collectively work on the source and contribute as necessary rather than forcing the load just onto you.

[Lishy1]

One last uninformed suggestion by yours truly:
Could players be more flexible so that you would be able to switch them after a script/game has been activated? Say you want it to switch to a specific player when you reach a boss.
As it stands, in danmakufu you would have to add the code to the player you select when you load a script. Things get a little messy from there...

To sum it up: Being able to switch shot types.

This could be an interesting secondary feature, although it could easily break player balance by letting you keep switching to the 'optimal' shot type for the occasion.

It wouldn't really be a problem of balance. It's a problem of danmakufu being so dependent on the character you've selected.
From what I could understand so far, it seems like the problem is that danmakufu is so dependent on the character you chose if, for lets say you unlocked the extra stage in your game.
By switching characters, I mean support to do so after a game/script has been activated. To perhaps even choose the characters ingame from the story mode menu rather than prior.
This could require completely recoding how the program treats players though, but it would allow much more possibilities.

Again, sorry if I said anything incorrect and sorry for my lack of "advanced" knowledge >_<

[MCXD]

This could be an interesting secondary feature, although it could easily break player balance by letting you keep switching to the 'optimal' shot type for the occasion.

Have it switchable or lockable with a function like Expert

[8lue Wizard]

<Quoted stuff>

It wouldn't really be a problem of balance. It's a problem of danmakufu being so dependent on the character you've selected.
From what I could understand so far, it seems like the problem is that danmakufu is so dependent on the character you chose if, for lets say you unlocked the extra stage in your game.
By switching characters, I mean support to do so after a game/script has been activated. To perhaps even choose the characters ingame from the story mode menu rather than prior.
This could require completely recoding how the program treats players though, but it would allow much more possibilities.

Again, sorry if I said anything incorrect and sorry for my lack of "advanced" knowledge >_<

...I'm sorry, but I'm having a little trouble following you. Do you mean switching out characters in the middle of a plural script? Like, between spellcards and such? 'cuz, quite frankly, I think that's a horrible, horrible idea.

[Montblanc]

=o Wows. The Stupid One made some very excellent points.


Also, and this isn't any kind of important issue, but was there any specific font style you had in mind for any in-game text? I know a few Touhou games had their own custom-style font sets, and was just wondering if you had any ideas on that thus far.

[Nuclear Cheese]

Couple of suggestions, sorry if it's a bit late as I just noticed this thread as I was perusing around the board.  I know this has been attempted in the past (RIP OpenDMF) so godspeed to you for working on a new replacement.

FYI - I had been tossing the idea around for literally weeks before I even posted about it.  I wanted to make sure I had the available time in the long-term to be able to support this the best I can.

1) I wouldn't use C# for this mostly because although Mono is great, I wouldn't rely on it for graphical programs.  WinForms and other GUI things work DRASTICALLY different on Mono than on Windows .net to the point that you might as well use a third party toolkit, negating the whole point of using .net in the first place.  Also SDL is pretty crappy on all platforms, only really useful for having a single target to hook a window to for OpenGL (which after reading is all you're using it for anyways).  I would honestly look into using an existing crossplatform 2D/3D engine like Irrlicht or CrystalSpaces (definitely recommend CrystalSpaces) and just focus on coding the actual danmaku and hitbox framework.

I know you already got some code down but honestly maintainability in the long run will be MUCH easier if you stick to a preestablished engine and just code in C the object logic/patterning and hitboxing.  Especially for crossplatform compatibility and just future compatibility even in Windows (look how many issues DMF has :|)

As far as using C#, WinForms and such don't even come into play in my code here; I already knew they don't work (at all, if I remember correctly) on Mono, so I don't touch them.

SDL is pretty limited for graphics itself, which is why I'm using it just to set up an OpenGL window like you say.  But at the same time, it makes dealing with input and audio a lot easier than anything else I know of.

As far as preexisting engines, keep in mind that it would create significant lag-time in startup, and likely at several points mid-development, due to learning how to work with the engine and such.  For that amount of time, I think it's easier for me to throw together my own code, which gives the advantages of not being limited by what's "under the hood" (since, if it's not there already, someone can just put it in) and having the engine custom-tailored to our needs.
Also, I get the impression that most game engines are optimized to deliver a set game speed, regardless of framerate.  This is rather unlike what I think we want in a game like this (the official games, for instance, play at the frame rate) because, usually, varying frame rates gives rise to inconsistencies in how the game behaves each time - due to, for instance, one time the frame landing on timestamp 5.443 and another time the frame landing on timestamp 5.445.
And, of course, there's always licensing concerns.  While most things are probably fine, we do need to keep an eye on things, so we don't go pissing people off.

As far as C vs. C#, I've done similar things in C++ before (for intance, my currently-on-hold-due-to-lack-of-ideas STG SphereTide Gunner), and it was a royal bitch keeping things organized.  C# is a much cleaner language in this regard.  Plus, automatic garbage collection = no worries of memory leaks.

2) Yes use an existing scripting engine/language rather than invent your own parser/lexer.  Lua was designed specifically for this, and it's stupid easy to embed it or something like Python or Ruby.  It's infinitely easier to just use an existing language and have people learn to use it rather than invent and maintain your own parser and lexer.  Maintainability comes back into play here, as you won't have to worry about making code binds for every little thing.  You just have to code key functions you want to expose to the scripts, and let the language handle the flow and logic.

I don't really have much knowledge of Lua and such.  I should probably look into it.
Main concerns would be syntax of the script file, with the ability to keep related scripts together in an organized fashion.

By the way, I hate Python.  Indentation as syntax is a horrible idea, in my opinion.
Ruby, on the other hand, I have no experience with.

Plus with older DMF scripts you can just build a conversion tool and then just hand-fix any oddities rather than trying to match DMF's syntax and usage word for word.

Certainly doable, but would be hell and a half to implement.  Especially with some of the differences in how things are structured. (Which were restructured as such to simplify scripting and eliminate some of the unnecessary limitations in Danmakufu)

Basically what I'm trying to say is, it's great you're doing it, but you really don't have to reinvent the wheel.  Using already built stuff like the game engine and script language will let you focus more on what actually matters, coding the danmaku framework and script bindings, and will be much easier to maintain and complete and make crossplatform.

The thing is, I already know a good amount of OpenGL/SDL and C# development, and the entire engine structure came together mentally in maybe a day or two of mostly idle thinking about it.  On the other hand, like I said before, I generally have little to no idea about interfaces, APIs, etc. regarding already-built engines and such.


btw - please don't think I'm trying to be disagreeable here.  I'm just stating my side of things.  Feel free to counter-point and such, as you see fit.

Good luck, and if you'd like some help I'd definitely be willing to throw a few programming hours into it, although I don't really have much time right now to devote to it.  I'd be willing to setup Mercurial repository and bugtracker for the project so people can collectively work on the source and contribute as necessary rather than forcing the load just onto you.

Thanks.  While it might seems a bit selfish/arrogant, I'd like to at least get this thing to a working, stable point before I start posting code/builds.  Right now it still needs some stuff added in, notably:

• Input - simple task, maybe a couple hours of coding at worst
• Reading script files (Either proprietary or pre-defined script format) - depends on where we go with this.  Probably the biggest unknown, since either I'm using ANTLR to generate a parser (which I started experimenting with already), or I'm going to be reading up tutorials on Lua.
• Execution Engine (may be rendered moot by script language selection) - not as long as it sounds like for a basic, yet "full" set of features.
• A script selection menu - probably a couple hours of coding to get it to a decent-looking point (save for actual images, since I suck at art)
• Font rendering - the only real weakness in OpenGL's drawing setup, IMO.  I may be able to hook into SDL.Net's font functions to generate an image-based font internally, though.

It wouldn't really be a problem of balance.

Actually, I would argue that balance is the primary concern with this idea.  Most player/shot types have specific strengths and weaknesses:

• ReimuA - homing shots and small hitbox, but low power shots
• MarisaB - high power and really awesome bomb, but needs to be directly aligned with targets (and moves so fast you can't dodge accurately if you suck like me

By allowing the player to switch out characters/shot types at will (which is how I understand your idea), it would allow players to easily break this pro/con setup by swapping to characters whose disadvantages aren't a concern at the moment.

Implementation-wise, though, I doubt it'd be too hard to do.  Just swap the current player object with a new one for the new player type.

Also, and this isn't any kind of important issue, but was there any specific font style you had in mind for any in-game text? I know a few Touhou games had their own custom-style font sets, and was just wondering if you had any ideas on that thus far.

I don't really have any ideas in this regard yet.  My biggest concern is actually getting font support in order, for which we may have to rely on an image-mapped font.  This is the only significant disadvantage of the OpenGL/SDL setup that I know of, since OpenGL doesn't have good/any font support.

However, I might be able to abuse SDL.Net's font class to generate an image map font on-the-fly ... I should look into this.





EDIT:
Due to an unscheduled lack of commitments and other crap, I'm actually at my desktop, and I just got in a mini-update to the program - it now reads inputs.
Currently it's limited to the default keyboard inputs we all know and love/hate/feel indifferent about; configurable controls can be added in later (it's already half setup for that - just need to add in storage to hold the control configuration and processing for controllers).

I'm also spending a bit of time looking at scripting languages, font support, and such.

Please note that this is an exception to the rule - most weekdays I'll be too bogged down with stuff to do much more than stopping by here on my laptop.  Weekends should yield more positive results.

[ghost333]

try to add a different colision type for lasers.... using circles (if i read right) would be bad  i think

[Stuffman]

Lishy isn't really properly communicating why he wants the change-players function, he talked to me about it earlier.

He doesn't mean having the Player Select screen come up in the middle of scripts, he means being able to change the active player script in the middle of the game.

For instance, it might be a part of your game that you play a different character on a certain stage, or maybe your character unlocks their hidden powers and is different for the last couple stages or something like that. The trouble is that there's no way to change to a different player file mid-script in Danmakufu. You have to work around it by putting all that stuff in the same player file and making it work with common data, which is kind of clumsy.

[Nuclear Cheese]

try to add a different colision type for lasers.... using circles (if i read right) would be bad  i think

Certainly makes sense.  Would most likely do something like an ellipse ...

Lishy isn't really properly communicating why he wants the change-players function, he talked to me about it earlier.

He doesn't mean having the Player Select screen come up in the middle of scripts, he means being able to change the active player script in the middle of the game.

For instance, it might be a part of your game that you play a different character on a certain stage, or maybe your character unlocks their hidden powers and is different for the last couple stages or something like that. The trouble is that there's no way to change to a different player file mid-script in Danmakufu. You have to work around it by putting all that stuff in the same player file and making it work with common data, which is kind of clumsy.

Ah, this is slightly different than what I originally interpreted it as.

This is certainly possible in player scripts already, but built-in support may not be a bad idea.

[anonl]

try to add a different colision type for lasers.... using circles (if i read right) would be bad  i think

Certainly makes sense.  Would most likely do something like an ellipse ...

Circle <-> line-segment+radius is probably easier to implement than circle <-> rotated ellipse.

[Montblanc]

I was playing MoF earlier and was reminded by doing so to ask about something. xD

For Stage Progression, are you planning on making it like Danmakufu/EoSD/PCB/IN, where after completing a stage, the screen shrinks and your score page pops up before moving on?

Or are you going to do it like MoF/SA/UFO, where your score briefly pops up and then automatically shifts into the next stage without any transition screen?

[Drake]

That's more up to the player, I'd think.

[MCXD]

Make it something completely different to both.

[Dizzy H. "Muffin" Muffin]

Make it specifiable in the level-script.

Or, better yet, the level-transition script.

[Chronojet ⚙ Dragon]

I was playing MoF earlier and was reminded by doing so to ask about something. xD

For Stage Progression, are you planning on making it like Danmakufu/EoSD/PCB/IN, where after completing a stage, the screen shrinks and your score page pops up before moving on?

Or are you going to do it like MoF/SA/UFO, where your score briefly pops up and then automatically shifts into the next stage without any transition screen?

LevelTransition();

How about YOUMU or FUJIN?

[Nuclear Cheese]

try to add a different colision type for lasers.... using circles (if i read right) would be bad  i think

Certainly makes sense.  Would most likely do something like an ellipse ...

Circle <-> line-segment+radius is probably easier to implement than circle <-> rotated ellipse.

Good point.  That would be a lot easier.
Any objections or other suggestions?

Although, come to think of it, what about the case of two colliding lasers?  I'm sure it's doable, but I don't know the algorithm off the top of my head.

I was playing MoF earlier and was reminded by doing so to ask about something. xD

For Stage Progression, are you planning on making it like Danmakufu/EoSD/PCB/IN, where after completing a stage, the screen shrinks and your score page pops up before moving on?

Or are you going to do it like MoF/SA/UFO, where your score briefly pops up and then automatically shifts into the next stage without any transition screen?

Good question.  The MoF-style one would be a bit easier, I think.  But in the end I think we'd want both ...

LevelTransition();

How about YOUMU or FUJIN?

... like this.



Some more progress tonight:

• Window scaling - the program supports multiple window sizes, and scales all of the graphics to fit.  Now I just need to add in a way to actually configure it, aside from changing the variable in the code.
• Player movement
  
  • Handled automatically, without any manual scripting, simply by setting the object's player movement speeds (unfocused and focused)
  • Any object can be given player movement, not just the player.  I'll leave you to imagine possible uses for that.
• Playfield boundaries
  
  • Current playfield size: 426 by 568
  • Currently we have a purple border.  I'll replace it with code to have an image-based border later.
  • Objects that fly off outside the playfield far enough will be auto-deleted.  This can be disabled on a per-object basis.

And, I figured I'd give you guys a glimpse of what it looks like in the current build.  Warning: I'm no artist, so it's not particularly impressive visually.


(If this doesn't display, try this link)

The white text was added in afterwards (over ⑨000ms in MSPaint :V).

Object 1 is simply moving at a down-right angle.  Note that its sprite is rotated to match its movement vector (the red corner is up on the image)
Object 2 (Pyro-Reimu) is moving straight left.  This time, the sprite is not rotated with the object's movement.
Object 3 is player-controlled.

The number in the title bar is a temporary debugging output - the value is a global variable that each object's Tick and Collision scripts modify each frame.  This lets me know what's going on with the objects as they move about in realtime.


I know, probably not very impressive, but please keep in mind that most of the work I've been doing is foundation - the engine itself is actually pretty usable right now, save for some details:

To-Do List of Doom:

• Script file reading
• More functionality in the Execution Engine (especially commands for manipulating objects)
• Script selection menu
• Font rendering (could, in theory, do without for a while, but it'd be nice to get it in there pretty quickly)