That's it. *shot sound that fades deep inside your brain* I got my 20 ratings recieved, so here it is: post mortem, for those who liked and for those who haven't seen "It is rainy" yet.

That's a short story: Early saturday I was walking home, just after mine 8-th lesson ended. I was pondering: what game I can create to make it fit unstable theme. I stepped into the puddle, my sneaker bacame wet. "Hell! Pavement was dry this morning!". Instantaniously my brain got an idea. Weather. Weather is unstable!

I had enormous amount of plans and ideas I wanted to implement. But there is a rule, simple and cruel. Divide all your ideas by 20. I did it, so there is things (in priority ascending order) I wanted to put in this project, but cut and smashed them with a hammer: 1. Wind map, simply a map with procedurally generated vector field, this had to effect all meteorogical parameters, 2. Anemometer (wind gauge), disdrometer (some kind of rain gauge, but much more interesting), 3. Notepad, where you can draw with a pencil (It was supposed to help you store measurments, before sending them), 4. Electricity bill, to make you save electricity, turning off board and lights, 5. Sounds, for rain, wind and even nature to increase atmosphere, 6. Computer minigame, so you have an ability to play computer game inside computer game.

Things I learned:

P.S. This facts are also advises, that may ~~or not~~ help you.

Game design: - Cut, beat, disintegrate ideas you really like, but feel that there is no time to implement them. - Small details make your picture look awesome. You may have no skill in drawing or design, but working hard on detalisation - guarantees good result.

Code: - Proper way to access protected variables. Use methods to access other's object variable, do not do it directly. - Custom inspector may majorly increase your gamedesign possibilities and effectivness. Try it out, it is not hard.

Art: - It doesn't matter if you draw things incorrect, not like your art teacher does it. "It is rainy" has broken perspective, just look at bed or at table. - Spend more time chosing color palette, good one makes image juicy and colorful.

Oh, you read all of these? I do not believe. Get a :cookie: and do not forget to prepare for your firing squad :)

Have you ever tried to fight aliens with your own hovercraft tank? It's time to do this! 3 enemy types. 12 upgrades. Infinite waves. Play now: https://ldjam.com/events/ludum-dare/54/hoverspace

https://www.youtube.com/watch?v=5u9X54PuhiI

"Nothing is particularly hard if you divide it into small jobs" ― Henry Ford I came up with idea instantaneously. "Brotato" but room is shrinking. So I wrote a list of planned mechanics: - Player with WASD movement & additional movement option - Weapon for the player - 3 types of enemies - Infinite waves with increasing difficulty - Shop menu in-between waves with items and repairs - Room shrinking and a way to prevent it

Seems like a lot of things to do. And it definetely is. With careful planning, scope reduction and a ton of dedication I managed to implement all of this in just two days. The third day was spent on polishing, fixing bugs and balancing all of the things. Here is the list of things I wanted to implement if I had some time to spare (I did not): - Boss that appears each 10 waves with custom AI and attacks - Engine temperature mechanic that would encourage to use boost - Multiple weapons that can be bought in shop

https://www.youtube.com/watch?v=5u9X54PuhiI

So, while working on this game, I did many things right... And much more wrong. I guess it will be much more interesting to read about my failures, so here they are: - I overscoped. Not nearly as much as in previous Ludum Dares, yet still I did. This is the reason game has lack of sounds (no menu sounds, music loop is way too short, no shop sfx e.t.c) - Made few bugs. Like armor being almost useless due to bad gamedesign (basically all enemies deal 1-2 damage, and it is integer, so it isn't really reduced). Room shrinking to negative size. Money and enemies spawning over the walls. - Too heavily relied on my inspiration - "Brotato". Money and enemy designs are very close and it is obvious. I should have picked more references for that. - Made boost mechanic almost useless. It should have had some more usecases, rather than just increasing player's speed. Probably it should've allowed player to crush enemies?

You can play and rate Hoverspace here: https://ldjam.com/events/ludum-dare/54/hoverspace

Have you ever seen pseudo-3D pixel art games? There are multiple methods to achieve this effect, but I will cover only one of them - sprite stacking.

So what is sprite stacking?

Sprite stacking is a technique based on rendering voxel model as many horizontal slices placed on top of each other. This method allows us to easily render big voxel models using traditional rendering methods.

:rocket: Let's look at pros and cons of sprite stacking! Pros: - Looks aesthetically pleasing - Pretty easy to make it working - Kinda does not have an alternative Cons: - Most naive implementation is slow - Realtime version may require multiple optimizations

So, how can we accomplish that? Let's start with creating voxel model:

This is the model I created for my game - Hoverspace

Btw, you can play it here: https://ldjam.com/events/ludum-dare/54/hoverspace

I created this model in MagicaVoxel. Image above is rendered with magica's renderer. In order to use this in game, I had to export it as slices:

After that, I had to do just one thing - actual sprite stack renderer.

Foremost we need to construct mesh, that we are going to render:

All these buffers are assigned only to one mesh. It allows us to render all stack just in one draw call! Next, we should define actual rendering logic. In the most simplistic case, we would just set mesh filter or render stack using Graphics.DrawMesh and call it a day.

We are not going to do this. It's just too easy ;)

My approach is slightly more complicated. Here's my algorithm: - In update, check if object rotation has changed. - If it did - render mesh onto render texture. If needed - apply outline shader. - Then draw render texture onto the screen in the correct place.

This allows us to avoid rendering whole mesh each frame, by replacing it with just one quad! Also, this method gives us possibility to apply some effects on top of the texture. In my example, it is outline.

This is how I render mesh onto render texture:

If you are interested in render texture utilities like ones used here, here you are: https://github.com/nothke/unity-utils/blob/master/Runtime/RTUtils.cs

Figuring render texture size is done with lots of math. And due to the fact that my approach is not optimal I'll leave this as an excercise for you :smirk:

Though, this method may help you in your journey. It calculates screen space AABB that can be used for setting RT size:

Rendering render texture on screen is straightforward.

This algorithm was used in my game - Hoverspace. I would really appreciate if you check it out! https://ldjam.com/events/ludum-dare/54/hoverspace