Possible ALIVE project...

[RoryF]

The idea here is to make a sort of recreation of the original ALIVE engine used in the first two games, the main difference being that it would be much more open ended.

It would be a good idea since it would provide the ability to: first, actually ADD new stuff (by that I mean, something missing from the original ALIVE engine that could be used to improve level design), and avoid the annoyingness that the engine itself makes (basically, Exoddus).

Obviously it will take some time, and already I have started on a version to see how far I get with it, and I will upload the project file (it's VS2010 C#) after enough updates every now and then.



Some stuff I've got started on here though:


Firstly, I have been working on implementing the texture system. At the minute, all textures you want to load into the game need to be defined. This is the TEXDEFS.DAT file, plain text, but it has rules obviously...

TEXDEFS.DAT Preview

The idea is that textures/sprites can be manipulated as standard images (bmp for the minute as I get it working), and then the TEXDEFS file will tell the game what to load and how/where to draw them. This allows you to edit the sprites in an easier way.

Another reason for doing this is obviously you need to own the game's assets (or make your own), so you need to use Paul's Decoder app to retrieve the game's sprites to use them in the engine. You just put them straight into the TEX folder where the TEXDEFS.DAT is, or you will need to edit TEXDEFS.DAT and tell the game where you are storing the sprite files. At the moment, I am writing the texture definitions as I go along, using the default filenames made by Paul's Decoder.

Here's how my TEX folder is so far:



The way I'm planning on developing it, is as follows:

1. Get animated sprites working, and add in all of Abe's sprites.
2. Get some sort of physics and basic level construction with a good file format (including loading backgrounds and foregrounds from pngs).
3. Work on a generic class for actual interactive objects (bombs, sligs etc).
4. Put in the normal environment and non-thinking obstacles (bombs, levers, wells etc).
5. Around this time would be working on level-level transport though said objects (also; hubs!)
6. Now add the thinking stuff in (sligs, scrabs etc).
7. Final fixing up before first sort of done release.
8. Improvements on top of that and possibly some other thingys to make other thingys with.

Finally, as a result on the work I've done with the textures, here's Abe's standing still sprite loaded from the extracted ABEBSIC.BAN:



Remember; it's still work in progress!

[Phylum]

The AO sprites are semi-transparent, with the black somehow representing transparency. I can't remember quite how it worked, but I do remember running into issues with the middle of sprites randomly being see-through when I last played around with them. I think I rendered them properly once with a DX blend mode, but I can't remember what it was.

If you want to be really clever and actually make this flexible you really need to implement some kind of scripting. I'm currently working on a VM-turned-script-interpreter (that still reads from an intermediate bytecode-like format) and one of my first ideas for when it's done is actually a bit like this, or at least something simpler which starts to define a framework for an ALIVE-like engine. My end goal would be total asset replacement, though, to allow for things like hats and colour customisation a-la Aji's Oddworld dream.

ALIVE has lots of little intricacies. You really need to think carefully before you dive too far into this. Really carefully.

[RoryF]

I plan on making it use a sort of plugin interface, where you can edit nearly all of the engine stuff once a call is invoked and essentially write whatever you want using C#. The engine objects themselves will be held together under a global class, in which you simply do something along the lines of:

EngineObjects.Add(new MyObject(blah blah), X, Y, other vars)

In addition, I will hopefully put in some event thing so you can hook stuff, possibly in the similar way.

Also the line in front of Abe is part of the sprite for whatever reason, I could change the TEXDEFS to blit it out by default, but yeah I know about the transparency, just look at the explosion sprites.

[Phylum]

Well the obvious flaw with letting people run their own code is security.

[Job McYossie]

I've always wanted to see the ALIVE engine run something not Oddworld. I always thought that it'd make for a great engine to release story based platformers. I wish I could help, because I am so behind this, my the furthest I might be able to help is with basic graphic design, but nothing about any sort of code. I really do wish you well with this, and am glad you are doing this!

[Phylum]

ALIVE is a garbled mess built around a game that seemingly changed a lot over time. Even the basic cinematic movement doesn't really work properly.

I think the best example of how much of a hack the ALIVE engine is were the special ground objects elum required to not break everything. "When something doesn't work properly, hard code a special case because we don't have time to change the requirements again" is a great programming motto.

[RoryF]

I plan on making a lot of stuff editable not only using files, but things such as what items you're allowed to hold (grenades/meat/rocks) etc. using game commands loaded from level file data (or changed in the game console). So in with the instructions for the game to build the level, you'd have something like:

SSET CANHOLD ROCKS,GRENADES

I've worked out an idea for how possessing stuff will work, it's pretty simple actually and should be quite flexible when it comes to making new stuff. For now, I'm working on getting the ANIMDEFS done in a nice way.



Looks easy enough for now...

[Paul]

I had this idea a few years ago

http://www.oddworldforums.net/showthread.php?t=18528

And some animations running with a cam/background:

https://www.youtube.com/watch?v=kdhI...136P7aCnT-uvzQ

I would recommend you use C++ rather than C#, C++ can be ported to almost anything. Any indie game such as The Swapper which used C# always ends up getting ported to C++ for other platforms.

LUA seems to be the defacto scripting language to use these days too.

Edit: Also!

You should really consider writing the engine tools before the engine itself. Its not very flexible to have some text files to setup animations and such. You need an object editor which lets you preview animations, setup animation transitions and set up AI scripts for that object etc.

It would be a huge task to get this working properly You'd really need to think about the design first.

.. and of course a full blown level editor so people can actually create content with their new objects or edited existing objects.

Then you could think about a basic engine just to display the content from this - if its a new engine you'd want a way to dynamically reload the content on the fly. Then you could get into the harder things like making the AI work and getting the game play correct. Don't forget you'd need a "real" sound engine too.

Edit again:

And not to sound too negative - I think this is a good idea (hence why I suggested this a long time ago ). But LUA/C++/SDL or SFML would be much better than using C# frameworks.

A proper design would be the first step though - then you could get a mercurial repo up on bitbucket or something.

[RoryF]

Yeah, I decided after re-reading that thread to start the project, and just to be reassuring, I did put a lot of thought into possible problems beforehand so it's not a completely blind thing that will branch off into thousands of ideas and never deliver.

About C#, I will have a go at making it in C++ if that's what you recommend, it'll need me to obviously rewrite the stuff I have got (shouldn't take too long). In regards to the text files, it's mainly there to serve as a sort of template, I will write the tools to manipulate them easier once I know the engine loads them in correctly.

The basic engine stuff is what I'm working on at the moment , the image I put up was to test if it was loading and drawing in Abe's images properly, I'll be using a similar thing with animations and then hopefully the CAM images. The reloading of stuff though... there is a console which I've put into the engine, so commands for reloading and changing stuff can be sent into it easier.

[Paul]

I'd highly recommend you use SFML, its cross platform so you can build for Windows/Linux/Mac etc. No need to write tons of boiler plate code to create window contexts and the like.

http://www.sfml-dev.org/tutorials/2.1/

[Phylum]

SDL is also good, but is written in C so things don't always make 100% sense in a C++ context. But hey when do they?

I'm going to stick my neck out and say to use D over C++, but that's probably just me being controversial. I have minimal C++ experience by choice, because I just found it incredibly unpleasant to work with. At the moment I'm not afraid to say that I prefer wrestling with C, although I'm still doing a few smaller D projects on the side to get more fluent with it.

e: Actually, most (all?) of the time you have to deal with structs in SDL it gets abstracted by methods, so they look like objects. It would fit pretty well with the style of C++ code. I don't really know if that's a good or a bad thing at the end of the day.

[Paul]

with SDL you end up writing a bunch of C++ wrappers. Old SDL is also a software rendering lib which won't really be up to the job. SFML is a OpenGL wrapper so is much more suitable, assuming you actually want 1080 res.

D isn't really adopted much yet - its compilers suck and there are only a few targets for it. Most other libs don't have bindings to D either. If I had to pick a rare but new programming language then I'd use Go over D.

Pretty much any multi plat game engine is written in C++ these days since its old, proven and has tons of support/tooling/resources and can target pretty much any CPU.

[RoryF]

You've got to bear in mind that I don't know that much C++ and only just come across SFML now that you've mentioned it. I'm not sure whether it would be a good idea to actually get stuff done using things I know for now, or spend ages learning these first and make it using them afterwards.

At the moment, I'll make the tools for the animdefs and stuff once I've made sure they're displaying properly, I'm not working on actual physics or any of that until I know that it works right (also need to do some tweaking with the startup sequence, the loading of textures is being done before anything is displayed at all, need to sort it out!)


EDIT:
Also, there needs to be a good name for this thing, I only called it csA.L.I.V.E. simply due to not being great at coming up with names, and it being written in C#. If anyone actually has any ideas, go ahead and say. :P

[Paul]

What graphics API are you using? DirectX?

[RoryF]

I think it's DirectX, I'm currently using the XNA 4.0 libraries (as annoying as that is), until I figure out how to work with OpenGL without it being a pain. I plan on changing to a better library after getting the testing done for the texdef and animdef file formats (which is 90% complete).

Here's some drafts for the tool to create the ANIMDEF and TEXDEF files, I should probably pack these into one file rather than scattering them, but I'll do that as soon as I sort out the level layout format.

Here is an image of a possible ANIMDEF editor:


Next is the TEXDEF editor:



You'll be glad to know I have ANIMDEFS pretty much working, though the next step is to find a better library than XNA.

Edit:
I just realised, I missed out the boxes for scaling and transparent blitting options, oh well, you get the idea of the gui anyway.

Edit2:

Work starts on whatever this tool will be called, I have a good plan to combine the TEXDEFs and ANIMDEFs that to be honest, I should've done in the first place. At least it means I get to use that loading screen from AO temporarily.

Edit3:

Here's some good news: I've started working on a way to get everything organised and a method of making the engine work the way I think it should.

Firstly; to do with the TEXDEFs and ANIMDEFs, they're needed to get this working is the simple thing; however I've been putting together a format for instructing level building. This doesn't mean I'm putting it in the engine this instant, and don't worry, it's not something that I've dived into 90% of the way and justifies how the engine will work already.

LVLX (for now - can't call it LVL otherwise there would be confusion of course), is what I have in mind for hopefully telling it what to do with levels.

Essentially it contains instruction in four main parts:

CAMDEFs - Tell the engine what images are being used for CAMs, how to reference them (like the R1P15C01 or whatever in the original), and what X and Y they are. also I need to sort out foreground bits too! almost forgot that...

OBJDEFs - Really simple, a couple bits telling the game what an object is that you want to use on your level, say a slig, contained as a compiled library in %gamedir%\mylevel\slig.dll, obviously with the whole security thing, the best I can do for now is make the editor/engine scream at the user until they are 100% sure they want to load it.

LVLBUILD - Where the instructions are contained for adding the objects defined in OBJDEFs come in, this basically will tell the engine how to create new object instances (XY coords, variables that you might need, blah blah).

LVLINFO - A simple segment that isn't 100% needed, but tells the engine what version of LVLX it's using in case it is updated and some converter might be needed to get it to work. In addition, you can stick author, par time, comments, level name and just all that general info.

---

You might be wondering where TEXDEFs and ANIMDEFs are, I've decided it would be best to give each individual object control over it's own one. It would make the whole thing easier to manage when someone wants to edit stuff. For example, say you had slig.dll in a folder, you could also put texdefs.dat and animdefs.dat in that same folder, link them in the .dll and load it that way.

Also it means you don't spend 500000 years loading bitmaps the moment you run the engine; which is not a good idea whatsoever (there's a loading screen for that!)

---

Oh and the .dlls themselves can be loaded in a similar way plugins do in things like Paint.NET and CraftBukkit, using an interface to get AI responses to stuff like gamespeak and keep track of what needs to watch input or not (this is how possessions will work).

... I can't wait until the 4th edit when I make the tools.

Edit 4:

Not the tools; but this is to do with the visuals of the game... the best I really can do is a set resolution, probably 640x480 like the original game, if it reeaally needs to be bigger, I will think about a way of setting it up to do such a thing.

On top of that, looking back at the level thread again, I almost didn't think about the background, like how Abe and stuff can appear in two layers, a little annoying but meh. I'm thinking, I should add a variable into the ALIVEObject class to tell it what layer to draw it on, obviously invoked using the interface of course...

Edit 5:

Just quickly, because rereading it I don't know if I mentioned; the AO spritesheet thing is the thing that sparked the creation of TEXDEFs. I know that the black represents transparency, and that's what I mean when I say I missed that part out in the gui draft.

That's the main issue with bitmaps, the engine will have to spend a lot of time keying out the colour, if you use PNGs, well, HELLO ALPHA! So the engine screenshot I did above was a test also to make sure that it was getting rid of the colour correctly, I did not edit any transparency before loading it into the test.

[gishygleb]

Alpha problems? The solution is simple. Most of sprites have the black color as alpha, when some other (as "explosion","orb") have an opacity based on the colour's lightness. Dark colours become less opaque, when light ones are seen fully.

In Photoshop you may see a "Background Eraser" tool doing such a thing at 50/50 setting.

By the way, what is your progress?

___________________________________________________________________________
Lightness-based opacity's formula is (for RGBA):
A = ((R/MaxR)*(G/MaxG)*(B/MaxB))*MaxA.

In AO, AE sprites, which have the L-B O are rendered pixel-by-pixel with such a shader, when the level loads.

[gishygleb]

WHOOPS, MULTIPOST.


Another way to render the L-B O is to set the transparency shader to "absolute additive".

But really, it is better to edit the L-B O mages in the Photoshop using the Background Eraser tool (beyond the label of a mere eraser tool). I did that to get some of sprites to work in my OddRun.

[RoryF]

There's not really any issues regarding alpha, I figured out that additive was what the explosions needed after playing around with the SpriteBatch modes. I have to add something in the object stuff to tell the engine if it's rendered additive or not, but you are correct.

The problem with using Photoshop is that I'm not really sure how legal it is to make the engine and provide the sprites on top of that to play with it, the best I could do was allow you to do that, but for most people it might be that they just want to copy the Decoder's output straight into it.

[gishygleb]

Maybe, some option-field, where the user chooses the type of transparency (additive/subtractive/straight (here colour selection)).

So the aim of this program is to import your own textures? Or what?


Java is just perfect (except for the RAM usage).

[RoryF]

It's simply a remake of the A.L.I.V.E engine, but I'm aiming to avoid putting Oddworld specific stuff in the actual code; Sligs and other objects double as actual dll files you can use in your level, as well as being examples of how to make the objects.

Things like chanting and bird portals will be handled by broadcasting to an AI handler in the objects (if there is one), possession will simply be the object telling the game to switch the ID of what object is handling input. Bird portals probably by getting the nearest bird portal object, and checking if it's reachable and stuff. Remember: these are specific to the object's interface; so each object needs a nice name in order for the engine to know what you're looking for (similar to getElementsByClassName in javascript).

[gishygleb]

Oh-woah? Try your best, good luck. Share your source code with us from time to time, please.


Seems like I am the only one person in the whole world, who does not give his variables understandable names and thinks of, it as of the better way.

[RoryF]

Well, I've got to make sure that the stuff that's in the code is as understandable as possible. The way I do it is to simply name anything the best I can, and if I can't give it a good name (eg one's that would be annoying to type out), I'll stick a comment above it to explain it. Especially in long winded parts I put a lot of comments in essentially step by step, if it needs it of course.

