Major concepts and issues

[1337]

This thread is supposed to be a discussion about the major concepts and "think-abouts" in orxonox. And of course if that involves larger problems, these are also to be addressed here.

(reto)
- Steering wit key-bindings, etc.
(x3n working on it after the exams)

(reto)
- Sever/Client concept in cooperation with graphics. Shall we create a graphics interface for instance? Or only a playableServer?

(nico)
- physics: more what kind, and based of which lib.

(patrick)
- Multithreading: which parts are parallelizeable? I have some good ideas about multithreading, but haven't got the time to write/draw them down. If you are interested to know them, I'm working at the TIK institute until the end of February. You are welcome to come by (perhaps all that are interested together). Hmm... perhaps you will want to write an email to me about it before to make sure I'm not working at home.

(patrick)
- Mission Goals: Very, very important: How do you define mission goals for players. Are there different types of mission goals? How do you define if a mission is accomplished? how do you define a mission goal? This is very essential as it will determine the playability of Orxonox. If you create a good solution for this you will have a game and not a framework anymore.

Feel free to post. If you don't think a point is not worth a major issue, we can easily remove it, since I wouldn't want this thread to become too large (not concerning posts, but issues).

[nicolasc]

- Steering wit key-bindings, etc.
(x3n working on it after the exams)

With some thoughts about what input control. Keyboard only, mouse, joystick or gamepad? And if multiple methods are used, they need to be balanced.

- physics: More what kind, and based of which lib.

cheers
nico

[patrick]

- physics: more what kind, and based of which lib.

I talked to Chrigi about that and we both agree: Using ODE is a very good possibility. It is well documented, as you can see here

Adding Issues:
- Multithreading: which parts are parallelizeable? I have some good ideas about multithreading, but haven't got the time to write/draw them down. If you are interested to know them, I'm working at the TIK institute until the end of February. You are welcome to come by (perhaps all that are interested together). Hmm... perhaps you will want to write an email to me about it before to make sure I'm not working at home.

- Mission Goals: Very, very important: How do you define mission goals for players. Are there different types of mission goals? How do you define if a mission is accomplished? how do you define a mission goal? This is very essential as it will determine the playability of Orxonox. If you create a good solution for this you will have a game and not a framework anymore.

[1337]

I hope you don't mind if I add all the input into the first post in order to compile a list.

[nicolasc]

I talked to Chrigi about that and we both agree: Using ODE is a very good possibility. It is well documented, as you can see here

Sure.... give me a wrapper for ogre and we'll use it. But from what happened last term, I am not sure, if ODE is really a good idea.

I have several discussion with marc about what physics engine to use, and especially why.

• ODE is great for simulations, but somewhat old/outdated, and lacks some features a modern physics engine should have - i.e sleep states.
• Bullet, though fine, is more core colliding blocks, than for that simple physic we are looking for.
• Newton, though a binary lib - 32bit only - is fast and simple enough. I am not sure about Ogre-integration..

With the rest I can agree.
cheers
nico

[beni]

Well, it's a bit stupid to just say, that there is no open source physics library good enough. ODE is used that much for a reason.

What we also need is scripting: In the old Orxonox we used lua. Ogre seems to have some lua support, but I haven't checked it out yet. Scripting is important to create and react to events inside a level. Of course event can also be handled from the game, but were used to outsource stuff into text files right?

[x3n]

Yes, lua support shouldn't be a big problem with the ideas from orxonox v1. I'm not sure if we need the ogre plugin... we don't have to script graphics.

[BadElvis]

Concerning the steering, I think the best steering for a spaceship is the following:
- The thrust is controlled by the keyboard (thrust+/thrust-)
- The heading is controlled with the mouse: in the center there is a crosshair (where the shots will hit). Around the crosshair, there is a (small?) tolerance circle. If the mouse pointer is inside this circle, the ship's heading doesn't change. if the mouse pointer is moved over the border of the circle, the ship changes its heading in the direction of the mouse pointer. To make a looping, one would move the mouse up or down. to make a turn, one would move the mouse left or right. moving the mouse pointer further away from the center, makes the ship turn more quickly.
- Iz might also be important to have two additional keys to roll the ship (turn around the axis pointing in the direction of travel).

This kind of steering is easy to learn and powerful in combat/dogfight situations.

I'm writing this because I found the steering at the last orxonox convention very strange/didn't understand it at all. There were no indications showing me what I am doing/where I'm going.

Feel free to delete this post if it doesn't fit in here or move it to the steering thread by marc biber.

[1337]

Hmm, I guess your idea is probably a good idea since our steering is implemented exactly (except for the little circle, which is yet to come) like you proposed.

The actual problem is the implementation. E.g. where to write things down. It's most certainly gonna be in the Ship class. Another problem are the key bindings (so you can change with what key you want to thrust, etc.). That has to be implemented as well.
And of course there is the huge client/server issue: How much does the server control (down to which level, e.g. just mouse movement, nothing at all..) over the client? The more it does, the laggier the steering gets, the easier it is to code.
And I'm sure that's not everything at all...

But thanks for the input, we always appreciate it.

[x3n]

I'm writing this because I found the steering at the last orxonox convention very strange/didn't understand it at all. There were no indications showing me what I am doing/where I'm going.

The implementation is almost exactly like you described it, except for the circle (I'm not sure if the circle is good - if you try to adjust your orientation just a little bit, the ship won't react...).
At the presentation you were probably confused because nico set the option 'invert y-axis' to true.

[1337]

(I'm not sure if the circle is good - if you try to adjust your orientation just a little bit, the ship won't react...).

Hmm, personally I think it to be a good idea under one condition: The player has to actually see the mouse cursor and the little circle. Then it makes perfect sense.

[x3n]

But small left-right adjustments result in big mouse gestures...
I'll have a look on the steering in aquanox, freelancer and darkstar one before we implement our own steering to get some inspiration

[patrick]

Here is some more inspiration: Star Wars Rouge Squadron:
on youtube. It's similar to benis "circle in the circle steering".

In RS the ship will always automatically turn back to horizontal position.

[nicolasc]

Good point... make a lot sens on the surface, but in space. OTOH if might be easier for most people if the game is more 2D, than 3D. In most shooter - Freelancer included - it is rather rare that the enemy appeared directly above or below you. What I meant to say is, that we should include that in our steering protocol.

I also like the camera behavior in RS - FL does it similar, but shooting direction and light direction were not necessarily coupled...

Another question arises here: Do we want planetary flight, or does the simulation part take place in space?

[beni]

Planetary fights would cause some problems I believe, but I wouldn't say it's impossible.

The question is, how we want to generate a planet surface. A height map would be the best solution. Ogre allows us to change the SceneManager ingame to change to the terrain. Via paging or other algorithms we could load and unload quite a lot of information while flying through the level.
Also possible is a self generating level, where we could use a special low resolution height map to tell the random generator how it should behave (water, mountains, forest, desert and so on). Again this would cost some time to establish this. Also the self generating terrain wouldn't save already visited areas and one would have to add special places where certain things should be.

So with the present state we should in my opinion completely exclude planetary fight scenes.