working on cliff generation, specifically marking the edges properly. to properly illustrate chunk boundaries i made the chunk colors alternate between grey and white.
the top image is the initial cliff edge marking (any tan tile connected to a white tile becomes orange).
the second image shows the second pass where i convert all white tiles with 2 orange tile connections into an orange tile. this method actually gives worse results and causes large gaps between cliffs segments in different chunks.
the third image shows a tweaked version of the method used in the second. i am converting tan tiles to orange instead of white tiles to orange. it gives significantly more accurate results, still a few gaps to sort out though. i am missing a specific case related to chunk edges.
this simple method i am using works beautifully. i originally used the marching squares algorithm to mark the edges of the tan blobs but it would have taken a lot of tweaking in order for it to give the proper results.
Here is some simplex noise combined with my ‘infinite’ chunk-based game grid. You can see where the chunks connect. There are 9 chunks in the grid and you start in the middle. If you move to an edge chunk, that chunk becomes the center and the chunks which are not immediately on the edge of it are erased and moved to become the new edges.
Combined with saving/loading the entities within a chunk, this means i could create massive procedurally generated persistent grids.
The bottom image shows the difference between using different octaves with simplex noise (the leftmost image uses 8 octaves). I started work on generating cliffs (the orange outlines on the right image) but it’s going to take a different algorithm to properly generate cliff edges.
A little test app i’ve been working on. I’m using Unity and it is really intuitive and easy to learn. I just started about half a week ago and I’ve already made substantial progress.
What it is: Eventually it will be a mobile game released on iPhone/Android. Originally I was going to make a Flappy Bird type clone just to get used to Unity but the learning curve wasn’t as steep as expected. I have a general idea of what i want to do and it will be Flappy Bird-esque, I suppose.
So far I have the procedural terrain generation (loosely) implemented. The white tiles are placeholders. Player movement works and basic input works (you can jump if the tires are on the ground).
I had some free time so I started work on my pathfinding for actor entities. Right now it’s barely functional (the actors can’t deal with obstacles yet and i need to cap path computation times).
When you select an actor then click a tile, it runs a function which computes a path to the tile (in the form of a queue consisting of tile objects). Then the actor starts de-queuing each tile and transitioning from tile to tile until it empties the queue. If a tile becomes impossible to traverse, then the actor will stop and re-call the pathfinding function, rebuilding the queue of tiles. For now, that doesn’t happen. It’s next on my todo list.
At this point i think i’m going to decouple pathfinding from actor entities and make an AI class for it because it’s becoming increasingly complex.
I finished more stuff. The white square up there is the cursor. I don’t have any cursor sprites (yet). Still waiting for the monogame update.
The yellow drawings i made there were a result of me testing my fully functional unit/tile selection code. And that dude in the top left corner is a (very crude) actor entity. It doesn’t do anything yet.
Redid the grid system, hopefully this will be the last time i have to do this. The grid is now an 8x8 2d array of chunks which are 256x256 tiles. At most, there are 4 chunks active (within camera view). All other tiles are made inactive until the camera moves within their visible range.
In the image above, the tiles are colored to show where chunks begin and end.
Ideally i was going to make the grid much larger but that would also bring in new issues. I’d run out of memory if i had more than 64 chunks and i would inevitably have to delete chunks that aren’t active then load them when the camera enters their visible range. So for now i’m going to stick with 8x8 (which is still pretty dang spacious).
I have put the sidescroller on hold for several reasons. The main reason being, i had no clear idea where i was going with it. I had ideas of what i wanted to implement, but overall it was a giant question mark. Sometimes that’s a good thing, in this case it wasn’t.
I’ve been doing a lot of the tedious boring stuff recently. I wrote an attribute system for entities and made them serializable. My next order of business is making a simple level editor. Instead of making a separate modding toolkit for this game i figure i might as well just build it into a developer menu since it’s easy.
No matter how i slice it, i’m going to need to implement a bunch of GUI stuff. I guess i’ll go with Winforms. I have no idea what i’m doing.
I Frankenstein’d the final product from several different sketches. I don’t own a scanner (i had to hold my webcam steady and take top down photos of each drawing) which explains the differences in color. If this looks like it was inspired by Earthworm Jim or something similar then that’s probably because it was.
For some god damned reason i can’t draw normal hands to save my life. I also can’t draw hands directly from an arm, i have to draw them separately then splice them in and re-scale them using Photoshop. The gun in his left hand was also drawn like twice the size it needed to be, because i’m cool like that.
More progress with player movement. Those two orange rectangles you see covering the blue bouncing rectangle are actually not colliding with anything, they are sensor bodies that tell me whether the player object is on the ground or touching a wall (which is why i can bounce off walls, that was intended). Normally they would be invisible, i’m just drawing them because i want to be sure they’re scaling properly based on the size of the physics entity they’re parented to.
The movement needs fine tuning but otherwise i’m pleased with the results.
I finished an input helper component which should come in handy for several things. I can’t see how anyone can program a game without using a component-based architecture… It’s messy enough with everything compartmentalized, I can’t imagine how much of a mess it would be if it weren’t.