![]() ![]() Reset render e TileLayer for most efficient way to handle Private function onUpdate(inEvent:Event):Void Here we update all game entities and then render Your main game loop would something like this: class GameMain TileLayer uses TileSprite to replace, while gm2d uses Tile for the functionality Note: The libraries Tilelayer or gm2d (look in the blit folder) handle the drawTiles() abstraction nicely. Handling the graphics yourself is the major hurdle since you will need to plan out how you layout your graphics before you load a level in your game (using a Tilesheet). has x/y, width/height, rotation, scale, graphics, etc and you will need to replicate all of that in your GameEntity class. In order to do this you need to build up a class that has everything you need in it (ex: GameEntity). In drawTiles() you will optimally have only one layer for game content, so that you only need to call drawTiles() once per frame. Instead of using the build in class you can roll your own game entities and render with drawTiles(). If you did something like this then you could have enemies walk into your screen even if the hero stands still (camera not moving). Keep in mind that whatever game logic you use to move your enemies would apply regardless of the camera, and you would probably want a slightly larger box (bigger than the camera) that would be used to indicate if the game entity was "alive" i.e. Note if you use a game engine such as flixel, or awe6 that this type of thing is already taken care of for you, and unless you are interested in learning exactly what it takes to implement a smooth camera I always suggest using a tried and true game library to help get your game out quicker, but the end goals are up to you. The camera.moveOffset() function would look something like this: public function moveOffset(inXDiff:Float,inYDiff:Float):VoidĪfter you get this working you will have an issue where scrolling isn't smooth, so you will have to do additional work to change the camera position over time.maybe give it some elasticity to make it look nicer. move same amount as the heroĬamera.moveOffset(newHeroXPos-oldHeroXPos,newHeroYPos-oldHeroYPos) You could do this with a listener or just a function call, something like: var oldHeroXPos = hero.x The scrolling parts come into play by having your scrollRect() follow the hero. So now your "camera" is in the Game Container layer and you simply use scrollRect() to show exactly what you want. In order to do so you would add all of your sprites to a parent sprite so your display hierarchy looks like this: In this case the camera may follow your hero, so that it tries to keep the hero centered on the screen as much as possible (similar to how the original super mario bros. Basically you want to have a "camera" concept to show exactly what you want in your game.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |