next »

[Ordnas]

I think Final Fantasy battle system was difficult to expand on NES due to technical limitation. The first FF on NES had parties and enemies separated by 2 Windows due to hardware limitation, probably the battle would be very different without these limitations. The active time battle came out only on the SNES. In my opinion 50% of the battle design choice came from an hardware limitation. Then changing the battle system became a very delicate decision on more powerful hardware, a FF without turned based battle could be translated for the fans as a "not a Final Fantasy".

[gimymblert]

IMHO there were already element of puzzle in all final fantasy and dragon quest anyway, it's just they had to have a way for player to advance and be rewarded, so they ensure everyone could progress by deliberately giving too much potion, beating through sheer grind, or let hardcore player be rewarded by breaking the game by learning the subtlety and be rewarded by being OP.

Which match my contact with jrpg in general, first playthrough is kinda grindy because I don't know anything, second playthough is like super fast because I beat boss 10 level higher than me with no potion, sometime locking them in a loop. For example many encounter are specifically design so you need to think about the row placement of your character (in front or the back) like the octopus in ff6, he only bash player in front with high damage, so you have to move all your character back (if you notice), but you can still just power through it.

I would not fault people for not noticing anyway, the only FF game that require less grind and more strategy upfront was ff14 with the paradigm system, but then they removed so much freedom in the game, it was basically linear.

[Ordnas]

Agree with you, for example in FFVIII and the first encounter with the T-Rex, it can kill the party with few hits, so you need to use Blind.

[ThemsAllTook]

I had a need to implement my own word wrapping algorithm yesterday. Only took about an hour of work, and around 70 lines of code for the core logic. Always a fun little problem to solve from scratch! I'd post a screenshot, but it just looks like normal text. I guess it's one of those things that you want not to be noticeable, because you'll only really pay attention to it if it's gone wrong somehow.

[InfiniteStateMachine]

I had a need to implement my own word wrapping algorithm yesterday. Only took about an hour of work, and around 70 lines of code for the core logic. Always a fun little problem to solve from scratch! I'd post a screenshot, but it just looks like normal text. I guess it's one of those things that you want not to be noticeable, because you'll only really pay attention to it if it's gone wrong somehow.

I know that exact feeling (down to the word wrapping problem) 

[oahda]

Cool! That's what's next on my text rendering list too but since it's for any writing system I'm using a library with a Unicode-compliant algorithm for breaking text properly regardless of script, so I'm probably not going to be able to get it done quite as fast as you did, haha.

[nova++]

After so long, I'm deeply pleased to have figured out (with help) my problems with ellipsoids, and now have gotten them linked into my terrain engine. It's been so long.



It even works (...for a while, before blowing up due to reasons I already know) with absolutely hilarious levels of elongation:



...Okay, maybe they look like they belong on the bristol stool scale, but dadgummit they're working. Now I can actually start working on ways to configure the terrain such that it doesn't look poopular.

[goob256]

The only cool thing I've coded recently is combo detection for fighting game stuff. It works with keyboard and gamepad including analog/dpad.

[ProgramGamer]

I just found a wikihow article on making a programming language, and I thought I’d share it with you all.

[ThemsAllTook]

I had a fun little problem to solve the other day. I'm building a turn-based combat system where each participant has their own speed stat, which determines how often they get a turn (higher is faster). I thought this would end up being obvious, but once I dug into it, I wasn't immediately sure how to make it work.

After some thinking, what I came up with was a system where each participant gets an invisible turn gauge. The top of the gauge is equal to the highest speed value of any participant in the battle. So, when I want to check whose turn is coming up next, I first look for full gauges. If there are none, I fill them up by each individual's speed value all at once, which will guarantee that at least one fills exactly, and others may overfill. If more than one is full, the most overfilled gauge goes first; if two are equal, I have a tiebreaker. The one whose turn it is gets their gauge emptied, though any overfill amount carries over.

It works great! I implemented it a few days ago, and while I was pretty sure the math checked out, I didn't get a chance to see it in action until today. In a test battle that lasted 15 turns, the participant with a speed value of 5 got 8 turns, the one with a speed of 3 got 4 turns, and the one with a speed of 2 got 3 turns.

There might be a more mathematical way to do this, but tracking gauge state for each participant lets me do things like change their speed in the middle of battle without disrupting any calculations. Since this isn't real-time, reality kind of bends around whoever happens to be fastest at the moment, which is the part that made it hardest to think about - it still feels wrong to have the gauge max out at the fastest participant's speed, but it seems to be correct as far as I can tell.

I'm surprised at how many little things like this I'm being prompted to solve for this project. It's revealing just how similar all of the games I've made before have been. My framework and templates make a lot of assumptions that they'll be used for real-time action games, and I wasn't able to see that until I tried to do something different.

[ProgramGamer]

Isn't that sorta how the later Final Fantasy games do it?

Not to sound dismissive of the fact that you solved a difficult problem of course, but if memory serves the modern final fantasy games use a meter for each character that fills up at different rates for each of them, and when that meter fills up that character gets to do an attack.

[ThemsAllTook]

Yup, exactly. That's probably what put the gauge idea into my head in the first place. These aren't ATB gauges, though - it's an invisible mechanism that's only there to produce the output of an overall turn order. I think Final Fantasy X used a system pretty much like what I'm building? I remember being able to see a graph of calculated upcoming turns so you'd know how many times you can act before the enemy gets to move.

[gimymblert]

yeah ffx, disrupting the visible order was part of the strategy,
other games just queue order based on speed on a single turn, can't make two move per turn

[Crimsontide]

Got my oct-tree bit-plane lossless voxel compression running!!

[Schrompf]

Nice! Pics or it didn't happen.

[Crimsontide]

I don't have anything pretty atm... just this:

