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

Nuclear Cheese

  • Relax and enjoy the danmaku.
    • My homepage
Re: A replacement for Danmakufu?
« Reply #630 on: June 22, 2010, 11:42:42 PM »
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.

That idea for bullet coloring has been put on the "would be nice, but it's not necessary" list.  Also, your idea for the red channel is redundant, since we already would be using the alpha channel for transparency (.png kicks ass).  Having a channel fade from black to white/color sounds like it might be a good idea, though.
I also had the idea that the third color channel could be used for a secondary color on the graphic.

Oh, and just so everyone knows - if I do end up getting this idea working, my plan is to also create a small tool that takes in a "normal" bullet image and creates a "color-coded" one like described above, so that you won't need a PhD in Photoshop in order to make them.


Right now bullet graphics, like all other graphics, are just standard images.  The plan is, if/when this idea gets in place, it'll be a second option when drawing an image, rather than just drawing an image normally.  This means it'll be applicable to not just bullet graphics, but any graphics that are displayed in the game (for instance, waves of same-shaped, different-color'd enemies could look nice with this).


BTW - I've been pretty lazy with the first post, and as the note at the top says, a lot of that information is out-of-date, so it may be a good idea to not take it all at face value.


EDIT: Ooh, new page.  Also new progress:

I just implemented "message functions".  These are functions that you define within an object type.  Later on, any script that has the ID number of an object of that object type can call the message function to request some action or value from that object.
On a related note, I also added the return command to mdScript, which returns a value from the current script (if no value is given, it returns a default value of zero).


Here's a sample of message functions in action:

Code: [Select]
Musuu
Script[mdScript]
Name[Message Testing]
Type[Enemy]

Boss "TheEnemy"
{
   initialize
   {
      SetLife(9001);

      id = CreateObject("OtherObject", 50, 50);
      id->"send id"(GetMyID());
   }

   tick
   {
      if (GetLife() < 1000)
      {
         SetLLife(2000);
      }
   }

   message "hurt" (amount)
   {
      SetLife(GetLife() - amount);
   }

   message "get stuff"
   {
      return "stuff";
   }
}

Effect "OtherObject"
{
   define id;

   initialize
   {
      id = -1;
   }

   message "send id" (new_id)
   {
      id = new_id;
   }

   tick
   {
      if (id > -1)
      {
         id->"hurt"(50);
      }
   }
}

The enemy script first spawns an "OtherObject" object.  Then is calls that object's "send id" message function, so that the enemy can give its own ID number to the newly spawned "OtherObject".

In turn, each frame the :OtherObject" object calls the "hurt" message function of the enemy object.  The enemy object's tick function simply makes sure the enemy's lifebar never drops down to zero (which would cause an error in the "OtherObject" object since the enemy object would be deleted).

Also note the "get stuff" message function (which isn't used at all in this example).  Since it takes no args, it forgoes the open and close parenthesis when it is being defined.  You'll still have to use the parens when calling it, though.  (Does this sound like it could get confusing?  I can make it always require the parens for consistency ...)

Of course, these can be used for much more complicated tasks if you put your mind to it.  These message functions can use all of the normal script commands, and have access to all of the called object's defined variables.  This is just a relatively simple example used to demonstrate usage.


You'll notice that all of the message function names are in quotes - I decided to do that for a couple reasons.  First, it leaves you more freedom with the naming (spaces, symbols, etc).  Second, it ensures we can't have any overlap with object properties.
« Last Edit: June 23, 2010, 03:18:58 AM by Nuclear Cheese »
to quote Naut:
"I can see the background, there are too many safespots."
:V

Nuclear Cheese

  • Relax and enjoy the danmaku.
    • My homepage
Re: A replacement for Danmakufu?
« Reply #631 on: July 22, 2010, 02:48:53 AM »
Hey guys.

I hate to come in here just to apologize for not making any progress, but, well ...
I have to apologize, since I haven't made any progress in the past month or so.  :fail:

Been really distracted, and I'm not sure what to work on next on this ... anyone have any preferences on what gets worked next?  Here's a list of things I've considered getting to soon ...

  • Power system
    There was a bunch of discussion on how this could be done earlier ... mainly, scripts would define power item values, as well as thresholds for each "power level".  The player script would use the power level as the indicator of how powerful of a shot to use.
    Also, this system would extend to cover bombs as well, allowing, for instance, bombs to burn up some power as well as/instead of bomb stock.
  • Stage files
    These probably aren't that hard to do, to be honest.  In fact, technically you can make stages right now; it'd mainly be formalizing it and adding any extra functions to support it.
    PS - any particular functions for this?
  • Lasers
    Surprisingly difficult.*is shot*  Of course they're on the list for a definite feature in the first full release, so I'm gonna have to hit them eventually.
    Hardest piece is probably the collision detection, since I'll have to write up and test collision with a whole new shape.
  • Tasks
    I don't have an exact implementation plan for these yet, but I do have a couple possible ideas on how they could work.
  • Pausing
    Pretty self-explanatory.  Theme had started working on this way long ago, but has since apparently disappeared from around here or something.  Go figure.  :V
  • mdPlural language for Plural scripts
    Right now, plural scripts aren't quite as easy to define as they are in Danmakufu - this scripting language will help with that.
  • Optimization
    This wouldn't have any major visible effect, but would certainly help with rediculous bullet spam making things run smoother.  I know of a couple ways to optimize the collision detection code, at the very least, which should yield some decent improvement.


Of course, if I missed an "OMG WHY U NOT DOING THIS ALRAEDY?! :derp:" item that should be in done soon, let me know.


Also - when do you guys want the next test release?
So far, since the last release, I've added:
  • Lives/Respawning
  • Text display of score, lives, bombs, and graze
  • Bombs
  • Functionality for plural scripts
  • Message functions
to quote Naut:
"I can see the background, there are too many safespots."
:V

Azure Lazuline

  • Looooove!!
  • PM me for free huggles and love!
    • Entanma Project - indie game development
Re: A replacement for Danmakufu?
« Reply #632 on: July 22, 2010, 02:56:02 AM »
Stage files or lasers should be your next target. If you get stuck on one though, just do some optimization.

Re: A replacement for Danmakufu?
« Reply #633 on: July 22, 2010, 03:00:31 AM »
Wassup

So I haven't really been following this as closely as I should, but I really do want to script in your language. The problem is, I'm not really interested in devoting hours and hours to reading through this whole thread and trying to teach myself the language, while still keeping up with updates. So, for the next thing to be done, I'd love to see an extremely basic tutorial on scripting within Musuu. Since the majority of us that are following your engine know danmakufu, you can assume we know really extreme basic stuff and whatnot, so you can just provide us with syntax. Right now I just have no idea how to get things started, and some terms look very foreign (I know they're explained in the thread, but hunting through so much information is...  :ohdear:). So uh, I'd love it if you could write a few paragraphs explaining what all these new terms are and how things operate. I know I'm not the only person who looks at this project and gets discouraged because of the massive wall of jumbled information everywhere, so I think it'd be really benificial to you to have more play testers and whatnot.

Without knowing much about anything at the moment, and after a really basic tutorial is written, I'd love to see a pause feature next implemented. It pausing the music as well would be all sorts of awesome. Afterwards... Probably tasks, given they're easy to use and very useful. Of your list, I think the power system would be the least important thing to be done at the moment.

Lord Phantasm Satori

  • Permabanned
  • RIP 7/21/2010-9/10/2010
Re: A replacement for Danmakufu?
« Reply #634 on: July 22, 2010, 06:33:14 AM »
yeah. thing is, I'm not sure whether I should learn this or danmakufu. considering danmakufu is in japanese and has little support outside this forum.

actually I'm not sure I should learn at all since I'm not even sure what I can use and how I could even contact Zun to ask permission to do so...

Stuffman

  • *
  • We're having a ball!
Re: A replacement for Danmakufu?
« Reply #635 on: July 22, 2010, 08:02:05 AM »
Ditto Naut. What we really need right now is some starting documentation.

Quote
actually I'm not sure I should learn at all since I'm not even sure what I can use and how I could even contact Zun to ask permission to do so...

The official guidelines are that you can use ZUN's IP, but not any actual media he made. So, for instance, you could make Reimu a boss, but you would need to produce your own sprite of her, your own images of yin-yang balls, and your own version of Mystic Oriental Love Consultation (or whichever of her themes you prefer), and then everything would be kosher.

Note that these rules are rarely followed in the western fandom due to our depressing lack of talent.
« Last Edit: July 22, 2010, 08:11:54 AM by Stuffman »

Lord Phantasm Satori

  • Permabanned
  • RIP 7/21/2010-9/10/2010
Re: A replacement for Danmakufu?
« Reply #636 on: July 22, 2010, 08:41:24 PM »
aren't the official guidelines made by you guys also? This all started because of an angry ZUN fan-boy yelling at someone to stop using ZUN's work didn't it? and you treat it like it was ZUN himself who said it. I'm not sure about this though, so correct me if I'm wrong.

I saw the thread where someone posted that, btw.

DDRMANIAC007

  • The DDR Maniac
  • Dance Dance Revolution
    • The Touhou stream blog
Re: A replacement for Danmakufu?
« Reply #637 on: July 22, 2010, 09:26:23 PM »
Is there a twitter I can follow for this?

Serela

  • Moon Tiara Magic
  • VIA PIZZA SLINGING
Re: A replacement for Danmakufu?
« Reply #638 on: July 23, 2010, 12:03:44 AM »
aren't the official guidelines made by you guys also? This all started because of an angry ZUN fan-boy yelling at someone to stop using ZUN's work didn't it? and you treat it like it was ZUN himself who said it. I'm not sure about this though, so correct me if I'm wrong.

I saw the thread where someone posted that, btw.
I'm pretty sure the guidelines were laid out by ZUN

Not 100%, but fairly sure
<mauvecow> see this is how evil works in reality, it just wears you down with bureaucracy until you don't care anymore


Nuclear Cheese

  • Relax and enjoy the danmaku.
    • My homepage
Re: A replacement for Danmakufu?
« Reply #640 on: July 23, 2010, 03:24:41 AM »
So I haven't really been following this as closely as I should, but I really do want to script in your language. The problem is, I'm not really interested in devoting hours and hours to reading through this whole thread and trying to teach myself the language, while still keeping up with updates. So, for the next thing to be done, I'd love to see an extremely basic tutorial on scripting within Musuu. Since the majority of us that are following your engine know danmakufu, you can assume we know really extreme basic stuff and whatnot, so you can just provide us with syntax. Right now I just have no idea how to get things started, and some terms look very foreign (I know they're explained in the thread, but hunting through so much information is...  :ohdear:). So uh, I'd love it if you could write a few paragraphs explaining what all these new terms are and how things operate. I know I'm not the only person who looks at this project and gets discouraged because of the massive wall of jumbled information everywhere, so I think it'd be really benificial to you to have more play testers and whatnot.

