by date
Sandboxes, Shmups & Tilemaps
Sandboxes, Shmups & Tilemaps
| Name: | Glen C | |
|---|---|---|
| Date Posted: | Aug 10, 2006 | |
| Rating: |  4.0 out of 5 | |
| Public: | YES | |
| Comments: | YES | |
| RSS Feed: |  or Subscribe with  . | |
| Profile Page: | View profile page for Glen C |
Blog post
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.
Recent Blog Posts
| List: | 10/29/07 - Platforming with TGB 10/02/06 - Moving ever forward. 08/10/06 - Sandboxes, Shmups & Tilemaps 07/25/06 - Endless War 07/17/06 - Hitting the road. 07/10/06 - Weekend Warriors 07/06/06 - Sandboxing 07/05/06 - Gyhart Framework Design |
|---|
Submit your own resources!| Tom Spilman (Aug 10, 2006 at 07:29 GMT) |
| Glen C (Aug 10, 2006 at 14:01 GMT) |
| Alexander "taualex" Gaevoy (Aug 10, 2006 at 14:27 GMT) Resource Rating: 5 |
Any plans to publish your framework? ;)
| Glen C (Aug 11, 2006 at 04:02 GMT) |
If it were published, what would you want/expect from it?
| Alexander "taualex" Gaevoy (Aug 11, 2006 at 05:07 GMT) Resource Rating: 5 |
Support
Some major blocks to assemble a game in few lines of code
(I'm a bit tired to think now - 1am :))
| Glen C (Aug 11, 2006 at 05:40 GMT) |
> 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.
| Alexander "taualex" Gaevoy (Aug 11, 2006 at 05:47 GMT) Resource Rating: 5 |
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.
You must be a member and be logged in to either append comments or rate this resource.
