some crazy ideas

[Jonathan]

Lyx: Ah, OK. But I still don't see how it's significant enough, and what's wrong with a bit of risk?

[Lyx]

I'm interested in a speed cap, actually, but for different reasons. :)

Mmh? *curious*


About the head-to-head racing mentioned earlier..... i could think of three ways to get the intended effect without disrupting normal gameplay(i guess there are more ways to do it):
1) when one leaves a "wall-acceleration-zone", intruduce a short(maybe 0,3secs) phase of increased de-acceleration

2) add an additional "acceleration-zone" when driving very close behind another cycle and in the same direction (similiar to the "slipstream" in car-racing)... that way, both opponents "catapult" each other to higher speeds again and again.... might result in a similiar gameplay like the "close combat racing via boosters"-idea

3) add boosters ;-)

I guess all three can also be mixed with each other, if reasonable.

- Lyx

[SuPeRTaRD]

" juwb wrote:
9. Top-down (bird's eye) camera

The custom cam is close. "

therse already a top down camera, its called external or outside or soemthing ,..

speed limit? i doubt turbo servers would appreciate that

i dont think basic a-tron gameplay should chage, bikes should not have thickness.

atron reminds me alot of the lightcycles game in arcades, the tron portion of the tron movie arcade game..

except the blast holes were smaller

and brake was turbo

anywho,.. i REALLY REALLY REALLY like how lucifer set up his new server.
you cant u-turn or adjsut there but there is plenty of rubber.

it feels like a very old version, but in a good way.

i dont think shaped 4axis grids take away from the game at all, (unless the map just inherintly sux)

anything that makes the game more editable, or customizeable, etc.. will only add to the player fanbase & longevity of the game.. for me , maps has just opened endless possibilitys of playing with this badass game.

there, i think thats about it..

i think the feel of the orignal movie & arcade game & stuff, & the orignial armagetron, is important to keep in mind, as we improve the game.

& if you want original feel , check out lucifers new server "the crack pipe" god.. what a name..

& lucifer, when u are ready to tweak the roulette server let me know,.. i'd love to help give input

[philippeqc]

I know from tron 2.0 that they had floor spaces where if you drove over them they had an affect upon your cycle such as speed enhancement, but this rout is not really required.

on this discussion http://forums.armagetronad.net/viewtopi ... 3881#33881 I present such a mechanism. Its a dry reading. You might want to follow reading this document with the one attached at http://forums.armagetronad.net/viewtopi ... 3911#33911, but I dont guaranty it wont confuse you even more.

-ph

[Phytotron]

I just broke out a little GLTron, and should make a couple amendments. GLTron's cycles will actually fit through narrow passages—it's just really, really, really damn hard to get yourself lined up perfectly so as to get into one.

And yeah, the floor can have transparency down to a lower image as well. If you want to see something that will make you absolutely drool, dig the artpacks called "binary, "CyberLand," and "eCITY," especially the first one. The screenshots don't even begin to do them justice, though. http://www.gltron.org/artpacks.php

Incidentally, while messing around I tried to do some roulette. Crap it was hard, heh.

[Z-Man]

About GLTron cooperation: I was in closer contact with Andreas when this all started; the feeling back then was that while there would be things to be gained from a cooperation, it's also good to have two products in close competition (like KDE and Gnome). Maybe it's time to reestablish the contact; GLTron and AA have flourished in different areas. Andreas has polished the visuals and has scriptability (I guess that makes the artpacks so flexible), probably better configuration and UI. We have the network and its cans of worms. The most evil thing we could do here would be to incorporate GLTron's rendering code once our rendering code has been made more flexible

Things I liked and will pick up:
- The possibility of giving the cycle a width so it does not fit into tiny corridors anymore. You'd still be able to grind one wall closely.
- Different acceleration factors for your own, your teammates' and your enemies' walls.

I also like the slipstream idea; It's not really feasible technically however. The problem is the prediction; in a network game, if you and someone else race side by side on approximately the same height, you will see yourself as being ahead all of the time, and the amount of this extra acceleration you really get largely depends on what the other player has done that your client does not know yet. So even if we manage to make a prediction that works if the other player drives straight on, it will break down heavily if he doesn't and increase the feeling of lag.

The acceleration cap is already there; CYCLE_ACCEL_OFFSET servers precisely this purpose. Jonathan has found a way to turn around the acceleration curve: set CYCLE_ACCEL_OFFSET to a negative value smaller than -CYCLE_WALL_NEAR. Values between that and zero will have a nasty division by zero waiting for you, and diverging acceleration/braking around the critical value.

[SuPeRTaRD]

i hopes those will be toggleable server options..

if gameplay changes in a major way i think alot of the older grid players might dissapear

[Lucifer]

I don't know, man. I can't see cooperation hurting, and it would be nice to adapt a fancier rendering engine into armagetron, but my gut tells me we'd be better off engaging in a more competitive relationship than cooperative. (not that I care too much either way, I don't think either project would become stagnant because of it)

I was thinking something more along the lines of xine/mplayer, actually. "The other guys suck! Oh no, they've got something we don't, let's grab their code so we can have it too" And then you wind up with stuff that's not that different from one another....

Anyway, what does his rendering engine look like? Has anybody here actually cracked open gltron's code to see?

/me goes to download source tarball

[Lucifer]

Talking to myself...

It doesn't look like his rendering engine is all that complicated. There are a number of calls to scripts, though. His menu system is almost just like ours, except he uses lua to script it, where we have a set of templates and inheritance and stuff.

His rendering engine itself uses wavefront objects for the models, and he's got some code to load the models, of course. Then there's a series of functions that just use a few lists to render the objects.

So, we'd have to strip the rendering from game objects and rearrange game objects to a format we can adapt his code to use, maybe putting them in std lists or somesuch. I don't see how it can be more than 4-6 hours of work if someone just gets on it. It could be upwards of 20 hours or more, but gltron isn't a large codebase at all. Ballpark, it's probably 1/4 -> 1/3 the size of armagetron, and it's in C even!

Anyway, you could start by detaching his functions from looping through game objects, so each function works on one single object, then change our game objects' rendering methods to call his functions. Of course that doesn't take care of ordering everything properly, but it still doesn't look that hard. Worse case you put all your objects into a simple scene graph and write a wrapper function around his renderer that translates that scene graph into arguments that make sense in his renderer and just dump it there, call it after you've updated the game objects.

[Lucifer]

Alright, got gltron to compile and ran it finally.

Face it, guys, our rendering engine is better. His might be prettier in ways ours isn't, but it's the old form vs function argument. We have custom cameras, smartcam, several different camera views. We have maps (now).

The only strengths his rendering engine has over ours are in the special effects and the explosions, all of which feel closer to the movie than what we've got. Now, I wouldn't mind having explosions like his, but we have special effects that are just as cool and visually stunning if not more so. We've got mirrored objects! He's got halos around each cycle. He gets that by using fog. For performance, gltron fell down in a big way. With all the bells and whistles on, I only got 78 max fps out of gltron. With all the bells and whistles on in armagetron, I get the same. But one of those bells is resolution, I run armagetron at 1280x800 and get the same as gltron running at 1024x768.

So, I'm not seeing any direct benefit to switching to gltron's rendering engine. THere is a lot of indirect benefit we get by doing it, but that comes anyway with just about anything else we might do. By switching out to use his, we have to factor our own. IN order to do it the most painless way I can see, we'd have to create a function to order the calls and put all of our game objects in some central list or other (which already exists, iirc). Then we have to add in our custom camera views and make it work in an environment that gltron doesn't operate, which will probably amount to a pretty substantial rewrite of his rendering engine, and then we have to include our own bells and whistles as they stand. When it's all done, where are we going to be? Better or worse performance? Flip a coin. We will have a more robust renderer than we have, easier to maintain, separated from game logic, and all that stuff. Those are the benefits that make such an exercise worthwhile, but the final rendering probably isn't going to be that much better than what we have. Regular incremental development will get us there anyway, and it's very much arguable whose is better. Ours does things his doesn't do, his does things ours doesn't do. IMO, ours facilitates game play whereas his just looks good.

