Quiver/Hellaglitch Version 0.2
Firstly, the name of the game has changed from Hellaglitch to Quiver. I elaborate later on why.
Quiver version 0.2 is out, featuring a railgun, shotgun, networked multiplayer deathmatching, and a deathmatch map, among other numerous improvements, including sound effects.
=> Check out the demonstration video!The name of the game has changed from Hellaglitch to Quiver as it is a shorter name, a more memorable name, a more fitting name, and as for name collisions with other media, only collides with an obscure DOS game that is a DOOM(1993) clone to my knowledge.
Next week I intend to begin work on my worst aspect of any game development, namely "marketing". Of this, I intend to set up an itch.io page, work on small development log videos demonstrating and explaining different effects to have educational value, and set up a mail list. As for game content, next week I will work on adding the 4th weapon, the Rifle, adjust the zombies to leap at the player, and time-willing, create a new AI capable of shooting at the player. The latter shouldn't be too difficult as a result of my data-oriented programming method.
This week's plan file is listed below.
Sometimes you have a week where you try to solve a complex design and implementation problem, and you realise exactly why the current standards for this is what they are. Namely the design problem of a seamless multi-floor top-down level. The current approach I see used a lot is to split it up into multiple levels which isn't seamless, but solves a lot of problems, and allows level developers not to work within the constraints of the world(this brings issues for networking, hence why I don't use it). Another solution is teleportation, which would in theory work, but would be very jarring and probably liable to be buggy. I suspect this is just a core problem of top-down games. Games such as Hyper Light Drifter and Hotline Miami solve this exactly in the ways I just listed. As for implementation issues which are more technical, one has to consider collisions, lighting and rendering on all layers- and since this will feature multiplayer deathmatch, how to consider, but also the graphical "pop-in" from handling multiple layers. I suppose an explanation of my solution may be in order. All notable entities which will change layers have a layer variable. When they collide with a height trigger, that layer changes to what the height trigger is set to. The game will render and handle player collisions for all things on the current player's layer, the layer above and the layer below. This range of 3 instead of 1 is to prevent things getting stuck inside of each other when passing through a height trigger. You would also need to consider any baked lights that have to bake their lights prior to gameplay, as well as how players interact with items and enemies, as well as spawning mechanics for layers. In short, it's possible but my cost-benefit analysis of this problem suggests it is not a problem worth working on. It is effectively a feature creep at this point. This level design space is also sufficiently well explored within 3D games. I have left my solution within my code in case I choose to explore this problem at a later date. * Proper addition of a layering system with heights and render layers. Means we can add triggers to change layers and render only relevant layers * Layering system created with proper adjustment for the light baking. It recalculates all lights when layer changes * Layering trigger. Can now switch floors * Instead of lots of sprites, now just render a repeat texture in a polygon. Texture alignment is still important here though * Redid the main menu. No longer looks terrible * Added volume slider * Added proper sound effect system for sounds that are created in the world on the fly * Extended volume slider to also handle music and sound effects * Main menu title graphic * Added shotgun and shotgun ammo * Created deathmatch map * Added sound effects for railgun, pistol, shotgun when firing + Now only use 1 Light2D ever. Should probably use the profiler to see how costly this is, since I'm aware Light2Ds in Godot bring with them a performance cost. + Massive optimization of all walls. No longer constantly calculating distance to player + Lighting animation effect fixed. Light animations are now possible without lag + Lighting no longer recalcuates all lights when layer changes. Instead it generates and saves its baked light and only renders when allowed. + Fixed bakedlights using occluders + Discovered a massively easier and more efficient method for handling floors by repeating textures within a 2D polygon. Massive reduction in nodes, still compatible with using sprites + Clear inventory on death multiplayer Lore Terminal without an existing file will crash. Singleplayer Death Statistics Refactor all code to align with my code style standard Teleporter render layer inocrrect