Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Areyar]

No... it is not a neccesity... I, and many other old guys like me, have a hex fettish though.

Still, hexes are too much trouble in programming to just use them because it looks cooler.
If you need the better approximation of freedom of movement, you just use an absolute x,y,z coordinate system with a higher resolution and use vectors for movement etc.

Spoiler (click to show/hide)

I have thought about implementation of hexes in a game actually, but that was for a boardgame.
Not sure whether this is the way that is used by professionals... (in essence the hexagon p,q,r grid is reduced to an offset square x,y grid (square bricks) by altering the rules for movement, so that it appears to allow movement from a tile to the 8 surrounding tiles, except for the upper left and lower right corner tiles.) display is just drawing the icons on the corresponding locations of the hexgrid.

[Vactor]

A quick example of what i've been working on.  arbitrarily numerous chunks of tiles are generated with random tiles, and are sent drifting around the screen at varying z levels.

I also put in a fog to give it a bit of depth, and there is a sky box that is toggled off in the picture(as I don't have a good enough texture for it, a big empty square that says ground looks far worse than nothing at all)

My big struggle for today is getting it to build into a self executing .jar file.  LWJGL doesn't seem to be playing nicely, and I'm not sure how well my textures are existing in the buildpath.

I'll probably put in buoyancy sorting(small chunks rise, big ones sink), collisions, bumps and squeezes next.  Right now the drift of the chunks are throttled by using tiny decimals that are added every frame, I should probably bring that into a distance/time calculation that will be independent of the rendering rate.

I really like hexes, but at this point would only want to program with them on a static map, not one that is constantly being altered.  It was a huge headache converting coordinates into a hex grid, and tracking connectivity and pathing.

[Vactor]

update:

Mouse picking is in now, as well as a camera that accepts and travels to destinations derived from clicking on something.   The clumps are sorting themselves, and the drift movement is metered to 10 steps/second.  I'll still need to add in system lag adjustments for motion, but that should be rather simple.  I also put in some infrastructure for Airlands (player owned collections of clumps) and just generated the first one. 

I'm putting in movement controls for the player's Airland now.  Sadly the stuff i've been working on wouldn't show up in a screenshot, so it would look about the same as my last post.

One of the interesting side effects of the buoyancy sorting is how the Airland building sub-game will become harder the lower you sink.  At the highest altitudes clumps are small and will fit together into tightly knit Airlands.  As you get heavier the lower altitudes are filled with oddly shaped and gnarled clumps that will make it tough to add onto your Airland without leaving gaps.  I could see a niche role for a player  to fill in a multiplayer game as a small-clump courier, gathering high quality small clumps with a small, lean Airland, and dragging them down to the low altitude big guys for trade.  You would just want to take precautions so that you don't end up getting attacked rather than traded with.

Multiplayer is probably going to be a ways off at this point, as i'm going to focus on getting a fun single-player experience underneath the multiplayer mechanics.

[The Doctor]

Are you going to put some Natural Phenomena? Like, things that don't get attached to your Land, but affect them? I can't explain it, but hopefully you get the gist.

[Vactor]

I am planning on having some sort of ambient phenomenon based around regional weather, which can have a blanket effect upon your tiles, including bonuses and penalties, as well as the possibility of acclimation.

Imagine a wildhaired sorcerer took his people into the blizzardy skies above the mountains in pursuit of a fabled artifact.  Buffeted by swirling winds and harsh temperatures, many perished as the villages were snowed in.  When he returned however, strange Ice beasts roamed his land, some areas seemed to emanate cold themselves, and many peculiar gems had formed around the tops of the rock formations of his airland.  The local mage guild quickly discovered that these gems had hidden magical properties.

Oh and i have airland movement in, right now its very full of inertia, and you move it by accelerating it in a particular direction.  I'll have to include a speed cap to prevent any light-speed achieving airlands.

[PTTG??]

I'd think that the hazard of relativistic collisions would do some of that... on the other hand, high speeds could cause earthquakes and other damage.

[redacted123]

-

[qwertyuiopas]

Speed limitation would be very nice and dynamic if it was due to "air resistance" based on the size and current magical effects. That way, maximum speed would vary nicely with current acceleration and landmass, giving players more hard choices in balancing their landmass, especially if a larger landmass could provide more power, but not enough to fully counteract the increased resistance/inertia...

[The Doctor]

Here's a question...

Multiple level lands! You planning on anything like that? Just for aesthetics, probably... But it'd be cool <3

[Cajoes]

Some simple fanart for a game that barely exist yet.

[Vactor]

quick update:

I've got the mouse casting pick rays at will (ran into a mysterious issue with this where the ray's vector only comes out right if I use the two z positions of 0.114 and 1.114.   I was using 0.0 and 1.0, and fought with it over the course of the last week or so, before discovering those magical constants).