Other than that, there's really no room to cooperate. Our menus are more complex. Sure, his are scripted, but that's not saying a whole lot. Our game engine kicks his all over the grid, we can play his game on our grid, but he can't play any of the myriad possibilities we have available to us.

Maybe his sound engine will do us some good, but I'm not seeing it. It's just mikmod and/or sdl_mixer, and we already have sdl_mixer. We just need music, and I'm working on that already.

His is written in C, so he's not likely to benefit from any of our code. He'd have to rewrite in C++, or he'd have to rewrite all of our code to work for him in C, neither of which are pleasant options compared to just continuing incremental development on his game.

NOw, I will point out that his grid is more luminous than ours. It's like a bright square of death and dismemberment whereas ours is a bit darker. I would bet that's what gives people the gooeys when they see his more than anything else. To use his explosions would likely wind up a huge fps hit for us. IN GLtron, no problem, in single player mode the game stops there anyway. But what happens when you have 4 explosions going at once? Otherwise his artwork is really nice, his default artwork certainly gives a better impression than our default artwork, but that's really a matter of taste. I like ours just fine, and I don't play with a moviepack.

As for his artpacks, I didn't look into them. GLtron does support multiple artpacks which you can pick from a menu and we don't. But I'm not willing to concede that his artpacks are fundamentally better than our moviepacks, I've seen some really nice moviepacks that had all the luminosity and then some and were really wonderful packs.

So, like I say, the only real benefits we get have to do with the quality of our own code after doing the job, and we get those benefits anyway through regular incremental improvement. I do still think it would be a fairly quick and painless job to make the switch, and I think that making the switch to his renderer gives the person who's doing it a solid path to follow, regular progress measurements along the way, and what looks like a good design to aim for, saving him from having to generate all of that stuff on his own. Otherwise it appears very much that we're miles ahead of him in pretty much everything else and the two projects are far more divergent than they are convergent.

(no adversity meant, of course, just a comparison)

[SuPeRTaRD]

.ase is more crossplatform than .lwo

the trails in atron could be additive transparency, or the engine could support it, it would be pretty.. another thing atron needs, proper vertex shading on the bike models.

IMO

also with vertex shading U could make a cool glow around the bike, but you'd have to have the floor grid segmented into many polygons to do it
(and that would be bad)

if you had additive transparency, u could make bikes & etc. that look like they are flourescing (with some modeling/texturing tricks)

like neon lights

[Z-Man]

i hopes those will be toggleable server options..

Of course. This is even a technical necessity in most cases, you can't just change gameplay in a networked game because you feel so.

About advanced graphic effects: We'll probably have an XML material format where we export all relevant parameters passable to OpenGL; alpha blended objects however need special care as they need to be rendered last and back to front. Additive (or subtractive, the Lichs in Arx Fatalis had one representing their evil aura and it really gave me the creeps) glow, if it is to be culled as foggy glow really located at the glowing surface and not glow that is created by scattering in your eye, should be no problem.

About restricting movement to grid lines: It's true that it will benefit pathfinding, but only make things easier for the engine after a complete rewrite: away from the triangulation and towards just an array of used blocks. And it would require special code for all variations of axis configuration we support. That's probably not going to happen. It would be relatively easy to hack it in using the current engine, but I see no gameplay benefits that cannot be gained otherwise (by the finite cycle width mostly); and the restriction will add another element of lag even to local games; your cycle will not turn exactly where you tell it to, but a bit later. You can try to convince me of the contrary once the finite width is in