Ditto Naut. What we really need right now is some starting documentation.

... dammit, I knew I was forgetting something.  A while back, sonicbhoc stepped up to do some documentation ... then promptly disappeared.  :/

I just threw together a quick, really basic boss script example on the wiki here.

I'll see about getting some more out soon.


yeah. thing is, I'm not sure whether I should learn this or danmakufu. considering danmakufu is in japanese and has little support outside this forum.

The two aren't mutually exclusive.



Is there a twitter I can follow for this?

No.  I'm not a fan of twitter, personally, and if I set one up I'd probably just end up forgetting to update it. >__>
However, it appears that Google Code is nice enough to set up RSS feeds for projects, if that helps - here's a list



Let's see ... things people called out:
  • Documentation (getting some done)
  • Pausing - Theme97 was working on this, but then disappeared (I'm noticing an unfortunate pattern here <__< )
  • Stages
  • Tasks




Here's ZUN's twitter if you want

Hi, keeper of the Brofists.  You're posting while I'm posting. :]
to quote Naut:
"I can see the background, there are too many safespots."
:V

Re: A replacement for Danmakufu?
« Reply #641 on: July 23, 2010, 03:27:20 AM »
Hi, keeper of the Brofists.  You're posting while I'm posting. :]
:wikipedia:

Also, man, I totally thought this was the Q&A thread when I posted that :getdown:

