[gameprogrammer] Re: The Next Step (2D Side-Scroller)


On Mar 5, 2007, at 8:19 PM, Charlie Lobo wrote:
Well it depends on what you want to do. If making maps easily moddable, characters would be the way to go, but with bytes you can pack more complex information than just a tile easier. For example if I want some tiles to be "ghost tiles" instead of making a new type of tile I just define one bit to be a flag for ghost or real tile. With the triggered events, the only way to not use a scripting system would be to make simple/predictable events, or make a click and/or drag system, like Game Maker or RPG Maker, which would be nothing but a scripting system hidden as an interfase, XML could work for scripts, if you are into that.
I am, actually! (Into XML...) One of my other (for work) projects has involved some basic XML parsing/writing, and now that you mention it your are completely correct that XML would work for a scripting system! ^_^ I'm very happy you mentioned that! *gears turning*
For multiple background layers, do just that, layers. Now my recomendation is make diferent kind of layer definitions in your file: tile layers (with tiles), BMP layers (with images) etc. you can also attach them properties such as horizontal movement (as compared to that of the player) so far away layers move little compared to the player. For diferent sized tiles, you can make the definition at the beggining of each layer also, but all the tiles in each layer have to be the same. Multiple tilesets depends on your resource managing, but it's just making the pallete bigger, this included with tinting I would reccomend you strongly to use a byte level saving method, to get the most out of this, plus if you made it into characters it would become big, slow to parse (if the level is big enough) and not as easy to read as you'd think.
What I'm thinking for tilesets is I have "Form" objects (singletons for each type, so like a brick tile would be a "Form") and I imagine loading up each tile SET as a form, and including definitions for the different tiles within that set, so if I say tileSetA.draw(n), then it draws the n-th tile as defined in an accompanying text file.
Also, Java comes with /zip file reading capabilities, so I was planning on, once I get all my files/images/scripts together for a game, just zip that up (maybe password the zip file) and have the game load it all from zip/s.
Another recomendation is to make a strong object system. You can use this to make strange size tiles, also you can use this for more interesting effects by putting them in strange places, such as BMP layers, for a Yoshi's Island effect (when the cannon balls jump from the background into the foreground). What's more, areas and such could be objects, and you could have the ability to include the objects in the map (case they are unique), make "quick" standard objects (like the square area) and save objects in another file (for enemies or items that appear in other levels)
I do indeed have everything set up into objects. Part of my goal with this project is to make a usable, versatile object-oriented game framework for the public in Java (read: cross-platform and proof of concept). Thus I'm not at all limited to single-size tiles per layer. Everything (thus far) has a collision bounds and my moving object/s check against anything registered as "collidable".
Final thing, on the using one polygon, on another thread someone recommended once the using of fragment shaders to tile using the video card acceleration, but you'd have to look for that. 
I don't know if any of this helps you, but hopefully it will.
Indeed! Even just talking about things I may already be planning helps because I'm hearing it from another perspective, and that cements it in my mind, or helps me realize something that would've taken extra time to fix later! So I promote discussion! ^_^ Thanks! 

-- Scott

---------------------
To unsubscribe go to http://gameprogrammer.com/mailinglist.html

Other related posts: