Hello there fellow SFML users,
This is going to be a big question so get ready. First off I have attempted to create quite a few games with C++ and SFML, programming the functionality isn't to hard, but after a few weeks, or months or even days my structure does always seem to mess up, what I mean by that is, due to something I did way back means i have to amend something new to fix that problem but some of my old functions are using that function, this happens all the time and I completely understand it is my fault for not fully understanding the structure of my game or the program.
So basically I am trying to create a simple clone of Mario Bros, so we have a title screen, a character, some enemies, a map made of blocks, score, time, lives, levels, continues, projectiles etc. So here is the my problem, using SFML i have myself a imageService, soundService and musicService, now these basically just load a file and store it inside of a map so I can call on that file when I need. But here is the main problem
I have a State which has a ImageService, the state has a hero and a level, would I assign them each a image? for example hero.sprite = imageService.images["heroImg"]; would that be the best way? Second lets say if a level had some blocks, but some blocks are infront of the hero, would I have to write out my render function to say
//Draw level blocks
//Draw hero
//Draw upper level blocks
//Draw menu
//etc...
But then a really big important part is, the renderwindow is 800 by 600, in most computer games the user is allowed to change the size of the game, so lets say the user wants to display 1280 by 768, where would be the best place to draw the sprites differently? What about collision detection? if the view was 800 by 600 and now it is 1280 by 768 the width has go up by 1.5 and a bit and the height has changed by 168 pixels, would I save a global variable in my state which has the "ratios" of the screen? so 800 by 600 = 1:1 and 1280 by 768 = 1.6:1.28 would I then use that to modify all sprites displaying and also use that to modify collision detection?
I'm just really trying to get my head around the structure of a game, does anyone have any simple links to books or articles on how to structure one, or even better a tutorial on how to structure a simple SFML game.
window.clear();
// notice the order
// back to front
window.draw(background); // background first
window.draw(player); // then our player over the background
window.draw(hud); // then our user interface or whatever you want over the player
window.display();
(http://i.stack.imgur.com/G70oT.png)
http://stackoverflow.com/questions/471432/in-which-scenario-do-i-use-a-particular-stl-container
Or you could give all Entities a Z member and have a single vector of pointers to them which you sort every frame.
Why every frame? You only need to sort them once every time a sprite has just added, and that's assuming the data structure of the layers doesn't have predefined layers that the Z value falls into.
Example 1, each sprite has a Z value deciding it's layer of rendering:
spriteArray = list(sprite for sprite in spritesToBeLoaded)
spriteArray.sort(key=lambda sprite: sprite.z)
# rendering loop
while(gameRunning):
for sprite in spriteArray:
render(sprite) # already sorted
# later in the game, some entity is added
spriteArray.append(newSprite)
spriteArray.sort(key=lambda sprite: sprite.z) # we are good until next time something is added
Example 2, the sprite data-structure has preexisting layers:
spriteLayers = dict()
for layer in range(maxLayers):
spriteLayers[layer] = list()
#when adding sprites, they are automatically sorted based on Z attribute
for sprite in spritesToBeLoaded:
spriteLayers[sprite.Z].append(sprite)
#rendering them in the right order is trivial
for layer in range(maxLayers):
for sprite in spriteLayers[layer]:
render(sprite)
#no need to do any sorting, the structure is always sorted
newSprite = Sprite()
spriteLayers[newSprite.Z] = newSprite
The second alternative is more similar to the option about having a background-object, level-object and foreground-object, while still retaining all the flexibility offered by Z attribute based layering.