Nuclear Cheese

  • Relax and enjoy the danmaku.
    • My homepage
Re: A replacement for Danmakufu?
« Reply #642 on: July 30, 2010, 12:41:51 AM »
Hey guys, just popping in to say I added a quick function reference for mdScript:

http://code.google.com/p/musuu-no-danmaku/wiki/FunctionReference

Please note that I used the latest code as a reference, and it is possible I listed a function that is not yet in a released version.


Also, I was hoping to get more done on this project this week, then SC2, BB:CS, work, etc. all happened at once and my schedule went boom. :/
to quote Naut:
"I can see the background, there are too many safespots."
:V

Nuclear Cheese

  • Relax and enjoy the danmaku.
    • My homepage
Re: A replacement for Danmakufu?
« Reply #643 on: August 12, 2010, 03:03:27 AM »
Hey again.

Fun fact:  I hate summer.  It's too freaking hot, and robs me of my resolve to do much of anything that involves effort.
(Also doesn't help that I'm still working through several games and such >__> )


Just got around to thinking about tasks a bit, and I wanted opinions on the syntax.  My thoughts were perhaps something like this:

Code: [Select]
Musuu
Script[mdScript]

Effect "Testing Tasks"
{
   task "task one"
   {
      i = 0;
      while (i < 60)
      {
         i++;
         delay(i);
      }
   }

   task "task two"
   {
      i = 60;
      while (i > 0)
      {
         i--;
         delay(i);
      }
   }

   initialize
   {
      Start("task one");
      Start("task two");
   }
}

(sample code, may not be perfect, etc.)

In this sample, we define two tasks, named "task one" and "task two" respectively.  In the initialize event, we spawn one instance of each task.

Each task, itself, is a trivial affair that just counts up/down.  The delay function, as you'll probably guess, delays the task execution for the given number of frames.  I'll probably also add in a stop (or similarly named) function which will end the task right there.

Each task will be owned by the object that spawned it.  The upside to that is the task will have access to the object's variables.  One catch, though, is that the task will disappear along with the object if the object is deleted.  (Is it any different in Danmakufu?  I seriously never use tasks in DMF, so I have no idea :/ )


As far as implementation, I did a bit of digging, and I believe that I can use anoNL's idea of using generators to handle this (suggested way back on page ⑨).  It's pretty much just some fancy code work ... only real complication is that I'd have to refactor a bit of the Script Engine to allow for it (shouldn't be too much, though).


