Wednesday, May 29, 2013

Green Algae: Bridges

Alright, so a little movement on the 'Green Algae' project. I was able to add the ability to create
bridges that you can walk across. This allows you to connect islands together.

I gave it a go and it took me a long time (hour and a half) to create a bridge connecting the island I was spawned on to the island to the north. Perhaps the world is a tad large or the island just aren't big enough. Another thing is just a small chunk of the trees at the top of that island were cut out in order to make the bridge. Which currently you do by dragging trees one bridge section at a time. So there was a lot of lugging and chopping going on to get that bridge built.

It was a little annoying having to drag around the trees, and chopping down that many with no hope of doing it a little faster each time was not very fun. So that definitely needs to be tweaked and improve chopping speed over time so you feel like you're progressing and getting rewarded. Some visual effects of the tree falling, or effects when you grow stronger might also help.

No saving maps yet which will be necessary soon. for play testing long term progression and replayability things that don't matter right now because there aren't any full game mechanics yet. The map generation seems to make islands that are all slanting from left to right which is odd but it must be something with the random generation I need to work out.

I also have a perlin noise generator that I can integrate and use as a way of generating a map it might we a lot faster as well. I need to tweak the rotation of the bridge sections so that they flow in the right direction pretty easy to do as you can imagine.

For chopping down trees I use a state machine. Here is the line in my update function.

chopState = chopState.handleEvent(input, world, dt, collisionResults);

Where input is an input manager that has the state of the keyboard and mouse etc... dt is a fixed time step value per frame. World contains a reference to the map and a list of drawable objects and various other things. The collisionResults holds the objects that the player is colliding with this frame separated by object class type, I use a partioning scheme right now the strategy is to have bins based on the grid of tiles in the map, lookup time is really quick probably uses more memory than it needs, though.

For the chop states I have a start, end, and a no chop (or idle state). I also use that mechanism for dragging. This keeps the number of if checks or switch statements (which I don't have any of) down to only what is needed. For instance, instead of a bunch of else if statements to check various states each state object has hopefully one if check in it which should very quick. It's about the same performance wise I would think but it helps make the code flexible for new states. The handleEvent method is called every update frame so if no conditions have changed for that state it just returns the same state.perhaps not the best to keep setting the variable if it hasn't changed but that's a minimal amount of time compared to other operations that are done.

So that's all for now, until next time I get a chance to move the code forward.