Posts Tagged ‘procedural’
In my personal slow-Jam I’m working on I decided to leave everything to Random and a few parameters.
Still there’s the need for levels, and the very basic requirements that everything should be connected, walled in and have a nice balance between narrow passages and open spaces.
There’s probably well known and better ways to do this, but any case, since I think the end result was more or less exactly what I wanted, I’m gonna outline how I did.
- Define an allowed geometry by normal sampling a width and height of the map (in tiles). I used a 2D boolean array as representation when doing the calculations
- Randomly seed some few (<1%, but more than ~7) positions so that each has a safety margin to the border of the array
- Iteratively connect dots by randomly selecting one not connected to the others and walk towards the closest other true position following Manhattan distance = 1 setting all passed positions to true.
- Repeatedly randomly select any edge pixel and randomly select one of its 4-neighbours that are unused and expand there.
- When sufficient number of tiles have been placed. For all edge tiles, place a wall in all unused positions with a chessboard distance of one
I only need quite small levels as each is only meant to last for maximum of 60s and the game is absolutely way too confusing to allow for larger levels, but in principle it would only require some parameter tweaking to get them too look quite differently.
I also like how one sort of can see where the seeds must have been placed.
Of course if anyone is interested in the code just let me know (it’s C# for Unity, and it’s not super-efficient by any means but since it’s only run at level start I figured it doesn’t matter too much).
Hello everyone !
So this is my post-mortem for Tinysasters, my LD# 23 48h entry made in Flash.
As I said before this was my very first participation. I hadn’t planned to enter the event until about one week ago, and I didn’t prepare. But I work on flash games every day, so this must count as some kind of preparation
I was a little anxious, because I had never developped a game in such a short amount of time, and I didn’t know if I could do it. But everything went very smoothly.
Tinysasters is a puzzle/simulation/gestion game. You play on a 8*8 randomly generated tile map and have to build workplaces, shrines and cities in order to collect ressources. The goal is to build a level 4 shrine. Natural disasters happen every now and then. They reconfigure the ground and make your life harder !
Build the level 4 shrine to heal the ground and spare the world from disasters like earthquake !
The idea was to make something between the boardgames Settlers of Catan and Labyrinth ; basically a Settlers of Catan where the tiles move and change of nature.
At first, I was absolutely not happy with the theme. I rated it -1. I liked “Artificial Life” and “Castles in the Sky” a lot better, but I don’t know if I could have made something good out of them. The theme doesn’t matter a lot actually.
As for the nature of the game, to be honest, when it comes to play, my heart usually goes to platformers and adventure games with a good story. But programming is my strongest point, so I thought I should rely on it a lot for my entry.
What went right
- (almost) no time wasted on debugging ! That was a good surprise. I’m used to spending a lot of my time fixing problems that seem to come out from nowhere and make absolutely no sense although they usually end up being all my fault after all. That’s one tremendous benefit of working on a very small project : I just had to see a bug to know where it came from because the entire code of the game was so fresh in my mind.
- I was a little scared at first when I started programming the tile animating sequence that happens when there’s an earthquake or the player generates a land. But it went smoothly and the TweenLite library was very handy.
- I hate building / coding menus and interfaces with so many buttons, and so many textfields, and tabs, and they all have to update, show the right information, show a red color when there aren’t enough ressources, etc., and it’s so overwhelming… It was very tedious but it went ok. There are a lot of ugly duplicates in my code but I guess I can live with that.
One of the many possible states of this interface box…
- About 40 minutes before the deadline, there still were no sounds, and the tiles were still rough colored cubes. I rushed on as3sfxr to generate some sound effects (very useful tool), made a quick music arrangement, added an underground effect to the tiles, some texture and some decorations.
Despite the fatigue (it was about 2 AM and I had worked all day), I found myself inspired so everything went quickly and I finished on time.
- I’m very happy with the result. I enjoy just watching the game playing disasters and reconfigure the map into wild deserts, forests and lakes. The mountains always prevail, eventually.
Invasion of the mountains !
What went wrong
- The firsts hours of coding were the hard part. Sometimes I’d finish coding a new fonctionnality, like the map generation, and had some kind of a mental blockage : I just couldn’t figure out what to do next. What I had in front of me was so far from being a game… it was a little overwhelming.
a depressing early stage of the game
- Like I said, I only had 40 minutes to polish the sounds and graphics. I had great expectations for the animations, I wanted to use beautiful particles effects… I wanted the tiles to explode in a thousand of pixels when they reach the borders of the map instead of those mere alpha fade outs… I wanted the volcanic eruptions to set the map on fire… I wanted the flooded tiles covered with shiny swinging blue water drops… I wanted a little flying god inpersonating the player’s actions react to the disasters and constructions…
Nothing of that was done. I am so sad. Maybe in the enhanced version
Also, more types of disasters were initially planned. Disasters that only affect the constructions : plague, civil war, etc.
- 7 hours before the end I was like “Great, 7 hours left, I have PLENTY of time to do everything I want !”. But 7 hours in the end are not like 7 hours in the beginning, especially with the timezone I’m in. I was so tired I was like a zombie and sometimes found myself spending half my time just starring at the disasters do their thing. It’s a good thing the game was already well-advanced at this point.
What went terribly wrong
- But the biggest problem I encountered came from the nature of the game itself.
“Do the game mechanics even work ?”
I couldn’t answer this somewhat significant question before the game was ready to be tested. The disasters had to be coded, same goes for the ressources, the buildings, the upgrades and all the time-consuming interfaces that come with it.
The game was ready to be tested 2 hours before the end.
I had my fiancé test the game. He told me he was troubled by the game even though he knew what he had to do.
At first, I didn’t listen to what he said and continued to blindly code what I could. Coding more interfaces wouldn’t have bothered me that much at this point.
Then, I had to face the reality : the game mechanics didn’t work as they were.
I had to balance the costs and gains of ressources, add difficulty settings to avoid overwhelming the new player or boring the experienced one, write a “how to play”… For that, I had to test the game a lot which takes some time… And the game navigation (title screen, restart…) wasn’t done yet, nor the graphics and sounds, not to mention the fancy particle effects I still hadn’t given up on !
The last minute how to play screen
Damage control was done, but the game ended up being less challenging than I would have wanted. Hopefully a future enhanced version will correct that !
I’m very glad I participated !
Thank you for reading and don’t forget to rate Tinysasters
I hope you’ll enjoy the game, I enjoyed making it a lot !