Main Page » My Games » Villainmad »

2011/06/29 (Villainmad): Oh, This Is Still Here

Created: / Modified:

Always use secure-HTTP / Unsecure HTTP / Permanent Link

Is anyone still paying attention to this? So, yeah, after a while of Just Not Feeling Motivated, I've started working on this again. I need to completely reorganize the code again, but I'm going to wait until I've just got stuff implemented. Here's the latest build; here's the latest source; here's the latest XNA redistributable; and the latest version of your particular brand of Windows is up to you.

Player-input should work now (and I scrapped almost the entirety of what I'd done before); I'm still using Sixten's Lexy sprite, because Shintear's family's been on vacation and he hasn't been able to send me his own creations. Anyway, the game should work for non-Xbox gamepads. It should also work for different keyboard-layouts from English-QWERTY, though I haven't been able to test this and would appreciate input from other people. Otherwise, edit the settings.xml file in Notepad. Known bug: Pressing the keys in opposite directions is supposed to cancel each other out (so if you press left and right on the keyboard simultaneously, or left on the keyboard and right on the D-pad, it'll act like you aren't pressing either of them), but this isn't quite working with the thumbstick. Fairly sure I know why, though. Also, the gamepad settings are currently named after their Xbox equivalents, but I'll set it up so that they just use numbers. (You also currently can't have buttons numbered higher than 11 if you start with 1, but that's because I need to switch that part over to using Nuclex.)


Okay, some bad news here if you wanted to make your own scripts with Villainmad: it's beginning to look like I won't be able to implement this. The problem is security: the scripting is written directly in C#, which I can either do by letting you load the C# source-file at the game's runtime (more stringent compatibility requirements) or compile into a DLL file (so that you can't directly see its source code). However, I don't want you to be able to just load whatever classes and systems you want; just the ones that pertain to the game itself. For example, no using standard file input/output to directly read and write files, which can cause all kinds of chaos even if you don't have Administrator access. I've got the following conundrum:

  • The stage/game-controller scripts need to be restricted in what they use.
  • The game-system itself needs to be unrestricted in what it uses.
  • They game-system and the scripts need access to each others' public methods; the system needs variables on the scripts, and the scripts need system-functions like adding game-objects and my streamlined drawing-functions.

And if I'm understanding things correctly, these requirements are somewhat contradictory. At one point, someone on Twitter told me, "The correct way to do this is with AppDomains, which are more trouble than they're worth." I'll still leave it open-source, so you can make a game with it if you want, but ... Sigh.

Remaining items on my to-do list:
  • Config, which is already halfway done ... well, ¼ done, but the first quarter was the hard part.
  • Menus
  • Collision detection, and I already know how I'll do this.
  • Text/language stuff; The idea here is, rather than putting text (i.e. for character dialogue, menu-item descriptions) directly into the script files, you'll have an XML file for each individual language, as well as what fonts it'll use.1 I'll put together a program for translators (and me) to use that'll generate the XML syntax.
  • Replays
  • 3D backgrounds?
  • Any other major changes and rewrites I need to do
  • Actually making the game itself!

1Technical bit: if you try to load an entire font into memory, it can take up a lot of memory, especially if the font in question has i.e. every single kanji-character in Unicode. So instead, it goes through each character used by each string, and only loads characters you actually use associated font. So, for ordinary English text with no unicode, if it just so happened that you used every letter of the alphabet except lowercase x and capital Q, it would simply not load those letters.

10 Comments (auto-closed) (rss feed)


Oh, I know how the "Just Not Feeling Motivated" stuff goes :|

looking good tho. i like the effects the bullets have there with the color changing

Dizzy H. Muffin

The color-changing is actually a test of the "change an object's type" code. :3c


Hah, looking good, I was actually starting to wonder if you were still working on this since there hadn't been any updates about it for quite some time - glad that you're still doing it though.

A teeny-tiny bug(?) report, if you could call it that - if you do the double-key hold on a keyboard, so that your sprite doesn't move, you can still go backwards (but not forwards). I'm not sure whetever if this was intentional or not - I also haven't tested if this is occurs with a gamepad.

Finally, some for-the-far-future personal request. If you decide to add backgrounds, please try and avoid what ZUN does with some of his levels and make the background white/really bright and the bullets white/really bright too... Some contrast is always nice. ;3

Dizzy H. Muffin

Yeah, I dunno what's up with the bug. I've tried it with an XNA "game" I made with the sole purpose of testing out Nuclex input, and when left and right are both held down, the system actually doesn't recognize when you're pressing up, whether it's in Nuclex or not, even though it recognizes down. (Nor does it recognize left when you hold up and down. Also, I'm using XNA's built-in system for the game's keyboard-input, since Nuclex doesn't recognize some of the keys, such as shift, ctrl, alt, and F10)

And yeah, I'll keep the contrast-suggestion in mind. ;)


It seems you are running into one of the biggest challenges of API design, how to make you're API open enough to be flexible, but closed enough to maintain security and avoid exposing too many implementation details. It is a VERY difficult balance, as you are finding out the hard way.

Sadly, I have not really worked on many big programming projects, so I can't give you any concrete advice on this aspect. But I wish you best of luck. :)

Dizzy H. Muffin

Well, it's already going to be open-source, so "avoid exposing implementation details" is a non-issue. That said, I'm probably just going to take the Minecraft method, which is "the complete, unabridged source is the 'modding API.'"


"Avoid exposing implementation details" isn't a security issue. It's a design issue. It's the idea of separation of concerns.

Being able to tell if something is well designed or not is one of the artsy sides of software engineering, I feel. It's a (learnable) skill.


"isn't *only* a security issue"

(excuse me)

Dizzy H. Muffin

Oh, I see. But yeah, as far as modding encapsulation is concerned, I'm not even that far yet.

Dizzy H. Muffin

This might be useful, but I'm not quite sure how. Might have to pose a question to someplace like StackOverflow ...