Open source ALIVE engine

[STM]

Dean Monti, is obviously new, no Max never did he just dreams about working with them!!!

[Jango]

Smooth moves knucklehead!

Why won't someone just answer his goddamn question?

EDIT: Oops, looks like someone did! Literally when I was typing this post...

[MeechMunchie]

Want to see my penis?

I'm going to let someone else answer that question.

[Varrok]

I think everyone else's answer for that is totally opposite to yours...

[Dean Monti]

Wait, so if 'Max the Mug' never worked on Abe's Exoddus, what were the last 3 comments in the first page of this thread about? a guy says that he hates the music which is played when you enter a secret level in AE and then 'Max the Mug' tells him that he was the one who had put in that music which plays when you enter a secret level in AE!! and then there was something about the guy being a pussy.....

And could someone please tell me what MMOSG means? And was Hand of Odd released or not? If not, why?

[Wil]

"MMOSG" stands for Massively Multiplayer Online Social Game. The Oddworld MMOSG is a fan-created environment on the MMOSG Furcadia made primarily by Ajiellyn, but I helped a bit in places, including putting that sound in.

Hand of Odd was cancelled because OWI needed to concentrate on Munch's Oddysee as its release date approached.

[Dean Monti]

Oh now I get it....

btw I heard you guys are trying to rebuild the ALIVE engine...
If you need someone to code any small programs or tools you might need to build the engine, I happen to have a fair knowledge in programming with C++, VisualBasic, QuickBasic and Pascal, (but mainly C++) so if you need any help...

thanks

[Paul]

Help will definitely be needed for this project, at the start it will be things like mapping resource Ids on to human readable names for the editor and so on.

[Paul]

Bump...

I'm starting a basic editor that may never get finished Just in case you don't know it will be an editor to create AO/AE levels for a custom engine.

Since I suck at designing UI's I was wondering of anyone could throw together some ideas/concept screen shots?

For the first version of the editor I want to allow compositioning of screens.

Edit: I doubt it but.. do we have any idea what the official editor looked like?

[joshkrz]

I have attatched an extreamly simple concept to this post. Is this the sort of thing you wanted? I can elaborate and design it in more detail if you like too.

[Paul]

Thats exactly what I was after Could you explain how its supposed to function (E.g what if some screens are far away cause you teleport/touch stone to them, how to add new screens etc?)

[joshkrz]

Well for perspective screens a layer panel (obiously two layers) would have to be used and placed in the screen navigator panel.

As for linking to screens perhaps each screen has an ID and a refrence name like:

Level 1, Zulag 3, Screen 5 would be:
010305 (Zulag exit with slig)

The refrence name would be a input feild for the user to identify screens easier.

As for the background in screen 5 its code would be:

010305.5

Also to add new screens a [+] button will be added to the screen navigator, the screen navigator will be drag and drop so you can move them about. Also the arrows around the design area will move to the next or previous screen respectivly but if there isnt a screen it will create a new one.

--

Now in regards to teleporting, hoisting and general actions to interact with the enviroment, I would sugest tools in the tool box, such as a Teleport tool, where the user selects the tool, and clicks a box to set that box to teleport. To link two of them they would have the same value.

These will need triggers too, so if abe steps on a floor switch, he will teleport. Switches and story stones and the like will need an option in the properies panel to link the trigger with the action.

--

Also different views would be needed. So a "Object" view, "Character" view, "Map" View, "Mechanics" view and "Movement" view.

Object View: Allows the user to place objects and set their properties.

Character View: Allows the user to add enemys, possesable objects and such and change their AI. For exmaple, a slig can patrol, sleep, or be staic.

Map View: Allows the user to add map items such as walkways or walls.

Mechanics View: Allows the user to add triggers, death, wells, exits, teleports.

Movement View: Add boxes where abe can hoist, has to crouch, ect.

--

Now these ideas are raw and need much thinking over expecially scince i don't know what is possible and whats not.

Hope thats OK, give me a shout if you need a refined version of the GUI.

[Wil]

Regarding codes for screens, why not use the pattern established by AO and AE? xxPnnCnn, where xx is a string of two alphanumeric characters that identify the level, and nn is a string of two numerals used to identify the path ("bit of level") and camera (screen).

Regarding screens that are not contiguous with any others, would it be easy to create a filter for "orphaned" screens? This is a useful category when editing wikis, but I don't know how you could easily determine whether a screen was orphaned. Considering only screens with no neighbours would ignore two screens next to each other but disconnected from the main path.