Lucifer: Wow, thanks for the analysis. Oh, GLTron has maps in beta stage, too, but I could not manage yet to install one of the betas (well, probably because I tried it from CVS).

[Lyx]

Now, I wouldn't mind having explosions like his, but we have special effects that are just as cool and visually stunning if not more so.

Thats true. However, for someone who has seen the movie, those explosions make a bigger difference in getting the tron-feeling visually, than "our" bells and whistles.

Our menus are more complex.

I think that our menues are bloated and suffering from growing-pains... but thats more a question of menu-structure. The current structure appears to be from a time when it okay for much less options - now the menus have become so large and with so many submenus, that a player who is used to "polished" games would get lost in the menu-maze. Since armagetron is planning for some major feature additions in the near future, a complete revamp of the menu-structure IMHO is not just a nice thing to have.... its almost a must if we want to add more options, unless we want navigating through the menues being a game of its own ;-)

NOw, I will point out that his grid is more luminous than ours. It's like a bright square of death and dismemberment whereas ours is a bit darker. I would bet that's what gives people the gooeys when they see his more than anything else.

I'd say the luminousity of his grid is more near the movie - but for my taste its a bit too bright. Something in-between our moviepack and gltron's grid would imho rule.

To use his explosions would likely wind up a huge fps hit for us. IN GLtron, no problem, in single player mode the game stops there anyway. But what happens when you have 4 explosions going at once?

Hmm, right - is there maybe a way to have something which looks similiar to his explosions, but more simplified to save resources?

Otherwise his artwork is really nice, his default artwork certainly gives a better impression than our default artwork, but that's really a matter of taste. I like ours just fine, and I don't play with a moviepack.

Hmm, something which i realized yesterday when thinking about what exactly it is what gives the movie-arenas their feeling...... i think it boils down to hugeness and speed at the same time. In the movie, the arena feels HUGE.... i think this is visually caused by the lightcycles appearing to run very fast over the gridlines - yet it appears to be nothing in scale compared to the rest of the scenery. So its about gridline-scale, walls and ceiling. The gridline scale is already okay in armagetron...... but our walls and ceiling.... hmm, how to describe it...... it just feels non-spectacular..... like racing in a living-room ;-) Some things which i guess may change this:

- higher rim-walls and larger textures, yet with with more details(the appearance of scale comes from having large shapes as well as tiny details in them.... similiar to how to make spaceships appear big)

- parallax-effects..... so layers.

- having an invisible *gap* between the upper end of the rim-walls and the ceiling, so that it does not look like a "room"

Both are resource-hogs and i someway doubt that its possible to add the missing feeling of vastness without getting a FPS-impact.


Concerning your finishing thoughts: to put it overly simple..... armagetron looks unpolished and "rough" on the surface, but scalable and advanced under the hood...... GLTron looks polished and "professional" on the surface, but limited and problematic under the hood. Keep in mind that what the players see, is only the surface. What the players might see in the future depends on the "internals".

[Lyx]

the restriction will add another element of lag even to local games; your cycle will not turn exactly where you tell it to, but a bit later.

You've got a point there. But keep in mind that this "lag" could be lowered by aprox 25% if one makes it like this:

Code: Select all

-- Tile2
|
|
|
+- 50%
|
|_ 25%: after this point, the cycle will turn at tile2
|       before this point, the cycle will "jump back" and turn at tile1
|
-- Tile1

Asuming that the size of a tile would be the same as the length of a cycle, the maximum possible lag would be 75% the size of a cycle. But a perceived lag would be there, right. The difficulty of implementation of which you speak is of course a good reason against this approach. However, i suppose that the further armagetron progresses, the more difficult the rewrite of the affected code would be. So, before dropping this feature-idea, it would make sense to make sure that we will not need it in the future.

[iceman]

I like the option of grid locking cycles, sounds cool to me