I’ve been spending a lot of time this week working on the new version of ANGELINA. I’m trying to make it more flexible than before, but it’s throwing up a lot of philosophical challenges too (the old question of how much to give ANGELINA at the start, that we saw in the previous projects too). I’m getting somewhere now though, with work in two areas – the first is a lighter, Java implementation of some elements of the Flixel language for game programming. This is going to help ANGELINA create games that are easily playable, while letting me stay entirely within Java for the first time ever. Good news.
The second area of work is blueprinting game designs. I’m playing with an idea of pre-design blueprint stages, where ANGELINA considers abstract game designs and does some evolution at this level before going and implementing anything. I’ll explain why I want to do that in another post, but for now let me talk about how I think these blueprints are going to work, and YAML.
YAML is a readable data-representation language that has lots of language libraries. This means it’s a handy, human-readable and easily edited way of distributing and sharing data. My intention is to have these game blueprints represented in YAML, and I have an example I drafted this morning that you can see here. There are two files – one contains definitions that describe objects in the world, like the player character, bullets and so on. The other contains unit operations which are little bits of action and change that can occur in the game. I’ve represented these as triggers and events.
You can’t see the entire scope from the little sample files I’ve made, but you can get the gist of it even if you’ve never seen YAML before. I’d appreciate it if you could take a look and let me know what you think – could you design a game like this? What would you change?
More on game blueprinting next week.
Looks usable to me, but it might be tough for game designers that are not into much programming. I’d make a “library” of pre-existing game elements for designers to use, and maybe have an editor to read and write the _impl file. Maybe this little thing I did once may be of use to you?
Also, another thing that occurs to me – you might need to add a score counter, or at least markings for which events are “desirable” and which are “undesirable” if you’re going to have an AI play these.
This will be important, yeah. I’d not considered how these games will be simulated yet, so good point!
Now that I’ve updated the system to include win_instance and lose_instance events, I can probably get the AI to take actions that lead it towards one state and away from the other, but it might prove too difficult.
Thanks for the input! Also I agree that it might be more beneficial to most designers to have access to higher-level game concepts. Maybe a GUI would help.