Also, please not that I currently do not plan on supporting the delay and (maybe) stop commands in event scripts (initialize, tick, etc).  In my opinion it ruins the semantics of these scripts (scripts run once each time the event occurs), and really doesn't fit with some of the events, anyways (why would you be delaying in a collision script, for instance?).
In other words, these commands will be exclusively for tasks - one of the only places where I'm putting a limitation like this.



In other news - has anyone taken a look at the documentation I put up?  It'd be nice to get some feedback ... I'm not sure if what I wrote up matches people's expectations and such.


Hopefully I'll be able to get more done on this soon.
to quote Naut:
"I can see the background, there are too many safespots."
:V

Lord Phantasm Satori

  • Permabanned
  • RIP 7/21/2010-9/10/2010
Re: A replacement for Danmakufu?
« Reply #644 on: August 12, 2010, 04:58:12 AM »
could you provide a sample of what a simple pattern might look like? so far, it looks less imposing than when I glanced at a random danmakufu script.

Re: A replacement for Danmakufu?
« Reply #645 on: August 12, 2010, 02:12:13 PM »
Hello

I skimmed through fast through the topic and i have a question:
IS this a new danmaku engine or  you're upgrading danmakufu?
and is there some where a future list?

sorry for these noobish question but i would like to know because i may be doing a danmaku  game.

Nonnie Grey

  • Contradictory Statement
  • The Anonymity formerly known as Kayorei
Re: A replacement for Danmakufu?
« Reply #646 on: August 13, 2010, 06:55:38 AM »
In other news - has anyone taken a look at the documentation I put up?  It'd be nice to get some feedback ... I'm not sure if what I wrote up matches people's expectations and such.

Everything looks pretty good to me. The script deconstruction styled tutorials work pretty well as a primer and the function descriptions are easy enough to grasp, at least for this novice Danmakufu scripter. The only one I really had trouble understanding was the description for SetPlural. Then again, there's nothing else in there about Plurals that I could find (bar NextPlural and LastPlural descriptions, naturally), so it could just be an issue of context.

Now for the main reason why I finally decided to post in this thread after lurking it for so long... I haven't actually tried scripting anything yet, but a question did come to me after stumbling on something in the latest test release. Do you intend to have the script browsing reined in to just the folder Musuu is in and its child folders or are you keeping it as is? As it stands right now, you can back up and away from the Musuu folder and look literally anywhere on your hard drive for compatible scripts if you know the way.

Nuclear Cheese

  • Relax and enjoy the danmaku.
    • My homepage
Re: A replacement for Danmakufu?
« Reply #647 on: August 14, 2010, 10:12:43 PM »
could you provide a sample of what a simple pattern might look like? so far, it looks less imposing than when I glanced at a random danmakufu script.

Here's a very simple sample, which simply creates a boss that stays still and fires a spread of 5 shots straight downward every second.

Code: [Select]
Musuu
Name[Sample Enemy]
Type[Enemy]

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

// TheEnemy
// Enemy boss that makes some danmaku.
Boss "TheEnemy"
{
   define count;

   initialize
   {
      // Set the image to reimu1.png
      // Also set it to always be aligned (don't rotate), and at layer 30
      SetImage("reimu1.png", false, 30);

      // set the collision sizes
      SetSize(18, 24);

      // Set the amount of life for the boss
      SetLife(150);

      // our timer variable
      count = 60;
   }

   tick
   {
      // decrement our counter
      count--;
      if (count <= 0)
      {
         // reset the counter
         count = 60;

         // Fire a spread of bullets
         angle = 140;
         while (angle <= 220)
         {
            FireShot01(GetX(), GetY(), angle, 2.5, "Shot1");
            angle += 20;
         }
      }
   }
}

This sample works in the current test release, although the boss won't despawn when she runs out of life, since that isn't scripted in the current test release (it is in the latest code, though).  When the next test release comes around, the boss will despawn properly when killed.



Hello

I skimmed through fast through the topic and i have a question:
IS this a new danmaku engine or  you're upgrading danmakufu?

This is a completely separate project.  I don't have the means to upgrade danmakufu, mainly since I don't know of any way to get the source code for it.


and is there some where a future list?

You mean a list of items that are planned to be worked on?  There's a list that PT8Sceptile put together ... lemme grab it:

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? (plural files partly implemented)
  • 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.

(Updated to reflect recent developments)

This list represent the current list of items for a complete first "real" release of the program.  There are also other items that have been thrown around.



Everything looks pretty good to me. The script deconstruction styled tutorials work pretty well as a primer and the function descriptions are easy enough to grasp, at least for this novice Danmakufu scripter. The only one I really had trouble understanding was the description for SetPlural. Then again, there's nothing else in there about Plurals that I could find (bar NextPlural and LastPlural descriptions, naturally), so it could just be an issue of context.

Plural scripts are basically a simplified way to string together multiple scripts in a row.  It's comparable to Danmakufu's Plural boss scripts, although much more flexible.

Basically, the way it works is that you give a series of object types using SetPlural.  Then, each time you call NextPlural, the object advances to the next object type in the list.

