Major concepts and issues

Introduce your project and write about your work.

Moderator: PPS-Leaders

User avatar
1337
Baron Vladimir Harkonnen
Posts: 521
Joined: Wed Oct 10, 2007 7:59 am

Major concepts and issues

Post by 1337 » Thu Jan 03, 2008 1:38 pm

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).
Last edited by 1337 on Fri Jan 04, 2008 2:45 pm, edited 2 times in total.
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.

nicolasc
Baron Vladimir Harkonnen
Posts: 258
Joined: Wed Nov 01, 2006 7:58 pm
Location: your mind
Contact:

Post by nicolasc » Thu Jan 03, 2008 3:15 pm

- 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
BOFH Excuse #212: Of course is doesn't work. We've performed a software upgrade.

User avatar
patrick
Baron Vladimir Harkonnen
Posts: 350
Joined: Mon Oct 02, 2006 6:03 pm
Location: Bern

Post by patrick » Fri Jan 04, 2008 1:58 pm

- 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.

User avatar
1337
Baron Vladimir Harkonnen
Posts: 521
Joined: Wed Oct 10, 2007 7:59 am

Post by 1337 » Fri Jan 04, 2008 2:48 pm

I hope you don't mind if I add all the input into the first post in order to compile a list.
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.

nicolasc
Baron Vladimir Harkonnen
Posts: 258
Joined: Wed Nov 01, 2006 7:58 pm
Location: your mind
Contact:

Post by nicolasc » Fri Jan 04, 2008 3:22 pm

patrick wrote: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
BOFH Excuse #212: Of course is doesn't work. We've performed a software upgrade.

User avatar
beni
Baron Vladimir Harkonnen
Posts: 949
Joined: Tue Oct 03, 2006 9:15 am
Location: Zurich
Contact:

Post by beni » Mon Jan 07, 2008 12:48 pm

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? :)
"I'm Commander Shepard and this is my favorite forum on the internet."

User avatar
x3n
Baron Vladimir Harkonnen
Posts: 810
Joined: Mon Oct 30, 2006 5:40 pm
Contact:

Post by x3n » Mon Jan 07, 2008 1:49 pm

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.

User avatar
BadElvis
Human Space Navy Lord Commander
Posts: 83
Joined: Wed Nov 14, 2007 1:07 pm
Contact:

Post by BadElvis » Mon Jan 07, 2008 2:02 pm

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.

User avatar
1337
Baron Vladimir Harkonnen
Posts: 521
Joined: Wed Oct 10, 2007 7:59 am

Post by 1337 » Mon Jan 07, 2008 2:14 pm

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.
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.

User avatar
x3n
Baron Vladimir Harkonnen
Posts: 810
Joined: Mon Oct 30, 2006 5:40 pm
Contact:

Post by x3n » Mon Jan 07, 2008 2:19 pm

BadElvis wrote: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.

User avatar
1337
Baron Vladimir Harkonnen
Posts: 521
Joined: Wed Oct 10, 2007 7:59 am

Post by 1337 » Mon Jan 07, 2008 2:23 pm

x3n wrote: (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.
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.

User avatar
x3n
Baron Vladimir Harkonnen
Posts: 810
Joined: Mon Oct 30, 2006 5:40 pm
Contact:

Post by x3n » Mon Jan 07, 2008 2:29 pm

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 ;)

User avatar
patrick
Baron Vladimir Harkonnen
Posts: 350
Joined: Mon Oct 02, 2006 6:03 pm
Location: Bern

Post by patrick » Tue Jan 08, 2008 11:19 am

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
Baron Vladimir Harkonnen
Posts: 258
Joined: Wed Nov 01, 2006 7:58 pm
Location: your mind
Contact:

Post by nicolasc » Tue Jan 08, 2008 12:28 pm

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?
BOFH Excuse #212: Of course is doesn't work. We've performed a software upgrade.

User avatar
beni
Baron Vladimir Harkonnen
Posts: 949
Joined: Tue Oct 03, 2006 9:15 am
Location: Zurich
Contact:

Post by beni » Tue Jan 08, 2008 1:14 pm

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.
"I'm Commander Shepard and this is my favorite forum on the internet."

Post Reply

Who is online

Users browsing this forum: No registered users and 7 guests