Castle Paradox

[FyreWulff]

You may have seen me mention Aileron before in this post.

As you can see, it clearly never got done in time for the next Hamsterspeak issue. This was due to various things:

Computer issues.
Timecrunch (spent a lot of time programming another site)
TMC feeding me new ideas.

But now I am ready!

I'm going to present Aileron over a number of weeks. I originally was going to post it all as one gigantic post, but I think this way will be better, since I can explain things in better detail and change according to feedback as we go along. Week 1 isn't actually going to show Aileron, but the reasons and general ideas behind it.


Why do you call it 'Aileron'?
Aileron the name is just a codename I came up with for this project. Aileron comes from 3 things.

1. It starts with the letter A, meaning it's a new beginning.
2. Ailerons are a part of an aircraft wing, wings lift you up!
3. James Paige works for an aerospace company. C-c-c-combo!

What is Aileron?
It is NOT a new version of the OHRRPGCE in the works. If I can release the program, it is just a GUI prototype.

It is NOT a functional branch of the OHRRPGCE. It cannot actually play, edit, or do anything with OHR games or files.

It is NOT a fundamental change to OHRRPGCE gameplay. Aileron will not change the fact that walkabouts are 20x20, the native res is 320x200, etc.

In fact, Aileron is 99% about the editor and 1% the game player.

Okay, so if you're not really changing how it plays, why did you start this project?

TMC kept bugging me to do something like this after I designed the current custom.exe music browser/player for TMC.

But I've also been wanting this myself.

To put it plain and simple. Look at this.



Now imagine you haven't been using the OHR before. You come across this screenshot. Are you really enticed to use this program? We all know the OHRRPGCE is easy to use - you can make an entire functional game without ever scripting, just using the keyboard and custom.exe.

But the reason the editor looks like this is because it's still stuck in it's MSDOS roots. And the OHR doesn't even run in MSDOS natively anymore. Back then, both CUSTOM and GAME needed to run in 320x200.

Other problems this interface has:
1) From what I read before, these menus are a pain in the butt to update.

2) It is hard or actually impossible to translate this program easily into other languages, since it uses the game's font files, which are limited to 255 fonts.

3) With newer operating systems like Linux, Mac OS and Windows Vista, this graphical interface is not compatible with accessibility tools like voice command and so on. For example, I was going to spend a weekend making a game entirely with Windows Vista's voice command functionality. As soon as I said "start custom", I lost the ability to do anything in custom, even if I told it to press the arrow keys.

4) This interface does not lend itself well to plugin functionality, and you have to bury a lot of features under other features.

5) You suffer from tunnel vision - you can only edit one thing at a time. You cannot edit enemy graphics and work on a battle setup at the same time, for example.

Aileron - break out from the 320x200 screen
The first thing Aileron fixes and discards is the idea that the editor needs to run in the same resolution as the game player. In fact, the game editor and player are merged together into a functional whole. Many other programs already work like this. For example, Game Maker automatically compiles and then launches the game for you when you hit 'play'.

Here is an early prototype of Aileron:



As you can see, there is already a basic idea.

* Users can select their tasks from the top menu, instead of having to find them in the current custom interface.

* Users can work on multiple aspects of the game at the same time.

About a day after I drew that prototype, I already had this. An easy job, just replicate functionality from custom:



Easy to read and use checkboxes, all of this can be controlled by the mouse, and we can easily add more bitsets via plugins without having to manually code them in. And we don't have to cram them into one screen anymore, we can even categorize these settings.

Another quick port, the general settings menu. Right now, the general game screen is kind of a dumping ground for options that can't fit in other places.

But split it off into it's own thing, and it becomes much easier to read:



So hopefully you have a good idea of where I'm going with this.

Next week: Vastly improved debugging and plugin functionality
Third week: Improving collaborative editing and editing your maps
Fourth week: Plugin functionality spotlight: replacing battle systems, sound systems, text display, internet multiplayer and more
Fifth week: ???

[msw188]

I just wanted to throw this in here; not sure if anyone else has mentioned this before.

