Vertical Scroller Mode

[bensch]

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.

[Michel]

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:

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

Things I still have to work on:

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

The idea would be to just tell the track manager some points inside the level, where the camera path has to pass. the track manager then calculates a spline through these points and the spaceship class takes this spline and moves the camera along it. The problem I see on this: For the AI it could get quite hard. The enemies shouldn't attack the player from a point where he can't shoot at them himself, right?
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]

[bensch]

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.

[bensch]

Almost forgot, to point two:

The changing of the path-node can be implemented using a script, and with the help of a script, and simple nodes (instead of spline-connections) branches can easily be realized.

[Michel]

thanks, your idea about hotpoints sounds cool and quite easy to implement. i'm will think about how i'm gonna implement that.

i will also post some screens here to illustrate what 's the problem with the perspective i mentioned above.

[patrick]

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

[Michel]

look at my poll in the gameplay- board for the issue mentioned above:
viewtopic.php?p=377#377

[patrick]

hi michel

I like the rolling of the spacecraft very much. It's far better than when we started. Congratulations!

I think you could now summarize the votes on your poll (not only the votes but also the inputs, there really are very good ideas floating around) and start implementing them.

Keep it up!

[Michel]

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.

[Marc]

If you checkout the HUD class you will see that there is the needed functionality.
The HUD class shows as well a nice way of taking care that it looks the same on different resolutions (more or less the same, as resolutions that are too different always will look strange).

[beni]

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.

[patrick]

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:

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

It should be possible to create multiple Tracks (eg. for cameras, mission track, enemy tracks, etc) so don't use the singleton instance stuff.

good luck!

[beni]

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:

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

It should be possible to create multiple Tracks (eg. for cameras, mission track, enemy tracks, etc) so don't use the singleton instance stuff.

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?

[Michel]

Questions?
Look at my freshly updated wiki. My work is now more or less documented there.
Enjoy

[beni]

I like it. If a have the time I will see through your code 'cause I'm intrested in the ways you achieved your goals.