Sandboxes, Shmups & Tilemaps
by Glen C · 08/10/2006 (12:21 am) · 7 comments
Hiya folks,
I've been head down, playing furiously, and want to share what I've been up to.
First, for my sandbox, I gave entities the ability to grab and drop movable parts of the environment:
It's basic functionality that I've wanted for a while, and it's always heartening to see it finally play out on screen the same way it does in the notebooks.
From there, I tangented and had to scratch a shmup itch. Working as always within my framework, I made myself a new entity subclass with appropriate shmup functionality (support for 'roll' animation on movement, mostly), and extended my camera to support roving shmup behavior. I fired up the tile map tool for the first time in a long time, and hacked out a new level with the default tileset. A new portal in my portal room and I have the core of shmump functionality covered.
For this test, the camera dummy was free-floating, and speed and direction are controlled by trigger tiles in the tilemap. That's a little rough for my liking, and for my next attempt, I want to try mounting the dummy to a path, which I expect should work rather more neatly.
Yesterday I wanted to play with tile mapping some more, so after work I tried my hand at a tileset to use, and last night, I threw together this level base. I was originally intending to make something long and shmuppy, but when I saw the big square tilegrid, I couldn't help myself. The result reminds me of the C64 sprawlers, bless 'em. I'm pleased to have learnt a few things making the tileset that'll be handy for the next one I try.
The long view:
Some 1:1 screens:
Now, the new TGB release is here to play with! It all looks very exciting, I'm looking forward to exploring the new possibilities. Of course, the new integrated tile editor has arrived at a good time, but if the per-layer y-sorting works as hoped, that just makes things even groovier. Too many potential paths, too little time!
Ah well, I'm still having fun, hope y'all are too.
Cheers,
Glen C.
I've been head down, playing furiously, and want to share what I've been up to.
First, for my sandbox, I gave entities the ability to grab and drop movable parts of the environment:
It's basic functionality that I've wanted for a while, and it's always heartening to see it finally play out on screen the same way it does in the notebooks.
From there, I tangented and had to scratch a shmup itch. Working as always within my framework, I made myself a new entity subclass with appropriate shmup functionality (support for 'roll' animation on movement, mostly), and extended my camera to support roving shmup behavior. I fired up the tile map tool for the first time in a long time, and hacked out a new level with the default tileset. A new portal in my portal room and I have the core of shmump functionality covered.
For this test, the camera dummy was free-floating, and speed and direction are controlled by trigger tiles in the tilemap. That's a little rough for my liking, and for my next attempt, I want to try mounting the dummy to a path, which I expect should work rather more neatly.
Yesterday I wanted to play with tile mapping some more, so after work I tried my hand at a tileset to use, and last night, I threw together this level base. I was originally intending to make something long and shmuppy, but when I saw the big square tilegrid, I couldn't help myself. The result reminds me of the C64 sprawlers, bless 'em. I'm pleased to have learnt a few things making the tileset that'll be handy for the next one I try.
The long view:
Some 1:1 screens:
Now, the new TGB release is here to play with! It all looks very exciting, I'm looking forward to exploring the new possibilities. Of course, the new integrated tile editor has arrived at a good time, but if the per-layer y-sorting works as hoped, that just makes things even groovier. Too many potential paths, too little time!
Ah well, I'm still having fun, hope y'all are too.
Cheers,
Glen C.
About the author
Recent Blogs
• Platforming with TGB• Moving ever forward.
• Endless War
• Hitting the road.
• Weekend Warriors
#4
If it were published, what would you want/expect from it?
08/10/2006 (9:02 pm)
Still too early and unproven, although I'm happy to revisit the question once it's shown it can do something complete and stable.If it were published, what would you want/expect from it?
#5
Support
Some major blocks to assemble a game in few lines of code
(I'm a bit tired to think now - 1am :))
08/10/2006 (10:07 pm)
Flexibility ;)Support
Some major blocks to assemble a game in few lines of code
(I'm a bit tired to think now - 1am :))
#6
> Flexibility ;)
Of course. Currently, it feels nifty for just about anything 2d & virtual/OO world based (top down, side on, cheap iso), and I'm hoping the new y-sorting will let me add in worthwhile 2.5d support. The basic framework would make abstracts or puzzlers easier/faster, I expect, and existing game logic controllers should run them just fine. Aside from the core framework organisation, (without which, it wouldn't be a framework), I'd hope there's nothing in the framework to limit what TGB can otherwise inherantly do. Will be interesting to see if that holds water. :)
> Support
Probably the foremost show-stopper in general. All the understanding on how the parts fit together and the reasoning behind why it's done the way it's done (or at least what the goal was) is souped in my brain, and writing it all out would consume large chunks of time I'd rather be having fun with. (All work and no play...) All that would require that the code itself be tested and proven and refined first, too, lest it be unfit for public consumption. And even then, the coding style is not much like the Torque standard. ;p
> Some major blocks to assemble a game in few lines of code
That's the plan, and it's looking decent so far, although I guess it depends on your definition of 'few'. ;)
Practically, any game of depth requires a bunch of code, but my ideal is, given the game is traditional enough, the only work should be new special-case features and content configurations. Will be fun to discover the final compromise with reality when I try making games with this.
08/10/2006 (10:40 pm)
Thanks for the thoughts!> Flexibility ;)
Of course. Currently, it feels nifty for just about anything 2d & virtual/OO world based (top down, side on, cheap iso), and I'm hoping the new y-sorting will let me add in worthwhile 2.5d support. The basic framework would make abstracts or puzzlers easier/faster, I expect, and existing game logic controllers should run them just fine. Aside from the core framework organisation, (without which, it wouldn't be a framework), I'd hope there's nothing in the framework to limit what TGB can otherwise inherantly do. Will be interesting to see if that holds water. :)
> Support
Probably the foremost show-stopper in general. All the understanding on how the parts fit together and the reasoning behind why it's done the way it's done (or at least what the goal was) is souped in my brain, and writing it all out would consume large chunks of time I'd rather be having fun with. (All work and no play...) All that would require that the code itself be tested and proven and refined first, too, lest it be unfit for public consumption. And even then, the coding style is not much like the Torque standard. ;p
> Some major blocks to assemble a game in few lines of code
That's the plan, and it's looking decent so far, although I guess it depends on your definition of 'few'. ;)
Practically, any game of depth requires a bunch of code, but my ideal is, given the game is traditional enough, the only work should be new special-case features and content configurations. Will be fun to discover the final compromise with reality when I try making games with this.
#7
For testing code - probably make a couple of demos from diff genres (yeah, it's a time sucker)...
few - 10-20 lines of code, the rest - data definitions(XML, etc..) and art ;)
ofcause - any specific feature will require custom coding, but basic features should be in framework (top down shooter, 2.5d level walker, etc. - just ideas)
I can start coding games with that already :) What will be the licence? Even if it will be a $$ code pack - still good.
08/10/2006 (10:47 pm)
2.5d support - would be awasome! Retro gaming! :)For testing code - probably make a couple of demos from diff genres (yeah, it's a time sucker)...
few - 10-20 lines of code, the rest - data definitions(XML, etc..) and art ;)
ofcause - any specific feature will require custom coding, but basic features should be in framework (top down shooter, 2.5d level walker, etc. - just ideas)
I can start coding games with that already :) What will be the licence? Even if it will be a $$ code pack - still good.
Associate Tom Spilman
Sickhead Games