I do intend to add a separate file format that will make setting this up easier.



Now for the main reason why I finally decided to post in this thread after lurking it for so long... I haven't actually tried scripting anything yet, but a question did come to me after stumbling on something in the latest test release. Do you intend to have the script browsing reined in to just the folder Musuu is in and its child folders or are you keeping it as is? As it stands right now, you can back up and away from the Musuu folder and look literally anywhere on your hard drive for compatible scripts if you know the way.

I currently have no intention of limiting where the program can search for files, unless someone can give me a reason otherwise.

... although, admittedly, this does complicate replays a bit since it means it'll be harder to find the correct path for a script file that the replay uses.  Especially when combined with the fact that we select an enemy script and a player script.  Hmm ... perhaps I'll need to make with some trickery for the replay files.
to quote Naut:
"I can see the background, there are too many safespots."
:V

Something XutaWoo-y

  • Adorable Weaponsmith
Re: A replacement for Danmakufu?
« Reply #648 on: August 19, 2010, 12:24:32 AM »
Out of curiosity, would it be too much to ask for the ability to code multiplayer? I'm thinking about multiple things (player versus player danmaku, phantasmagoria clones, tyrian style player turrets), but I'd imagine that, with some ingenuity, it'd be possible to do all of the above by simply allowing more than one player character for certain scripts. And being able to switch player bullets hitting other players.

For the sake of GetPlayeretc (outside of the player scripts, anyway), perhaps an extra argument for which player to check?

Also, if this is for generalized danmaku shoot 'em ups, a way to replace the default life system would be nice.

Then again, considering the recent news, a English-based danmaku engine that will be consistent (hopefully), is always nice. :V

Lord Phantasm Satori

  • Permabanned
  • RIP 7/21/2010-9/10/2010
Re: A replacement for Danmakufu?
« Reply #649 on: August 19, 2010, 05:04:19 AM »
oh yeah, would bosses with multiple damagable parts be able to be done?

Nuclear Cheese

  • Relax and enjoy the danmaku.
    • My homepage
Re: A replacement for Danmakufu?
« Reply #650 on: September 06, 2010, 12:04:08 AM »
Well, here I am again.  I really need to stop getting distracted by shiny things new games so much.  Stupid me.

Sudden cat acquisition doesn't help, either. :V


Out of curiosity, would it be too much to ask for the ability to code multiplayer? I'm thinking about multiple things (player versus player danmaku, phantasmagoria clones, tyrian style player turrets), but I'd imagine that, with some ingenuity, it'd be possible to do all of the above by simply allowing more than one player character for certain scripts. And being able to switch player bullets hitting other players.

For the sake of GetPlayeretc (outside of the player scripts, anyway), perhaps an extra argument for which player to check?

There aren't currently any plans to support multiple players in the initial version of Musuu no Danmaku, at least.  On the bright side, it isn't something that hard to add in (just need to allow multiple player control configurations, spawn multiple player objects, and ensure the correct player inputs go to the correct objects, mainly).



Also, if this is for generalized danmaku shoot 'em ups, a way to replace the default life system would be nice.

Then again, considering the recent news, a English-based danmaku engine that will be consistent (hopefully), is always nice. :V

The overall plan is to make this as generalized as possible, so having a different life system could definitely be doable.  To get thought rolling on this, any particular ideas that you'd be looking to implement?



oh yeah, would bosses with multiple damagable parts be able to be done?

With the current engine design, you'd have to create multiple objects that encompass the various parts of your boss, but it should definitely be possible.





I've (finally) gotten off my lazy ass again and put some stuff down in the code.  Specifically, I added pausing, and a pause menu.  It currently only has "Resume Game" and "Return to Menu" options.

I also added the FPS counter in the lower-right corner; I think I might end up adding a config option to enable/disable its display later on.  Also a few minor code cleanup tweaks.


Yay progress!   :3



Next items on my list are stages and tasks.  To be honest, stages are practically already feasible, by just creating an invisible enemy that spawns enemies/bosses at certain times; in reality adding stages is just adding in an official base type for them in the script engine.
Tasks, on the other hand, will be quite the 'fun' task, code-wise.  I have a general idea of how I'm going to implement them, but it's gonna be a bit tricky.

Also, there's the optimizations on the collision detection engine I want to get in sometime soon.  Mainly, right now the engine loops through the entire list of objects in the game, determining pair-by-pair whether it needs to check for collision between the two objects.  On the other hand, the new approach will keep track of this information as objects are inserted and deleted, which should give a substantial speed boost in that part of the program overall.



Oh yeah - remember I said sonicbhoc disappeared?  The reason behind that is he's at college/university, where they have a massively restrictive network, such that he can't even SVN to the code repository. :/
to quote Naut:
"I can see the background, there are too many safespots."
:V

Something XutaWoo-y

  • Adorable Weaponsmith
