Slashdot Mirror
Snowboarding Soul Ride Engine Goes GPL
TuringTest writes "LinuxGames reports this news update at the Soul Ride game site. Soul Ride is a snowboarding game with real character physics, and its engine is now released under GPL and available for download. You may see its beautiful screenshots until it gets /.ed. Note that only the engine is GPL'd, not the artwork and data. Can you imagine a GPL game with the Fellowship of the Ring crossing the Caradhras with these graphics?" I hope this release spawns a Linux-friendly snowboarding simulator -- Soul Ride is limited to Windows (9X, NT, 2000) for now.
The perl script seems to overworked/nonfunctional, but you can view a slideshow of screenshots at: http://www.soulride.com/products/screenshots/scree nshot01.html.
Point your WGET (to mirror) at
http://www.soulride.com/products/screenshots/imag
Soul Ride is limited to Windows (9X, NT, 2000) for now.
Gee, that's funny. I guess the Linux version that I've been playing for the last two months has just been a warped dream. Maybe not?
Cat, the other, tastier white meat.
OK, call me a Karma Whore, but here's a link to another page with screenshots from the game:
This announcement seems a little premature seeing as there haven't been any actual source files submitted to sourceforge yet. Screenshots are fine and good, but where's the source?
But adapting the terrain is childs play, basically a:
if frameratethreshold
render(smaller_mesh)
else
render(bigger_mesh)
end if
but there's no BSP-tree type ways to clip everything outside of the viewport. It processes every triangle in the 'world' for each frame, whether it's onscreen or not.
That is to say, it says:
draw(everything)
instead of
figure_out_whats_onscreen
draw(whats_onscreen)
My point is that this is just engine just draws a bunch of polygons. No cool special particle effects, no nifty vertex shaders or pixel shaders. No bumpmapping, environment mapping. No nothing. Just a bunch of triangles. As far as something to base a real game on, it's behind even the Quake engine.
Anyways, it's still good to see people willing to give up their source, even if it's value is nil.
I don't need no instructions to know how to rock!!!!
In any case, speaking as a developer of games, you can be sure I'll _never_ release anything into the GPL. Not so much because of politics but just because I can't stand the attitude of the GPL zealots who whine and moan about everything.
Which bit? The long preprocessing phase or the difficulty of collision queries?
The preprocessing can be done by the programmer and the processed data packaged with the game. Download the Chunked LOD demo and you'll see what I mean.
The collision thing is more of an issue, but would only mean storing a seperate hierachy of collision volumes. A lot of games engines do this anyway.
The problem with any LOD scheme is that you have to update your collision volumes whenever the shape of the mesh changes.
ROAM allows arbitrarily detailed terrain. It represents the terrain as a quadtree -- a space which is subdivided into four parts, each of which is subdivided into four parts, etc ad infinitum -- and by intelligently collapsing and expanding quadtree nodes based on the distance from the viewer to the terrain.
Actually your describing how quad trees work, which I Soul Rider is based on. But ROAM works by splitting triangles in halves recursively, and is quite different.
You are so clueless it is painful. You've actually given me a headache with your unsubstantiated drivel.
Here is proof, straigh from CVS, that what you are saying is pure nonsense: the terrain rendering source of the soulride engine.
Hint: you might want to take a look at the Render function. The comments are in plain English.
Great games
You could never share between a portals-based game (like Descent) with a BSP-tree based game like Quake, because they organize data in a fundamentally different manner.
You can. Both of those formats can be automatically compiled from a shared representation as simple polygons. The resultant map won't have the same manual optimization as if an artist had tweaked it by hand, though. For at least one of the engines, it will be slower than necessary. Quake and Descent are both 3 generations old, though, so a modern computer will chuckle at the extra work. (And the created Descent map may be quite ugly, as stretched-inverse-cubes are unlikely to gracefully represent the details of a Quake level)
The more substantive problem to sharing maps is the gameplay itself. Imagine what would happen if Mr. Quake was spawned in a Descent map: he'd run 10 meters, then fall into an inescapable depression- because the map was built for a flying hero. Likewise, a Descent spaceship might find a Quake map terminally boring ("I just fly up, over the castle, back down, and win!")
If the maps are intended for more compatible genres, then it might work a little better. At least assumptions like "player needs to walk across floor to the doorway" will hold true. But still, building a fun, professional-quality game map means tweaking to exactly challenge the player's ability to move, jump, and shoot.
Restricting the desired category of games to highly realistic ones makes the idea of sharing terrain much more worthwhile. In that case, as long as the terrain correctly duplicates the original location, then any inability of the game system to work well in it can be filed as a bug against the software.
In particular, I've noticed a trend in several FPS programs to include the Fort McKenna MOUT training grounds as a playable map, which becomes a common point of comparison.
A still working URL for the screenshots can be found here