Hello, i am interested in learning more about how "elastomania"(aka across) and "soldat" is built up with collision detection, rendering, and the managing of a map etc. Im sure many of you have tried one or both of these games. Does anyone know any specific resource that touch this kind of games ? Or can anybody tell me more about how it is done ??
2D vector style graphics and collisions
Miscellaneous Forums/General Discussion/2D vector style graphics and collisions the maxphysics project had some relevant stuff in it, last time I looked.
These kinds of games require a very good knowledge of geometry and maths to work properly, so bear that in mind.
These kinds of games require a very good knowledge of geometry and maths to work properly, so bear that in mind.
Made in Blitzplus:
http://www.enddream.com/download.php?view.1
Took us many months to get it done, since it was our first full game. A great learning experience. Just posting it as an example to show its possible to do it with minimal knowledge of physics, rendering, and game design, going in :). Cool thing is we weren't aware of soldat until about 7 months into development.
I've been meaning to do a write up for Gunstyle for a while. I guess if I have time I can do a detailed write up of 'how it was done'.
http://www.enddream.com/download.php?view.1
Took us many months to get it done, since it was our first full game. A great learning experience. Just posting it as an example to show its possible to do it with minimal knowledge of physics, rendering, and game design, going in :). Cool thing is we weren't aware of soldat until about 7 months into development.
I've been meaning to do a write up for Gunstyle for a while. I guess if I have time I can do a detailed write up of 'how it was done'.
Luckily i know the math that is needed for this kind of programming (linear algebra), but i havent touched the actual programming for something like it yet. Hey Alex O, looks cool, you dont have any screens lying around ??
After reading up abit i think i have one basic idéa about the collisiondetection. Im guessing, you build up a 2D octtree-like structure containing all "polygons". If you are in one segment of the tree, you check a bounding spere(for example) against the plane of the edges inside that segment. If you do pass one of the planes, you send the position on the plane to another function who determins if you are on the actual edge or not. The tilt of the plane can be used to determine a slide-factor on an eventual platform-character. Is this something like the real thing ?
If someone knows, what is the standard way of storing a stage made of triangles who consist of three points each.
And how do you go about rendering such a stage ?
After reading up abit i think i have one basic idéa about the collisiondetection. Im guessing, you build up a 2D octtree-like structure containing all "polygons". If you are in one segment of the tree, you check a bounding spere(for example) against the plane of the edges inside that segment. If you do pass one of the planes, you send the position on the plane to another function who determins if you are on the actual edge or not. The tilt of the plane can be used to determine a slide-factor on an eventual platform-character. Is this something like the real thing ?
If someone knows, what is the standard way of storing a stage made of triangles who consist of three points each.
And how do you go about rendering such a stage ?
Luckily i know the math that is needed for this kind of programming (linear algebra), but i havent touched the actual programming for something like it yet. Hey Alex O, looks cool, you dont have any screens lying around ??
sure I do :). Just haven't really been updating the site as much as I've been rather busy lately.
http://www.paradeofrain.com/wp-content/plugins/fgallery/fim_photos.php?album=screenshots
^screenies from most of the levels.
As for doing the setup of the collision detection, there really isn't a 'correct' way. As for Gunstyle we went the much simpler approach as it still had enough performance to meet our needs. The entire map is gridded off into sections (eeach about the size of one screen). This reduced the amount of collision checking by only colliding the characters and other physics objects with the current grid-section they were in. This was followed by a simple rectangle overlap to check if more detail checks are needed. Then the 'hard' part is to stop tunneling (going through objects) once you do the detailed check. Was simple, fast, and it worked. Tunneling was something we strove to eliminate in our engine because the player was not limited to how fast they could move in our game. Of course, if you don't reach speeds in your game of that magnitude this won't be an issue.
Of course, if you have a huge density of polygons in a single grid then it could hurt you. I don't think any of our levels reached that point. All of our levels had a very low poly-count since majority of it was just large chunks of terrain.
If someone knows, what is the standard way of storing a stage made of triangles who consist of three points each.
I don't know of a standard..unless you looked up some sort of known 3D file format. If you're only going to be loading triangles for the stage just for your game you should just come up with your own way of reading in the data.
And how do you go about rendering such a stage ?
I'm going to assume you are using Blitzmax or Blitzplus and that you are using the triangles for collision detection. With that said, I wouldn't even use the triangles for rendering. I would separate out my rendering routines from the collision routines. Depends on the detail you want to achieve, really. The way it was implemented in Gunstyle it allowed our artist complete freedom to put as much detail as he wanted into the 2D images. Later I would go back in an editor and import his images then do 'rough' outlines of the solid areas to create the collision hulls. These hulls were saved as groups of vertices and the images saved separately. So in reality, I would have a level laid out with nothing but collision hulls drawing themselves so i can get a feel for the level and make adjustments before alot of time was invested in the art.
The different parallaxing and foreground effects are achieved just with some sorting before rendering.
Then there's the quick way (I believe soldat might do something similar) and just use your collision triangles as you're rendering triangles also.
Nice graphics, but the gameplay is very bad, especially aiming.
Nice graphics, but the gameplay is very bad, especially aiming.
I can hardly agree with that. The game's target audience was definitely not the 'casual' gamer, and geared more towards hardcore gamers who tend to play skill-based multiplayer FPS. With that said, can't really say its easy to judge gameplay without actually playing it with others as there isn't an actual single player component.
that looks like a useful module IndiePath, thanks for the link :D
Maybe i'm not used to such one, but sometimes the mouse didn't change the angle os aim.