Re: A replacement for Danmakufu?
« Reply #651 on: September 09, 2010, 09:40:29 PM »
The overall plan is to make this as generalized as possible, so having a different life system could definitely be doable.  To get thought rolling on this, any particular ideas that you'd be looking to implement?
For a few examples, a health system like in PoFV where you have a few hits, but you get pushed back and get blink invincibility when hit. Another example would be a plain standard system where you have a certain amount of hits before dying; like, say, in pretty much every game. :V
A way to do shields and "armor" would be nice; basically, a second health bar that probally regenerates and prevent damage to the player's real health until depleted, like in Tyrian. As for armor, it's like that but it doesn't complete prevents damage, just reduces it; think of something like in an FPS.

Of course, the latter two could easily be coded by the coder him/herself with a player version of SetDamageRate and tinkering with variables, so yeah. :V

Re: A replacement for Danmakufu?
« Reply #652 on: September 10, 2010, 06:39:30 PM »
I still say that if I were doing it, for maximum flexibility, rather than putting just about anything in the hardcode (bullet-types, how items work, death, hitboxes/graze, "continue," even field-size and UI-setup), I'd put specific game-details in default/example scripts which you'd, like, "include" in the user-made scripts, so that if someone wanted to make a setup like Suguri (which is almost entirely different from Touhou), the game engine wouldn't get bogged down with hardcoded defaults which would just be ignored by the script. Kinda like how RPG Maker XP/VX do it ...

Nuclear Cheese

  • Relax and enjoy the danmaku.
    • My homepage
Re: A replacement for Danmakufu?
« Reply #653 on: September 13, 2010, 01:21:35 AM »
For a few examples, a health system like in PoFV where you have a few hits, but you get pushed back and get blink invincibility when hit. Another example would be a plain standard system where you have a certain amount of hits before dying; like, say, in pretty much every game. :V
A way to do shields and "armor" would be nice; basically, a second health bar that probally regenerates and prevent damage to the player's real health until depleted, like in Tyrian. As for armor, it's like that but it doesn't complete prevents damage, just reduces it; think of something like in an FPS.

Of course, the latter two could easily be coded by the coder him/herself with a player version of SetDamageRate and tinkering with variables, so yeah. :V

I still say that if I were doing it, for maximum flexibility, rather than putting just about anything in the hardcode (bullet-types, how items work, death, hitboxes/graze, "continue," even field-size and UI-setup), I'd put specific game-details in default/example scripts which you'd, like, "include" in the user-made scripts, so that if someone wanted to make a setup like Suguri (which is almost entirely different from Touhou), the game engine wouldn't get bogged down with hardcoded defaults which would just be ignored by the script. Kinda like how RPG Maker XP/VX do it ...

Well, then perhaps I should let you know about the idea I had today.  Most things like this are actually handled via built-in script functions.  I think that, once I allow the scripter to create their own functions, I could also allow a script to override those built-in functions, which could easily alter the "default" functionality quite a lot.



Got a bit of stuff done tonight.  I added a formal "Stage" script type.  Looks something like this:

Code: [Select]
Musuu
Script[mdScript]
Type[Stage]
Name[A Stage]

Stage "Test Stage"
{
   initialize
   {
      // do stuff
   }

   tick
   {
      // do stuff
   }
}

When making a stage script spawn other objects (enemies, primarily), don't forget that you need to include the files which hold the scripts for the things you're spawning.

Note also that Stage types have a higher spawning priority than Boss types.  This means that if you load both a Stage type and a Boss type, the Stage one will be spawned as the default, initial enemy.


I also added in the mdPlural file format, which allows the user an easier way to define a basic plural object (like a multi-phase boss):

Code: [Select]
Musuu
Script[mdScript]

/ A sample plural script
/ Comments start with a '/'

/ Type and name of this plural object
Plural "Enemy Boss"

/ The various phases of this enemy
/ "file" "type"
"Enemy1.txt" "Phase1"
"Enemy2.txt" "Phase2"
"Enemy2.txt" "Phase3"

Note that the Plural type here (declared right before the type name, "Enemy Boss") indicates that this is a plural enemy.  This is done so that this script has higher spawning priority than its component Boss scripts.

In this case, the enemy boss is composed of three phases, defined as scripts within two files.


Right now, mdPlural doesn't support multiple type definitions in a single file (unlike the other script formats), but I can add it if there is demand (I figured it'd be much less needed than the other types, since you're probably not defining many Plural types except for gigantic game scripts, where you'd probably want a bit of organization anyways :V )
to quote Naut:
"I can see the background, there are too many safespots."
:V

Nuclear Cheese

  • Relax and enjoy the danmaku.
    • My homepage
Re: A replacement for Danmakufu?
« Reply #654 on: December 05, 2010, 03:02:33 AM »
Hey guys, remember me?
I hate that it's taken me so long (work, you know >__> ), but I've finally got another update to MnD!

I've gone ahead and implemented lasers!  :3


