Danmakufu.NET - C# oriented Danmakufu clone

[SupahVee1234]

Danmakufu .NET
WIP: pre-alpha / planning stage


What is it?
Danmakufu.NET is yet another danmakufu clone. A very object-oriented clone. Danmakufu.NET reads external C# files, compiles them at runtime, and uses them to let the user create games.
Obviously, you have to know C# (or Java, which is pretty similar) to make scripts.

The current data setup is like this:

Data -> Gamemodes, Players
Gamemode -> Code, Resources, Entities, Scripts, main gamemode file
Player -> Code, Resources, Entities, Scripts, main player file

Code: folder containing useful classes (usually static) that contain useful, often used functions.
Resources: folder containing images, music and sounds for the script.
Entities: folder containing entity classes, such as enemies, bullets, familiars, etc.
Scripts: folder containing bullet pattern classes. You can "attach" one or more patterns to entities.


What's done so far?

• Dynamic compilation system (runtime compilation from external .cs files)
• SFML integration
• Primitive entity integration
• Primitive game mode integration

What should I do?
Well, I supposed you've read how the program is supposed to work. Since I've done practically nothing, I can radically change the data setup and other stuff. Do you think I should make any changes?


Here's a video of an un-animated Sanae shooting stuff.
http://www.youtube.com/watch?v=txe5URLD8eA

And here's how it was done.

http://pastebin.com/jzUPYBrP - Sanae player script, main class
http://pastebin.com/7ygZ1Hin - Sanae player script, shot class
http://pastebin.com/SAMg9qjZ - Sanae gamemode script, main class

Do you like this approach? Keep in mind that I will trivialize many of the stuff you've seen in the above pastebins by making some external libraries to quickly making bullets with commands such as CreateShotA or stuff like that. Overall, do you feel this is the right approach?

[Gc]

I can see problems if people know a bit too much of C# *raises hand* and start deleting system files *lowers hand*

However, if this means I can use my Visual C# 2010 to code bullet patterns, I <3 you.

[SupahVee1234]

I can see problems if people know a bit too much of C# *raises hand* and start deleting system files *lowers hand*

That's true, unfortunately. The only thing I can do is restrict the System.IO namespace, but that can also be used non-maliciously. I guess you just have to trust the script uploader, and read user comments before downloading the scripts. I could also have a server hosting scripts verified by me personally that can be automatically downloaded ingame and instantly become available to play.

Well, downloading scripts would be the same as downloading any application. Just be careful, and if it doesn't look legit, don't download it.

However, if this means I can use my Visual C# 2010 to code bullet patterns, I <3 you.

Could you please take a look at the pastebins and tell me if you like/dislike the code? Thanks

[SupahVee1234]

I've got some design problems.

The bullets the player fires are a class. In this case TemplatePlayerShot.
Now, I have to check if player bullets hit an enemy.

However all the entities are stored in the same list, how can I check is an entity is an enemy?
I could either have a global interface "IEnemy" which all enemies should inherit from, or have a separate list of entities which contains only enemies, a list that contains only bullets, etc.

What is the best solution?

[Gc]

If your Enemy class inherits your Entity class, couldn't you just :

Code: [Select]

foreach(Enemy en in EntityList)
{

}or something ?

[SupahVee1234]

If your Enemy class inherits your Entity class, couldn't you just :

Code: [Select]

foreach(Enemy en in EntityList)
{

}or something ?

The point is that I don't have an Enemy class. Users create enemies in external cs files that inherit from Entity. That the player script cannot "see". Maybe I should hardcode a base Enemy class, though.

[rfw]

Having interfaces or even base abstract classes would be a good idea in my opinion, as it reduces the amount of boilerplate required and simplifies organization a lot. You could even clump them into a single List<Entities> and run update calls on each of them, as defined by the base class (at least that's what I would do).

I'd like to see DLR support as an milestone somewhere (IronPython IronPython IronPython IronPython IronPython), since CodeDom is messy at times and not particularly flexible, and hardcoding danmaku/having an external assembly for it is a little horrendous.

Also, why SFML? I'd like to hear your rationale behind not using XNA.

EDITEDITEDITSOIDON'TDOUBLEPOST: You could also have collision bitmasks or some kind of struct to define if it is a) a bullet, b) the player, c) an enemy or d) the flying spaghetti monster's noodly appendage. Not the greatest thing to do, but whatever. The alternative with an enemy base class looks something like (LINQ abuse follows):

foreach(Enemy enemy in from entity in this._entities
                       let enemy = entity as Enemy
                       where enemy != null
                       select enemy)
{
    // do something here
}

ANOTHER EDIT FFFFFFFFFFFFFFFFF: Just wondering about the comment "The base constructors requires a string parameter that must be IDENTICAL to class name and file name" -- why use a string argument to a base constructor when you have reflection? Something such as myGamemode.GetType().Name would surely suffice? We're not in Kansas C++ any more!