Code:

BlockCompressorTest2():

level_dims: 4, 2, 1
level_offsets: 0, 80, 90
level_strides: (2,8,20), (2,4,8), (2,2,2)

block - stride = (1,4,10), dim = (4,4,4):
00 01 02 03
04 05 06 07
08 09 0a 0b
0c 0d 0e 0f

10 11 12 13
14 15 16 17
18 19 1a 1b
1c 1d 1e 1f

20 21 22 23
24 25 26 27
28 29 2a 2b
2c 2d 2e 2f

30 31 32 33
34 35 36 37
38 39 3a 3b
3c 3d 3e 3f

compressed stream - 37 :
40 55 55 49 42 34 d6 b7 84 68 ac 2f 0b d1 58 df 16 a2 b1 be 64 44 63 7d cb 88 c6 fa b2 11 8d f5 6d 23 1a eb 03

block - stride = (1,4,10), dim = (4,4,4):
00 01 02 03
04 05 06 07
08 09 0a 0b
0c 0d 0e 0f

10 11 12 13
14 15 16 17
18 19 1a 1b
1c 1d 1e 1f

20 21 22 23
24 25 26 27
28 29 2a 2b
2c 2d 2e 2f

30 31 32 33
34 35 36 37
38 39 3a 3b
3c 3d 3e 3f

block compression success
Done

Its the compressor working on a 4x4x4 voxel block (picked a small block size so the output was manageable for debugging) of 16-bit voxel values.  So uncompressed it would take 128 bytes, compressed it takes 37.  What makes me happy is that the above data wouldn't compress at all with a normal RLE approach, this is kinda a pretty rare/unlikely situation, and it did quite well.  Most real data would compress much better.

[Schrompf]

How does it work?

For comparision: I compress 8³ voxels of 8bit each by applying a palette and an in-place SVO tree. It looks like this:

Code:

- 3bits Num Bits per Palette entry. >6 falls back to "uncompressed", because from there compression turned out worse than storing directly
- xbits Number of Palette entries, sorted ascending
- x times y bits palette
- 8 bits - 1 for every 4³ block being solid, 0 for "subdivide further"
-- x palette bits for every solid 4³ block denoting the solid voxel
-- or
-- 8 bits - 1 for every 2³ block being solid, 0 for "2³ individual voxels"
--- x palette bits for every solid 2³ block
--- or
--- 8 times x palette bits for every individual block of voxels

With optional 32bit "average colour" for whole block and for every individual 4³ block for quick lodding. Left out for network transmissions, for example.

Up side:
- Compresses well, the averagely detailed block is around 10 to 20 bytes down from 512 bytes.
- Most algorithms performed on the voxel world have to work along the hierarchical structure and can simply work along this compression scheme without decompressing it first.
- Easy mass processing of voxels - 2³ voxels are guaranteed to fit into uint64, AVX can handle up to 4³ at once. Some bit fiddling gets you a long way.

Down side:
- Generates blocks with varying mem sizes, more difficult to allocate/deallocate. I have a block allocator and unit tests, but gameplay tends to change the voxel world over time and cache coherency will suffer
- Palette building and compression still needs to be vectorized, but I haven't had an idea, yet

[Crimsontide]

That's interesting, you're sort-of using an oct-tree but packing it into a single chunk.

For what I'm using there's no restriction on size, so 8x8x8, or 256x256x256, whatever.  It can even work with non-power of 2 block sizes so 14x2x38 would work... not that I have any use for that.

It's also templated so as not to be type restricted, I plan on using 16-bit voxels, but I wanted the flexibility to use it for other sizes in the future.

It basically uses two forms of compression that work together.  1st we separate the source into bit-planes.  So for a 16 bit type you would have the 1st bit plane be the least-significant bit of each voxel in the source block.  The 2nd bit plane would be the next most significant bit of each voxel, etc...  So for a 16 bit type you have 16 bit planes.  Each bit-plane is compressed using oct-tree run-length-encoding.  Each oct-tree node for each bit plane uses a very simple prefix code.  So the bit 0 means that node has children, 10 means its all 0's, and 11 means its all 1's.  Obviously applied recursively.  At the very bottom nodes/leaf nodes since there can be no children we simply encode 0 or 1.

Oct-tree encoding is great for 3d data with chunks of identical voxels, but if the data differs even a little bit it can break down.  Since I want to do physics simulations with the voxels, I imagine it'll be a common situation where many voxels will be similar in value, but not exact.  Bit-planes work wonders in these situations, because most of the bits in similar numbers will be identical (and hence will compress into runs via the oct-tree) while only the bits that vary between values need be stored.

It sounds more complex than it is.  What's cool is that I can encode/decode all bit planes simultaneously.  So I don't need 16 passes for 16 bit-planes, 1 pass will suffice.

That said I never thought of doing the simulation in-place without decompressing it first, that's an interesting thought.

I was looking at AVX2... but I thought it'd be best to get farther along and profile before heading down that row.  I'm not too worried about compression speed, as it'll happen much less often, but the idea of being able to decompress 8 blocks at a time seemed interesting.  My issue is there is no scatter instruction, and the gather instruction is rather awkward to use.

[oahda]

Think I posted about how easy Bullet was to get going before, but now it's getting properly integrated with my own engine, with body and collider components on entities, and those entities then getting controlled by the physics system! And some debug drawing too, finally, to see what I'm doing.



Only box colliders so far but now that I've got things up and running it should be a breeze to add more types—and to debug draw them as well. c:

[qMopey]

Nice work! I like the debug rendering. Very smart of you to implement that

Personally I have a nice little debug rendering suite for wireframe/solid geometry for all the common shapes, like sphere, capsule, cylinder, box, triangle, line, etc.

Comes in handy *all the time*.