Vertical Scroller Mode
Moderator: PPS-Leaders
Vertical Scroller Mode
I would be delighted to read about the new implementation of the vertical scroller.
Since it was the game style Orxonox was founded on, I !want! to play it as soon as possible.
Since it was the game style Orxonox was founded on, I !want! to play it as soon as possible.
Sry @ all that I didn't post here already, I was just thinking that it's not really worth it yet.
But now I can say that I at least got something.
Link to my Wiki Page:
https://dev.orxonox.net/wiki/VerticalScroller
Here are the goals I already reached until now:
So the AI would have to handle the constant change of level-boundaries. Idea: I could let the whole WORLD move along the spline instead. So the center of the screen of is always 0,0,0. Then the enemies have a constant field of absolute coordinates, where they are allowed to attack the player.
By the way it was Marc who gave me that idea. What do u think?[/url]
But now I can say that I at least got something.
Link to my Wiki Page:
https://dev.orxonox.net/wiki/VerticalScroller
Here are the goals I already reached until now:
- the playmode "horizontal", which means: moving in x-z- plane, y const is implemented! this means the movements work and are more or less balanced so that it is playable. on a left/right- translation the ship also rolls until a certain degree.
{ problems:
through the camera-perspective, the ship looks a bit rolled-over at the
left/right- borders of the VOW. patrick meant, that a more narrow actionzone would solve the problem. i'm agreeing to that, which means that i have to change my mind about the look-alike of the interface. f.e.: on one third of the screen on the left side, the interface is being placed, the rest of the screen is used for the action. this also means that i cant implement the interface like in patrick's idea of the hud, i dont even think that a transparent interface would work well. the other turndown of this: i would have to implent the interface by scratch for every playmode we want to implement, f.e. if you want to have a vertical-playmode what do u guys think about this issue?
} - the playmode can be chosen in the xml- levelscript. Well it's not very useful yet, because there is just one playmode, but still .
- implementation of the interface.
- other playmodes, if whished.
- maybe the implentation of a level track. If I'll still have enough time for this, I will consider it .. if not: then not .
So the AI would have to handle the constant change of level-boundaries. Idea: I could let the whole WORLD move along the spline instead. So the center of the screen of is always 0,0,0. Then the enemies have a constant field of absolute coordinates, where they are allowed to attack the player.
By the way it was Marc who gave me that idea. What do u think?[/url]
Last edited by Michel on Fri Dec 08, 2006 5:38 pm, edited 1 time in total.
Thanks for the post, it sounds good, and also matches the ideas, we had earlier on this topic (but more worked out ).
About the track:
1. Is it one single track, or is it possible to have branches??
2. How do you define Changing points within the level?
My suggestion:
Forget about a spline track for now, but implement Hot-Points, where the level can be resumed (in the future if loading/saving is implemented), and where the state can change (state == camera perspective for example)
Each hot-point has a time and a position within the level, and if there is time, these hot-points can also be connected by splines or nurbs.
About a track: It might also be possible to iterate from one point to the other using a node, that has a speed and a position, if this node gets in a certain range of the next Hot-Point, it steers for the next one.
Compared to the splines this implementation would not need an Absolute function, but iterate on the last time step.
The Problem would be, that different processor-speeds will have slightly different curves.
Hope this helps.
About the track:
1. Is it one single track, or is it possible to have branches??
2. How do you define Changing points within the level?
My suggestion:
Forget about a spline track for now, but implement Hot-Points, where the level can be resumed (in the future if loading/saving is implemented), and where the state can change (state == camera perspective for example)
Each hot-point has a time and a position within the level, and if there is time, these hot-points can also be connected by splines or nurbs.
About a track: It might also be possible to iterate from one point to the other using a node, that has a speed and a position, if this node gets in a certain range of the next Hot-Point, it steers for the next one.
Compared to the splines this implementation would not need an Absolute function, but iterate on the last time step.
The Problem would be, that different processor-speeds will have slightly different curves.
Hope this helps.
I think that you are on a good way. The most important goal at the moment is to implmenent a nice playable control. The whole project depends on this supproject. So first of all, we should focus on this.
The perspective problem actually not realy is a problem. It's just reality. Of course its different from the other vertical scroller games, because all other vertical scrollers use 2D-pictures instead of realy 3D models. Therefore you always got them from upside, which is not the case in Orxonox.
I guess we will need the player to accept this "reality" or we will have to tighten the field of view. Lets make a vote out of this in another thread, would you do this please Michel?
Thx, and keep it up
The perspective problem actually not realy is a problem. It's just reality. Of course its different from the other vertical scroller games, because all other vertical scrollers use 2D-pictures instead of realy 3D models. Therefore you always got them from upside, which is not the case in Orxonox.
I guess we will need the player to accept this "reality" or we will have to tighten the field of view. Lets make a vote out of this in another thread, would you do this please Michel?
Thx, and keep it up
look at my poll in the gameplay- board for the issue mentioned above:
viewtopic.php?p=377#377
viewtopic.php?p=377#377
i implemented a normalised velocity calculation today and also included the engine- output value, brought from the chactersystem-group, into the calculations. (the travelspeed therefore can't be set externally anymore and it has to be changed through the reactor-output and engine- values)
the movement- routines should now more or less stay how they are, except for maybe some little changes in the constants for balancing reasons.
now i worked myself into the hud and glgui- widget classes. do i see this right and the glgui- class hass been written by the orxonox team? i ask because when i enter 'glguiwidget' into google it just points to the orxonox page. if so: quite impressive work, guys! i'm just a bit scared now that i havent seen any functions to set absolute or even relative coordinates of the widget. all i've seen is that the class calculates the position of the widget internally, depending from the resolution and the order, the widgets have been allocated. what i didn't see is any way to influence the positioning. is it there and i'm just blind? if not it's going to be alot of work to implement an interface like we discussed in the poll- thread (interface b) v2) ... i guess i would have to either tweak this gui- class or else implement something from scratch into the hud- class. target would be to have a positioning system similar to css -> relative positioning through percentage- values for size and position plus 'float'- settings and even something like 'divs'. hmm... maybe i even could render a css- layout over it lol ..... heck i admit i don't really see where this all is going to lead at the mom. i guess i'm going to talk to the staff about this tomorrow. but i REALLY would be glad for any hints/ suggestions here.
the movement- routines should now more or less stay how they are, except for maybe some little changes in the constants for balancing reasons.
now i worked myself into the hud and glgui- widget classes. do i see this right and the glgui- class hass been written by the orxonox team? i ask because when i enter 'glguiwidget' into google it just points to the orxonox page. if so: quite impressive work, guys! i'm just a bit scared now that i havent seen any functions to set absolute or even relative coordinates of the widget. all i've seen is that the class calculates the position of the widget internally, depending from the resolution and the order, the widgets have been allocated. what i didn't see is any way to influence the positioning. is it there and i'm just blind? if not it's going to be alot of work to implement an interface like we discussed in the poll- thread (interface b) v2) ... i guess i would have to either tweak this gui- class or else implement something from scratch into the hud- class. target would be to have a positioning system similar to css -> relative positioning through percentage- values for size and position plus 'float'- settings and even something like 'divs'. hmm... maybe i even could render a css- layout over it lol ..... heck i admit i don't really see where this all is going to lead at the mom. i guess i'm going to talk to the staff about this tomorrow. but i REALLY would be glad for any hints/ suggestions here.
We talked about using the track. I just checked out the track's classes and it is quite a mess. I didn't fully understood every single piece of it yet and the whole thing could be implemented a lot better I think, but I guess we could use it. I will finish my review of the track today and then see how we can import it into your project.
I'm afraid it will be more of a hack, because reengineering the whole track needs longer than just a few days.
I'm afraid it will be more of a hack, because reengineering the whole track needs longer than just a few days.
"I'm Commander Shepard and this is my favorite forum on the internet."
beni: don't think too much about the look of the track module, as you told, it just needs to work at the moment.
At a later point in time, we will be able to reimplement it correctly and use simpler splines instead of the current implementation.
The goal would be to implement a class called Track with following abilities:
good luck!
At a later point in time, we will be able to reimplement it correctly and use simpler splines instead of the current implementation.
The goal would be to implement a class called Track with following abilities:
- addPoints(Vector)
- create the track
- set the speed of the TrackNode
- get the position/orientation on the track after a certain time has elapsed (getPosition(float dt), getDirection(float dt))
good luck!
Oh.. now I see. I already checked out those functions. Are we going to use them like them are and just use a new Track-class with those functions?patrick wrote:beni: don't think too much about the look of the track module, as you told, it just needs to work at the moment.
At a later point in time, we will be able to reimplement it correctly and use simpler splines instead of the current implementation.
The goal would be to implement a class called Track with following abilities:It should be possible to create multiple Tracks (eg. for cameras, mission track, enemy tracks, etc) so don't use the singleton instance stuff.
- addPoints(Vector)
- create the track
- set the speed of the TrackNode
- get the position/orientation on the track after a certain time has elapsed (getPosition(float dt), getDirection(float dt))
good luck!
"I'm Commander Shepard and this is my favorite forum on the internet."
Who is online
Users browsing this forum: No registered users and 88 guests