The number one thing that I don't like about custom is how hard it can be to find things that I've created. Attacks are the easiest thing to think of. My games have hundreds of attacks, but there's no way I'm planning them all out to put them in some kind of order beforehand. It would be great if this interface could sort things by options other than ID number (like the attack's names, for instance), and even better if I could 'preview' the thing I'm about to pick in a list. I might have 14 different attacks called "Face-breaker", and I'd like to be able to see which one it is I'm picking while I'm picking it, rather than have to go to the attack editor to make sure it's the one I want. I'm not sure what the proper setup for such a thing would be (maybe one window is a consistent 'preview' window?), but I wanted to throw this out there.

EDIT: PS: Just realized I forgot to also mention how awesome this whole thing is.
_________________
My first completed OHR game, Tales of the New World:
http://castleparadox.com/gamelist-display.php?game=161

This website link is for my funk/rock band, Euphonic Brew:
www.euphonicbrew.com

[The Drizzle]

This is a great idea. Any copy and paste functionality for bitsets? My pet peeve is having to go through the list of attack bitsets and fill it out over and over again for similar attacks. That list is huge.
_________________
My name is...
The shake-zula, the mic rulah, the old schoola, you wanna trip? I'll bring it to yah...

[Newbie_Power]

I already stated that this was cool in IRC, but I want to state here that this is going to be awesome, revolutionary even.
_________________

TheGiz> Am I the only one who likes to imagine that Elijah Wood's character in Back to the Future 2, the kid at the Wild Gunman machine in the Cafe 80's, is some future descendant of the AVGN?

[NeoSpade]

This is what I dream of every night... This will be SO awesome, infact so much so that I may have to upgrade this post to bold text.
This will be SO awesome

EDIT: Oh on a side note, what is it compatible with, I mean besides Vista, and other modern OSs, I use mainly windows 2000 for OHR game making, so I was just wondering.

[Bob the Hamster]

This looks really spiffy.

I would be happy about moving the main development of CUSTOM in this direction eventually. We even have a plan ('Plan for an Editor Editor') that can get us there.

I know I have asked this question already, but since I can't remember what the answer was, I'll ask again; what language/windowing toolkit did you use to make this prototype?

[FyreWulff]

Visual Basic .NET express, the free one that you can grab from here

[Rinku]

I think this looks like a big improvement. But I think at least the option for the old method of editing should remain, since some people may prefer it. It's sometimes faster to navigate menus with a keyboard than with a mouse, and sometimes speed of editing is what one is after.
_________________
Tower Defense Game

[Bob the Hamster]

[FyreWulff]

[Kizul Emeraldfire]

I know I'm a late-comer to this party, but I just had to say this:

EXCELLENT!

I usually don't really like the Windows-y GUI style, but I love this idea very much — I think it might be a little more handy than the OHR as I'm used to it.

Quick question: will it have a built-in script editor/importer? 'Cause I think that'd be pretty much the cherry on the top of a sundae, if you know what I mean.

[FyreWulff]

Updates are stalled because I'm looking for a new place to live in, and am trying to get a new job that's constant instead of temp work.

It can have a built in script editor, that would be possible with a plug in or a basic one can be included. Just spawn a text editing window with a compile button and there you go. I actually tried making a simple HSS editor with visual basic but it seemed the standard text control only handles the RTF format, so that was a bust there..

[FyreWulff]

Still getting crushed by search and working and the etc!

A quick update though. This is ideally what improved debugging would look like.

This is going to be an abstract for now, I'll make an actual mockup for the next post.



The problem with the current OHRRPGCE engine is that everything is forced to display through the engine's 320x200 window. While this made sense when it was a DOS program (and therefore didn't have a choice anyway), this is very kludgy for an app that is using windows.

So the solution is to break all the debug functionality out into seperate windows. When you elect to run your game from within the editing enviroment, these will pop up by default.

Tag Editor and Manipulator

About the same as the current tag debug function in game. Scroll up and down a list to see tags being updated in real time. Click on them and set them to off or on. Easy to use and understand.

Script Debug and Script Tools

This is where this gets a little more interesting. The script debugger would be a lot more helpful as a seperate window. You could monitor which script is currently debugging. How much script buffer you are using. What is really helpful though, is the fact that you can track the value of a script variable. Want to watch the value of a global var change as you walk around the map? It will be much easier to follow what it's doing if you can watch it happen in real time, making it easier and faster to fix if something goes wrong.

Debug Toolkit

This would be a general purpose window for the time being. You could use this window to quickly teleport the hero to another map. Quickly give items to a hero, have the engine draw passability walls during gameplay, stop and start music, trigger a battle, or other misc features that are useful for quick debugging without having to run a looping script inside your game.

Of course, you could add more debug windows with plugins. For example, I didn't even show a possible in-battle debug window, because Aileron would be able to change it's battle system by swapping out plugins. But each battle plugin could come with it's own debug window. Imagine with the default battle engine, you can manipulate enemy and heroes to help adjust the battle, or see what move the enemy is 'thinking' of doing next.

Until next time..