I also added in collisions, its entirely non-optimized at this point, so I only have it calculating collisions with the Player's Airland right now for testing purposes.  The crazed bouncing has created the need for some air resistance to slow down the clumps of land that you send hurtling after a high speed collision, otherwise the game would quickly turn into an ever expanding ring of clumps.

I tried replacing bouncing with sticking, and have that working now too, however you can get stuck to another clump of land without your grids matching up, which is something  i'll have to fix.  I was able to tool around a bit and sweep up other clumps and build a little map for myself.  I think it will work out so that if you hit something slowly, you stick to it, if you hit something at moderate speed you bounce, and if you hit something at very high speeds, you break off parts of your own Airland. (the recipient would get bounced, not broken)

Also, got the program building, was a simple fix, but it should be easily distributed once I have something playable to show people.

[dennislp3]

watching

[Virex]

I've got the mouse casting pick rays at will (ran into a mysterious issue with this where the ray's vector only comes out right if I use the two z positions of 0.114 and 1.114.   I was using 0.0 and 1.0, and fought with it over the course of the last week or so, before discovering those magical constants).

How are you casting the rays? Because if you're casting them using the front and back projection plane of the camera, you have to take into account that it's only an estimation, which gets better when the front plane is further from the camera. I used to have the same problem in a project of mine (using XNA's built-in function for casting rays) and it was solved by moving the front projection plane out fro 1 to 500 or something (which gave a deviation in the order of 10^-7)

[Vactor]

It would be interesting if airlands could devote certain tiles to functioning like battering rams, allowing them to simply plow into another airland, shattering the tiles it hits and crunching the two together for easy boarding.

Forcing the Airland you slam into to try to condense might be something i'd implement, like if someone puts a bunch of spiky clumps on their sides just to make it difficult to attach.  I'm about to start working up a sorting mechanism for the Airlands, so that they can adjust themselves to make their attached clumps fit to their internal grid.  I'll probably not have individual tiles being annihilated, because that would then in all likelyhood become the practice for paring down oddly shaped clumps.  Right now Clumps will always retain their shape, so you as the player have to make some choices about which ones you want, rather than taking the ones with the best tiles and breaking the chaff off.

Speed limitation would be very nice and dynamic if it was due to "air resistance" based on the size and current magical effects. That way, maximum speed would vary nicely with current acceleration and landmass, giving players more hard choices in balancing their landmass, especially if a larger landmass could provide more power, but not enough to fully counteract the increased resistance/inertia...

Something like this will probably go in before too long.

Here's a question...

Multiple level lands! You planning on anything like that? Just for aesthetics, probably... But it'd be cool <3

I had thought about it for awhile when i was considering how best to do them.  I had though about each piece having an elevation value for each side, making more complex linkage, and the possiblity of having interesting geography like spiral paths that work their way outward from the center of your Airland.  I've also considered having something somewhat simpler, like a plateau level, which some tiles would have plateau qualities, and would only be accessible by an adjacent tile with a slope quality.  The latter is still a possibility, however It might be a later addition, the landscape of the tiles is still at the placeholder point.

I've got the mouse casting pick rays at will (ran into a mysterious issue with this where the ray's vector only comes out right if I use the two z positions of 0.114 and 1.114.   I was using 0.0 and 1.0, and fought with it over the course of the last week or so, before discovering those magical constants).

How are you casting the rays? Because if you're casting them using the front and back projection plane of the camera, you have to take into account that it's only an estimation, which gets better when the front plane is further from the camera. I used to have the same problem in a project of mine (using XNA's built-in function for casting rays) and it was solved by moving the front projection plane out fro 1 to 500 or something (which gave a deviation in the order of 10^-7)

This might be the issue, my projection frustum is using 0.1 and 100.  Its working fine right now at any aspect ratio, so I might leave it alone for the time being, unless something funky happens with a non-16:9 resolution.

Also, thank you Cajoes for the fan art 

[Deon]

Oh god, it's been a long time! I'm glad you are working on it again.

P.S
 Hexes looked nice though .