Right now it just works like this:

  • Use the CreateLaser01(x, y, angle, width, length, image) function to create an enemy laser.  It returns the object ID.
    Note that width only refers to the width of the graphic, not the collision size (which is set by the bullet data.
  • You can manipulate the laser's position, angle, etc using its object ID, just like with any other object.
  • If you want to create a custom laser-like object, you can include in your script the SetBeam(width, length) function, which makes the current object have a laser appearance (stretched image) and collision.
  • Lasers used line-segment based collision.  Effectively, their collision area is a radius around the defined line segment.


Additionally, there were a couple optimizations and code refactorings, as well as a bug fix to stop objects from collision-checking with themselves (oops, not sure how I let that through to begin with).



Here's the latest look at the running "to do" list:

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.



A few things about this list:
  • Tasks are going to be hard.  I know I *can* do them, it's just not gonna be quick and easy.
  • For "improved bullet control functions" - what are we looking for, here?  I can replicate a CreateShotA-like functionality, if that's what is wanted, but I want to know if that's all or if something more/different is preferred.
  • Given how little I seem to be able to get from ANTLR regarding errors (most important to me would be line numbers), I'm considering rewriting the mdScript parser/lexer by hand.  I know it'd be a bit rough (mainly due to how tedious such a task is), but it'd give much better reporting on syntax errors and such if I did.
  • For the sake of making replays not mind-bogglingly difficult to implement, I'm considering instituting a "players" directory (similar to what Danmakufu does) so that replays have a constant base-path for player scripts.  This way, replays can be saved alongside the enemy script, and both scripts can be found by the program without much difficulty.
to quote Naut:
"I can see the background, there are too many safespots."
:V

lumber_of_the_beast

Re: A replacement for Danmakufu?
« Reply #655 on: December 05, 2010, 04:22:59 AM »
Glad to see this is still in progress :D

Random musing: How exactly does one make curvy lasers?

Nuclear Cheese

  • Relax and enjoy the danmaku.
    • My homepage
Re: A replacement for Danmakufu?
« Reply #656 on: December 08, 2010, 11:55:58 PM »
Glad to see this is still in progress :D

Random musing: How exactly does one make curvy lasers?

There currently is no built-in support for curvy lasers.  I think they're a much lower priority feature than regular lasers, given how rarely they're used.

In the meantime, it would be possible to simulate a curvy laser by using a string of "chained together" lasers, but that would be a bitch and a half just to implement.



Also, for those keeping track - I can't guarantee any regular schedule for updates in the near future, since it falls on to several factors (all of which seem to be working against me lately  :colonveeplusalpha: ).  Apologies for this project slowing down so much.
to quote Naut:
"I can see the background, there are too many safespots."
:V

Nuclear Cheese

  • Relax and enjoy the danmaku.
    • My homepage
Re: A replacement for Danmakufu?
« Reply #657 on: December 27, 2010, 09:08:28 AM »
New progress - power system!
(in other words - the ability to set up power items and such.)


The basic idea behind it is as follows:
  • The game script will set up how power items scale and such, while the player script will be given a "power level" value to determine how it will act.
  • By default, the power system is disabled, and the player script will be instructed to act at full-power.
  • MnD tracks a "power amount" for the player, which is increased as they pick up power items and decreased when they get hit.  This amount has a minimum of zero and a script-defined maximum.
  • The script also defines a set of "power level" thresholds - when the power amount reaches a threshold, the player reaches the corresponding power level.
  • A player's "power level" can be in the range of 0 through 8, with 0 being the lowest level and 8 being full power.


To give an example of how this works in practice, here is the script to set up a powerup system similar to PCB:
Code: [Select]
      // Set PCB-style power system
      SetPowerDisplay(power_display_fraction);

      SetPowerThreshold(1, 8);
      SetPowerThreshold(2, 16);
      SetPowerThreshold(3, 32);
      SetPowerThreshold(4, 48);
      SetPowerThreshold(5, 64);
      SetPowerThreshold(6, 80);
      SetPowerThreshold(7, 96);
      SetPowerThreshold(8, 128);

      SetPowerMax(128);

      SetPowerMaxDisplay("MAX POWER!");


Here's a rundown of how it works:

The SetPowerDisplay function determines how power will be displayed in the HUD.  I'll go over the defined values below; in this case, it's setting it to display it as "<amount> / <max>".

The SetPowerThreshold defines the threshold amounts for each power level.  In this case, we define all 8 levels to correspond to the power amounts in PCB where you power up.

The SetPowerMax sets the maximum power amount - in this case it is the same as the final threshold.

The SetPowerMaxDisplay tells the game engine to replace the power display with the given text when at the maximum power amount.  If this is not given, the power display will remain as-is at max power.



As another example to show how this can work, here's a script to do a power system similar to MoF/SA (disclaimer: I haven't played as much of the newer Touhou games, so this might not be as accurate as the PCB-style script):

Code: [Select]
global power_value_2;

