i am working on a movement system for my game that makes quarter sized steps. By this i mean it takes four steps to make one BYOND standard 32 pixel transition. The system is supposed to feel less chunky/blocky.
The way I was originally going to do this was to use pixel_x and pixel_y but i realized that it wont allow me to make steps but just little jumps unless I go way over the top with coding it. It would also slow down my time as I make complicated collision calculations and whatnot.
So another method I've come up with is to simply make the game's concept of tiles into an 8x8 instead of a 32x32. This concept would be really good because it would allow me to make use of many tile based tools that BYOND is equipped with, like pathfinding and use of the mouse. My question is, what complex code with I have to use, what would I have to override, and where should I start, to create such nonsense as 8x8 tiles?
If I could shrink the tiles down I could make a system that is capable of pseudo freeroam. No more tile based (wink wink). This would be great because i would still be making use of the default tile systems, but with so much more control. And I wouldn't have to draw a bunch of extra graphics and slow the game down, I could just somehow have each tile have four/sixteen quadrants.
ID:272845
 Apr 13 2009, 6:36 am
|
|
wow thanks man! Thats really cool of you to help me out with this, I was just hoping someone would shed some light on this. If its good enough you could offer a library, that would make all the BYOND games capable of freeroam.
I totally agree that the tile graphics should be 16x16, that makes the mapping really easy and still really nice. So I guess the best way would be to cut the 16x16 tiles in quarter (2x2) rather than cut 32x32 into 16ths (4x4). Then we could just resize the viewing and we're good. The tileset I'm using is comprised of 16x16 graphics used for autotiling grass and dirt and such. I stole it from rpgmaker if your familiar with it (I paid my $60). I'll probably end up replacing it before I publish but its great for developing with. It would work perfectly as 16x16 tiles that makes it free for grass and whatever to be not so obviously tiled. | |
Popisfizzy wrote pif_MovementSystem which I believe would suit your needs excellently. Pop handles all of the 'way over the top' coding for you.
| |
Thats SWEET. Now I just need to be able to use the mouse with the pixelized tiles! That might be tricky...
I found a bug with it, I tested it to see if the pixel stepping could be relied on but it glitched out and randomly made me bump air near a mob, and randomly let me walk through it. Twas wierd, as if the mob's size was constantly changing. EDIT found out more about the glitch, when you try to walk into a mob you have to go at least 1 tile away before you can walk in that direction. | |
Verm didn't properly look into the library. It's not designed to specifically handle pixel movement. All that is is part of my demonstration on how the system can be used to break movement-handling into multiple pieces. Essentially, it just breaks movement-handling into multiple parts, adding new things and modifying a few others.
[Edit] And, in fact, had you read the documentation, you would've caught this right away. Therefore, the moral of the story if RTFM. | |
However, I would strongly suggest keeping it at 16 x 16 pixels, enlarged to take up the full 32 x 32. I would agree with trying to make it look less "blocky" but world creation with 8 x 8 tiles would be extremely tedious and time consuming.
I have no code specific to what you are looking for, however given enough time I could probably produce something that would achieve the goal you are pursuing. Give me a day and I'll see what I can come up with.