Oddworld Forums

Oddworld Forums (http://www.oddworldforums.net/index.php)
-   Fan Corner (http://www.oddworldforums.net/forumdisplay.php?f=7)
-   -   Open source ALIVE engine (http://www.oddworldforums.net/showthread.php?t=18528)

STM 05-05-2010 08:39 AM

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

Jango 05-05-2010 08:40 AM

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 05-05-2010 09:24 AM

Want to see my penis?

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

Varrok 05-05-2010 09:42 AM

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

Dean Monti 05-05-2010 10:46 AM

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 05-05-2010 11:26 AM

"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 05-05-2010 11:58 AM

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 05-11-2010 04:12 PM

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 07-31-2010 07:59 AM

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? :D

joshkrz 08-07-2010 06:30 PM

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 08-08-2010 11:04 AM

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 08-08-2010 12:09 PM

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 08-08-2010 02:07 PM

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 08-08-2010 02:17 PM

:

()

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 08-08-2010 02:40 PM

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 08-08-2010 02:47 PM

:

()
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 08-08-2010 02:51 PM

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 08-08-2010 02:56 PM

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 08-08-2010 03:03 PM

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

joshkrz 08-08-2010 03:27 PM

:

()
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 08-08-2010 03:31 PM

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 08-08-2010 03:34 PM

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

joshkrz 08-08-2010 04:33 PM

:

()
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 08-08-2010 04:57 PM

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

Paul 08-16-2010 11:04 AM

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 08-31-2010 06:29 PM

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 09-01-2010 03:28 AM

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 09-01-2010 05:51 PM

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

Paul 09-12-2010 03:23 PM

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 09-17-2010 07:17 AM

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!