// ...
{
   // ...
   {
      // Set MOF/SA-style power system
       SetPowerDisplay(power_display_decimal_fraction);

       SetPowerThreshold(2, 20);
       SetPowerThreshold(4, 40);
       SetPowerThreshold(6, 60);
       SetPowerThreshold(8, 80);

       power_value_2 = 20;

       SetPowerMax(100);

       SetPowerLostOnMiss(20);
   }
}

For the general idea of this one, we are equating 20 units of power items with 1.00 value on the MoF display.  The powerup system works entirely with integers (to make life simpler), so we count the lowest denominator (0.05) as one unit of power.

In this case, SetPowerDisplay indicates a "#.## / #.##" display style.  What this does is match the MoF-style display, where the whole-number is the number of power thresholds you have passed, and the fractional part is the % you are to the next threshold.  (To be specific - in MoF, every 20 power items was equivalent to 1.00 - one 'threshold').

We only define thresholds for half of the power levels.  Since MoF only has four "power-up" points (when the player obtains each option), these are mapped to these thresholds.  The player will jump from power level zero straight to 2, then to 4, etc.

Here, we also define the maximum power amount to be above the last threshold.  Like MoF, this gives a "buffer zone" where you can lose some power and still be at the highest power level.

SetPowerLostOnMiss, as the name implies, sets the amount of power lost when the player loses a life.  The default is 16, but for this we want 20 (the amount of one threshold - equivalent to 1.00).

Finally, the business with power_value_2.  This is a globally defined value that determines how much power a large power items gives the player (for reference, the small item's amount is power_value).  By default, this is 8; here, we want it to be 20, which is enough to push the meter up 1.00 (one whole threshold).  The global statement at the beginning tells the game to treat the name as a global variable, rather than a local one, so we are sure to set the correct value.  I might end up making functions to set these values later on ...




In your player script, use the function GetPowerLevel() to get the current player power level, based on the above data.  Again, the value returned by this function is in the range of zero through eight, inclusive.



Finally, to spawn a power item, simply create a new object of type PowerItem (small power item) or PowerItem2 (large power item).




In short, this setup allows us to define the power system with the game, and still allow any player script to work with it by giving the player script a set of discrete power levels to work with.  I used both above power system scripts with the same player script, and it allowed the player script to utilize the two different power systems without any problems.  :D




There are six power display types defined currently (all are prefixed with power_display_):
  • none - doesn't display at all (the default).  This will not prevent a power system from working if you define the other values, it just won't show any value.
  • meter - shows a graphical meter that fill up horizontally.
  • number - just shows the raw power amount.
  • fraction - shows a fraction in the form of "<current amount> / <max amount>"
  • decimal - shows an MoF style #.## display.  The whole number digit is the number of thresholds met/passed, while the fractional portion is the % to the next threshold.
  • decimal_fraction - same as decimal, except it adds a "/ #.##" to show the maximum value of this display as well.


Happy holidays!
BV
to quote Naut:
"I can see the background, there are too many safespots."
:V

Re: A replacement for Danmakufu?
« Reply #658 on: December 30, 2010, 03:51:35 AM »
This is still alive?  Best holiday present ever!

If you would be kind enough to release another test version, I'll make something for you :)

Nuclear Cheese

  • Relax and enjoy the danmaku.
    • My homepage
Re: A replacement for Danmakufu?
« Reply #659 on: December 31, 2010, 04:01:20 AM »
This is still alive?  Best holiday present ever!

If you would be kind enough to release another test version, I'll make something for you :)

I'll get on that.  I just looked back at what's been done since the last test release, and it's a pretty big list:

  • lives and respawning
  • bombs
  • message functions
  • plural scripts
  • zerlolife script (mainly used to automatically despawn bosses currently)
  • pause menu
  • stage scripts
  • lasers
  • power system

Before I put out a release, I want to go ahead and throw together some quick scripts to demonstrate (most of) these features (as well as some other basics) - basically, I'm going to create a simple stage and such.
Don't expect anything amazing; last time I tried to create a stage it didn't end up with anything amazing. :V


Also, I'd really like to get some new graphics for (later) official releases ... I think the silly-looking blue triangle isn't exactly a 'professional-looking' character sprite, to say the least.  ;)



EDIT:

Test Release 7

Includes a whole new test script stage, with two variants that just have different power systems (PCB-like and MoF-like).

Player scripts have been updated to use power systems and now have bombs:

  • Simple Type
    • Simple forward shot
    • Faster shot rate as powers up
    • Bomb gives 4 seconds of invulnerability, as well as a faster shot rate
  • Spread Type
    • Forward spread shot; focus fire has a tighter spread
    • Wider spread as powers up
    • Bomb gives 3.5 seconds of invulnerability, and fires off multiple circles of shots during that time



I wasn't feeling too creative, so the sample stage doesn't (currently) feature lasers or anything using message functions.  :V

Also, don't expect any sort of balance in regard to difficulty as the stage progresses or between player types.  I just kinda threw this stuff together.


Enjoy!
« Last Edit: December 31, 2010, 05:50:06 AM by Nuclear Cheese »
to quote Naut:
"I can see the background, there are too many safespots."
:V