[joshkrz]

Regarding screens that are not contiguous with any others, would it be easy to create a filter for "orphaned" screens? This is a useful category when editing wikis, but I don't know how you could easily determine whether a screen was orphaned. Considering only screens with no neighbours would ignore two screens next to each other but disconnected from the main path.

Well i suppose you could check if any "doors" have been added to any surrounding screens (doors as in areas where abe can walk, drop or hoist into the next screen).

if there are no "doors" connecting to the screen, it is classed as orphaned? You would have to count actual doors too.

[Paul]

Hmmm after thinking about all the possible combinations of screens, I think perhaps maybe a massive scrolling area might be the best approach? (E.g like the canvas of MSPaint?)

I think the first thing to really nail down is the laying out of screens and connecting them together.

I don't think that doing a manual "File > add screen" or whatever is a good idea though.. picking the bmp file manually for each screen would seem like a massive PITA...

Another thing is that there would have be something to edit each cam file itself, since you need to beable to edit the layers of the cam file and whatever parts of it are animated.

[Wil]

I don't think that doing a manual "File > add screen" or whatever is a good idea though.. picking the bmp file manually for each screen would seem like a massive PITA...

BMP being the image for the background? How else are you suggesting these be added? If the user had a set of backgrounds already, they could load them into the editor, a screen created for each... but where to place each screen? Plus I don't think it's good to require a background for a screen during the development of a level.

A file > add screen option would have to be available for users who had a partially completed level and decided it needed an extra screen, and for adding intentionally orphaned screens like those used for story stones.

[Paul]

Adding a "blank" screen can use the test image as seen in the hidden part of the AO demo.
But I mean would you really want to manually select tons of images one by one? I was thinking you would create some custom archive format/library of background images for a given level.

But the format would actually allow for cloning/setting of layers/animations (not object animations, but meat barrels in the background for example).

[joshkrz]

Are you using CAM files as backgrounds? Wouldn't it be easier and more compatible to use JPG or PNG?

As for the screen editor, my initial idea was to have a layer for each "hight" level and also have a full screen editor to plan out your level. That way, the user has access to a limited navigator when adding objects and triggers and a full screen editor to actually plan his level with added functionality.

[Paul]

Definitely not JPG! Lossy compression :P And not cam either, but something similar to cam that allows for background image, layers and animations.

[joshkrz]

Definitely not JPG! Lossy compression :P And not cam either, but something similar to cam that allows for background image, layers and animations.

The only thing I could think of is SWF I suppose that would be perfect but it would tke ages to actually make a SWF for each background.

GIF has too little colour. What about a PNG sequence? It wouldn't be one file though.

[Paul]

I guess it would be a custom format, likely a collection of bmp and other binary data. I know this would be large in size but I don't think thats a factor during level development (when the level is "compiled" it would be converted to the game engine format which would be something more sane).

[Havoc]

I need to keep a good eye on this, it's starting to sound pretty awesome.

[joshkrz]

I guess it would be a custom format, likely a collection of bmp and other binary data. I know this would be large in size but I don't think thats a factor during level development (when the level is "compiled" it would be converted to the game engine format which would be something more sane).

So would the level editor be able to create these?

[Paul]

Yeah thats exactly it The UI just needs to present it in a nice manageable way

[Paul]

Bump.. I've created this to allow laying out of screens. If you right click a screen you can add a new one to the left/right/top/bottom and right clicking anywhere that hasn't got a screen will let you create a new one that fits in the nearest "block".

I think this seems like the most sane way of laying levels out.

Edit: Update with real screen images.

[FlakyRock]

hmmmm... I just have one question.
Are you creating another version of the A.L.I.V.E. engine? Like, is this going to be like a, simple level editor when its finished? Like drag and drop? Or complex? Complex would be better.

[Paul]

Yes I plan to create another version, I want the editor to be simple but flexible, a simple user interface doesn't mean its limited

[FlakyRock]

Ah ok, thats good then
I have been looking at this thread for a while and I must say good job so far!

[Paul]

Just to bump this thread, if anyone wants to help with this project please let me know! What you'll need:

1. Lots of spare time!
2. Be able to endure long and repetitive tasks
3. Good technical knowledge (although not a must)

I likely won't need any help for a few months though, but I figured its best to have help on hand

[mlg man]

1. Lots of spare time! - Check!
2. Be able to endure long and repetitive tasks - Check!
3. Good technical knowledge (although not a must) - Check!

Im sure i can help out!