Vertical Scroller Mode

Introduce your project and write about your work.

Moderator: PPS-Leaders

User avatar
bensch
Admiral Alexi Sarkhov
Posts: 101
Joined: Tue Oct 03, 2006 2:28 pm
Contact:

Vertical Scroller Mode

Post by bensch » Wed Dec 06, 2006 7:33 am

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

User avatar
Michel
Human Space Navy Sergeant
Posts: 13
Joined: Tue Nov 21, 2006 5:14 pm

Post by Michel » Wed Dec 06, 2006 6:48 pm

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 :wink:.
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 :cry:.
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]
Last edited by Michel on Fri Dec 08, 2006 5:38 pm, edited 1 time in total.

User avatar
bensch
Admiral Alexi Sarkhov
Posts: 101
Joined: Tue Oct 03, 2006 2:28 pm
Contact:

Post by bensch » Wed Dec 06, 2006 11:21 pm

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.

User avatar
bensch
Admiral Alexi Sarkhov
Posts: 101
Joined: Tue Oct 03, 2006 2:28 pm
Contact:

Post by bensch » Wed Dec 06, 2006 11:28 pm

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.

User avatar
Michel
Human Space Navy Sergeant
Posts: 13
Joined: Tue Nov 21, 2006 5:14 pm

Post by Michel » Thu Dec 07, 2006 12:23 pm

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.

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

Post by patrick » Thu Dec 07, 2006 1:34 pm

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

User avatar
Michel
Human Space Navy Sergeant
Posts: 13
Joined: Tue Nov 21, 2006 5:14 pm

Post by Michel » Fri Dec 08, 2006 5:19 pm

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

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

Post by patrick » Sun Dec 10, 2006 6:40 pm

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!

User avatar
Michel
Human Space Navy Sergeant
Posts: 13
Joined: Tue Nov 21, 2006 5:14 pm

Post by Michel » Tue Dec 12, 2006 7:18 pm

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 :roll: ..... 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
Human Space Navy Major
Posts: 41
Joined: Tue Oct 24, 2006 7:45 pm
Contact:

Post by Marc » Tue Dec 12, 2006 9:16 pm

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

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

Post by beni » Sat Dec 16, 2006 12:47 pm

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

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

Post by patrick » Sat Dec 16, 2006 3:39 pm

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!

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

Post by beni » Sat Dec 16, 2006 4:31 pm

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

User avatar
Michel
Human Space Navy Sergeant
Posts: 13
Joined: Tue Nov 21, 2006 5:14 pm

Post by Michel » Tue Jan 30, 2007 9:32 pm

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

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

Post by beni » Thu Feb 01, 2007 1:22 pm

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