Visual Studio is pretty good in that it takes two seconds to add the descriptions of methods and things with ///. I know in Java the equivalent is making a JavaDoc and referencing it but that takes time (or at least I haven't used Java enough to really know).

[gishygleb]

LibGDXed Java just uses // for comments. Or /* */.

[RoryF]

I know how to make comments; I'm referring to the tooltip-ish part that pops up.

Like this.

Edit:
In terms on progress; I'm not working on the engine itself at the minute, following Paul's recommendation to do the tools first.

Currently I'm setting up how the LVLX format should look (for now), it's almost done; but I had a lot of stuff to do yesterday and didn't get time to finish.

[gishygleb]

Ah, got it.

Accomplishing this shall make you a hero of OWF.

[RoryF]

If you say so...

By the way, I will upload the LVLX format document and an example LVLX (in text) when it's done. If you really want, like ANIMDEFs and TEXDEFs it is possible to edit by hand, but as Paul said; probably should use a tool. But it doesn't stop anyone from making a tool better than mine in future if they really wanted to.

[gishygleb]

There are sloth and ignorance. Certainly, no one would even try (except for Paul, maybe) to transcend your level.

[RoryF]

I don't see what you mean; the whole point is for this to be open - so it wouldn't make sense to make it impossible for anyone to understand the formats, hence making it plain text and documenting how it is put together. My tools will not be the best there is; and for that reason if someone wants to make an even better tool then they can do it easier and if it ends up truely being better then everyone benefits.

[gishygleb]

I mean, people will not put an effort to create their own engines.

Oh, please, a bit more commas, text is too sooooolllliiiiddd...

[RoryF]

I'm sure there probably has been in the past, possibly not the way I plan on it, but most ran out of motivation or just disappeared. Joshkrz a long while ago was making something in flash, it looked impressive but it just sort of vanished. Obviously, I'm going to try and keep this going, I have way too much free time to be doing nothing after all.

By the way, I'm also making the LVLBUILD part of LVLX, however, this means I need to plan out the object structure; which shouldn't be too hard, in fact I'd say I'm mostly done.

I'll upload the object stuff first to see if people are ok with its design; it DOES NOT have the methods inside yet; it is way too early for that. I have ideas, but it's best to get a full understanding of all possible features first before getting involved with that part.