1.1 Roadmap

[treellama]

We're still busily working on a bunch of extra stuff we feel should go in or along with the 1.0 release.

But, to reduce confusion, I thought I'd list some of the things I'd like to work on for 1.1:

Likely:Support for the original Marathon file formats (this is already getting started in SVN)Implement faders as shaders in OpenGL (Shader)Try to get more performance out of OpenGL (Shader) bloom on CPU-limited maps by combining normal and bloom rendering passesMinor additions to the Lua API (suggestions welcome, keyword minor)Bug fixesLess likely:Refactor weapons-in-hand rendering to support shaders and bloomSounds patches (requires modifications to Aleph One, ShapeFusion, and Atque)Metaserver dialog improvements (this is on my list every release and never gets done)Unlikely:Split physics and rendering into separate threads for 30 fps Citadel on dual core machinesColored lightingThis is just me. Other developers might have other plans.

I would like 1.1 to be finished some time in 2012. Just like I'd still like 1.0 to be finished some time in 2011!

[xdedge]

Support for the original Marathon file formats (this is already getting started in SVN)

This means well be able to play marathon scenarios( like trojan ), without converting them?

[treellama]

This means well be able to play marathon scenarios( like trojan ), without converting them?

Well, some conversion is necessary because they're .sit or .hqx. As well, many use an installer that only runs in classic Mac OS, because they weren't allowed to distribute game files at that time.

Lastly, if any engine modifications were done, MML would have to be written for those.

So, this would only get you a step closer.

[Ammon]

If Aleph One did support M1 maps, would it be possible to open them in VML (or Weland, mind you) and resave them as .sceAs?

[treellama]

If Aleph One did support M1 maps, would it be possible to open them in VML (or Weland, mind you) and resave them as .sceAs?

That's an extra bit of work. We'll see!

[Ares Ex Machina]

I thought I'd list some of the things I'd like to work on for 1.1:

Looking forward to it!

[Dugit]

[*]Colored lighting

Do you mean like the effect they put in Hex Level 73 (Rubicon)? That would look just awesome if it was an engine element rather than a texture/CLUT trick.

If Aleph One did support M1 maps, would it be possible to open them in VML (or Weland, mind you) and resave them as .sceAs?

That would be neat.

EDIT: Just a small question: what is the limit for viewing distance in Aleph One, in WU? Is there still one?

[treellama]

EDIT: Just a small question: what is the limit for viewing distance in Aleph One, in WU? Is there still one?

The square root of 8192

[Dugit]

The square root of 8192

Thanks.

Is it even possible to have a distance of 90.5 WU in a map, out of interest? Or is the mapping area given in Weland set in stone?

[treellama]

The area is the extent of the map format. 64x64 WU correspondingly gives you the maximum viewing distance

[RyokoTK]

Thanks.

Is it even possible to have a distance of 90.5 WU in a map, out of interest? Or is the mapping area given in Weland set in stone?

The diagonal of a 64-WU square is 90.5.

[Crater Creator]

...some of the things I'd like to work on for 1.1:

Unlikely:Colored lighting

Can you talk a little more about this one? If it were to happen, what kind of control would the mapper/scripter have? Would implementing colored lighting lay some of the groundwork for implementing light sources? Or are the two pretty much unrelated? I'm not very familiar with the code, but I feel like the experiments shown here still show untapped potential, even if originally intended as a joke.

[goran]

bridges and balconies plz

lol. You are pushing your luck here mate. Treellama is no known supporter of B&B.

Me, I hope Treellama has a kick ass year and eventually come to the unlikely list (colored lighting).

[ChristTrekker]

I'd like B&B, because it supports additional realism. The fact that we never see B&B in-game, when certainly we would if these scenarios were really happening, is odd.

But then, I'd also like an option for "realistic physics" that would eliminate mid-air course corrections while jumping. I'm not sure how well that would be received. Would certainly increase the difficulty in places. You could add a "jet pack" powerup to switch back to the original physics for a while!

And jumping, because I still can't grenade hop worth a darn! And if you're doing that, you might as well add crouching too, so you can use scenery as cover.

[Wrkncacnter]

These are all really great ideas. We should get nightly builds reinstated, so we can start testing this stuff ASAP.

[treellama]

I'd like B&B, because it supports additional realism. The fact that we never see B&B in-game, when certainly we would if these scenarios were really happening, is odd.

But then, I'd also like an option for "realistic physics" that would eliminate mid-air course corrections while jumping. I'm not sure how well that would be received. Would certainly increase the difficulty in places. You could add a "jet pack" powerup to switch back to the original physics for a while!

And jumping, because I still can't grenade hop worth a darn! And if you're doing that, you might as well add crouching too, so you can use scenery as cover.

Sounds like you're using the wrong engine!

[megabyte]

But then, I'd also like an option for "realistic physics" that would eliminate mid-air course corrections while jumping.

This could easily be done with lua. Check to see if you are falling and if so counteract the internal velocities by manipulating the external ones. Which wouldn't be the best solution in the world.
So this is where I ask Treellama if opening up the internal velocities so they can be modified via lua would be minor enough to make the list.

