💾 Archived View for risingthumb.xyz › Old › 2020 › quiver0.2.gmi captured on 2024-02-05 at 09:48:56. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-12-03)
-=-=-=-=-=-=-
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.