The game finally reached a point where is fun to play and works nicely overall.

At this moment is playable so I’ll be compiling a web version soon, after I added some more niceties to make it easier to understand for people, so it can be play-tested by anyone. Is still far of having all the features I want to integrate in the final prototype, also has had zero time invested in design for the moment, but I’m focusing on making the core game and mechanics fun and playable before everything else.

What’s new?

• Added pause menu when ESC key is pressed with Resume/Menu/Quit options.
• Added a starting workable menu when the game is launched.
• Integrated scrolling combat text for damage, power ups, etc, ..
• Fixed the “static laser” on enemy-type-2 , and now hurts the Player.
• Fixed speed so the game is more dynamic.
• Fixed UI elements, still prototype UI but clearer elements.

Next week:

I’d like to focus either in adding little additional mechanics (for example score system, unlock weapons, unlock skills, achievements system, game over mechanic, difficulty increase algorithm…) or in designing a procedural level generator.

Pros and cons about the new procedural level generator? At the moment the game uses random instances of walls, enemies and items, and drops it into a predefined squared room, the player uses portals to move between levels, which are the same predefined squared room where all game objects (except the player) are destroyed and re-instantiated in new random positions, which make it seems like a new level.

The idea would be to create a mixed system where there’s a board that acts as a virtual placeholder,  which is composed by n units of the current predefined squared room, there should be always 1 entrance, 1 exit and 1 unlocked path to connect both rooms, the rest of the squared rooms would be accessible if the player wishes to, either via an open path or a blocked one that can be opened/destroyed. Then on each room a semi-random template would be applied, with certain slots for each instantiation of either items, enemies or other stuff.

This would greatly improve the length and the variability of the game, but also means changing the core system on how levels are generated at the moment and would stop this project from being a simple first project and mutate into something more complex, increasing its scope, which I’m still not sure if I want to tackle for my first project, as the idea is to build and ship something as soon as possible, so I’ll have to do a pro and cons list and decide before moving into adding further developing time.

Make a toy. Start with game play. Not flashy looks or an over-arching concept built in layers. First build something whose mechanics you can play with, and so from the beginning we can see a game we want to play.

If you’re making a game, build a toy first. Jumping on enemies, bouncing a ball into a circle, matching pictures, pulling back and throwing something and seeing how far it goes, swinging from a rope–whatever it is, build that thing first. If your toy is fun, you can add style to it. If it’s not fun, you can fix it and make it fun, or abandon the idea and move on, without having spent much effort on the non-foundational stuff.

Remember you’re building a game. Step one isn’t designing beautiful sprites. It’s building little ugly things you can play with. You know, a game.

— A random redditor from /r/gamedev.

So most likely will go with the same random level generator that currently I have implemented but adding narrative nodes, in a sense that when the player reaches specific levels, randomness disappears in favor of scripted scenarios, and back to random generation once this scenario has been completed.