You could add a "jet pack" powerup to switch back to the original physics for a while!

This is basically binding player:accelarate() to an actionflag and maybe throw in fuel

And jumping, because I still can't grenade hop worth a darn!

Well...............

[ukimalefu]

I'd like B&B, because it supports additional realism. The fact that we never see B&B in-game, when certainly we would if these scenarios were really happening, is odd.

But then, I'd also like an option for "realistic physics" that would eliminate mid-air course corrections while jumping. I'm not sure how well that would be received. Would certainly increase the difficulty in places. You could add a "jet pack" powerup to switch back to the original physics for a while!

And jumping, because I still can't grenade hop worth a darn! And if you're doing that, you might as well add crouching too, so you can use scenery as cover.

Mid-air course corrections while jumping and grenade jumping are part of Marathon. You can't take away that!

[herecomethej2000]

I'd like B&B, because it supports additional realism. The fact that we never see B&B in-game, when certainly we would if these scenarios were really happening, is odd....

You clearly don't understand the purpose of this project. As Treellama said, If you want and engine that can do all that there are already plenty much better ones to choose from.

QUOTE(Megabyte)Well...............[/quote]

Frankly I think the mic is a lot cooler, thanks.

[treellama]

So this is where I ask Treellama if opening up the internal velocities so they can be modified via lua would be minor enough to make the list.

The reason you can't access the internal variables is that doing so would conflict with latency hiding. There are complicated strategies to get around that, some of which include just disabling latency hiding when Lua scripts need to access internal variables, and making Lua scripts do their own latency hiding, but I'm convinced that the end experience would be sub-par for both scripters and players.

It's certainly not a minor request

[Not Invented Here]

Wouldn't it be fun if we could have invisible bridges and balconies? Like, a way to trick the engine into making you walk on air. Nothing even needs to be said for actually defining geometry, since 3d scenery already can be used for that, but more of an on/off thing in Lua to make the player act like it's on solid ground even when it's not. Could even walk on water that way, or make weird light bridges that can suddenly shut off when you're walking on them, all kinds of fun stuff.

I know you can mess with the external acceleration to fix the player in the z axis, but then the player is basically just flying/floating/skating around, which doesn't do much good for bridge/balcony safety. I take bridge safety seriously in this respect, since I almost died when I was 9 because I went out onto a bridge that hadn't been de-iced, and almost fell into a ravine. It was not so much fun.

Also, an extensible object system would be nice, instead of having to swap everything around with MML. I know it's damn near impossible to run out of scenery, but if it were possible to script new scenery and plug it into the engine, or new items even? Script based extensibility in general would be nice for anything, like physics even!

[ChristTrekker]

Sounds like you're using the wrong engine!

I expected that response.

Mid-air course corrections while jumping and grenade jumping are part of Marathon. You can't take away that!

LOL. To me, playing Marathon isn't necessarily the gameplay. It's the atmosphere. I love the environment, the story, the mythos, the "look" and visual design. This is one reason I am so very pleased with the texture work that Goran is doing, because they stay true to the originals.

You clearly don't understand the purpose of this project. As Treellama said, If you want and engine that can do all that there are already plenty much better ones to choose from.

Actually I do, and I certainly respect those who feel that "Marathon" is defined by it's gameplay. But as I allude to above, I simply don't agree 100%. Things like bloom are really cool, visually, and I am not knocking the work that went into that at all, but I'd be just as happy keeping the old-school graphics and adding more capabilities instead.

What I'm saying is that I'm happy playing Marathon as it is, even without some of the features I think would be cool. Playing games built on other engines are fun, but they just aren't Marathon. Though someday I hope to give M:Resurrection a try, but that won't happen until UT is free.

[megabyte]

The reason you can't access the internal variables is that doing so would conflict with latency hiding. There are complicated strategies to get around that, some of which include just disabling latency hiding when Lua scripts need to access internal variables, and making Lua scripts do their own latency hiding, but I'm convinced that the end experience would be sub-par for both scripters and players.

It's certainly not a minor request

Ah well it was worth a try . How about being able to access movement controls like you already access weapon triggers, the action key, and microphone?

Maybe one of these days when work(Java Dev) and school calm down and I get more used to C++ I can help out with Aleph One's code and toy with making these changes myself.

[treellama]

Ah well it was worth a try . How about being able to access movement controls like you already access weapon triggers, the action key, and microphone?

Same deal. You'll notice everything that doesn't go through local prediction, like the triggers and overhead map, are already exposed; and everything that does get predicted isn't exposed.

[Crater Creator]

The reason you can't access the internal variables is that doing so would conflict with latency hiding. There are complicated strategies to get around that, some of which include just disabling latency hiding when Lua scripts need to access internal variables, and making Lua scripts do their own latency hiding, but I'm convinced that the end experience would be sub-par for both scripters and players.

It's certainly not a minor request

We currently have some lua functions, like .local_random(n), that aren't intended for use in multiplayer games. If internal velocity etc. is something that would be added if it weren't for the latency-related concerns, I think scripters would still appreciate having it in their toolbox, even if getting/setting .internal_velocity were invalid or ignored for netgames.