0
\$\begingroup\$

I want to make platformer game that would be sort of like megaman. I'm using SFML library for it. I have a problem with creating a map. Should I hardcode every single platform, add it colliders and so on? I've heard that 2d array of segments would be better, but I would still have to manually fil an array that's like 1000x1000 segments. Is there an easier way to approach this?

\$\endgroup\$
1
  • 2
    \$\begingroup\$ The question you have is a very generic. The best way to get more responses is to dot point all the considerations you have about your intended platformer. Try to limit your general question, if you state I have X problem and I have Y and Z options I am exploring, then people can more easily guide you through other considerations. You won't get a direct answer, but you will get more guidance if you are looking for advice on how research and grow your learning. \$\endgroup\$
    – ErnieDingo
    Commented Jun 5, 2018 at 22:16

1 Answer 1

1
\$\begingroup\$

Well it sounds like you should use or make this into a Tile-based platformer Engine. Another really helpful thing to know is if you're using images?

Among a lot of tile-based engines-You should load your images either by making code for your images (listed below) or if you're using image Files some how load each image into a sort of structure like below: (Here's the important part so listen up)

/c/b means color/byte or you could have a number/ /Structure started/ = { c/b, c/b, c/b, c/b, //New line c/b, c/b, c/b, c/b, //New line c/b, c/b, c/b, c/b, //New line c/b, c/b, c/b, c/b, //New line }

Here we have a grid of what (could be bytes or colors or, well it depends) to represent each image.

Options

Either what structure you're using (it doesn't matter) Loading the images into a special structure where it is easier to process collision. You could do 2+ things:

1. *sew* all the images/image structures together and actually have them connected some how. (Like a segment structure or an adjacency array) Or some structure where everything can easily build itself while connecting it self 

together; like:

/iteration 1/ - * * * * * * * * * * * * * * -

/iteration 2/ - * * * * * * - * * * * * --*

/iteration .../

Until it is all filled up! (You get the idea) So the it does the work for you. Also while processing collision you could just have everything relate to itself

2. The second option: Don't *sew* everything together and have it fill up by using like an array to copy in the structure you used to represent the map in. In this state your colliders create themselves.

And of course you could use a similar structure to represent the map as the image. I recommend you branch off of my ideas somehow to suit your needs. While you could use option #1 (preferably).

Relating the data together

And of course in a more direct state sort of sense. No don't be hardcoring parameters.

Make a structure for your images to be turned into something to go in like a [option #2 gameObject or as in option #1 just put it directly in your world structure]! That would be easily processed by collision handlers.

Make sure you have multiple layers for your game to work in. Segment/Array and under that all images stitched together into one big image!

Now with multiple images together (Unless you want to directly work with the images) while creating the code for that remember to store the image coordinates in an array (Called imgStorage) so you can create the top layer.

Referencing Objects

You could use that method to also get data from that imgStorage array and also to add bounding boxes (to the world structure) so you could put extra code in to help you represent/stitch/reference for your collision.

Now with everything in mind it's time to piece it all together!

  • You have your images imported with their data in their structure(s).
  • You have your grid/data/array to tell where to put the images/game objects.
  • Your images have gotten (and put) their parameters in imgStorage!
  • (Optionally) You made the image layer (piece together the images) backing the level(s)!
  • You've built your World structure (in part) by using the structure where
  • You've set you're bounding boxes imgStorage in their (image data/game object place) or structure where it needs to go
  • You've added extra references for bounding boxes to tell them they can collide and told them whether they are "static" or "dynamic"

That's it, all you need now is to put in the collision code the operates on the images...

And then you're done! I hope this helps!

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .