Beams of light
Posted On: 2017-03-02
This week's update was delayed due to a sudden onset of seasonal sickness, and I apologize that I had not planned ahead with any content to fill in the ensuing gap. Now that I am confident that I am sufficiently lucid again, I am able to write a bit about the project I was working on before I fell ill.
I have had a few larger game design ideas in my head for a while (I mentioned something of this in an earlier blog post), and I finally decided to start developing some of the pieces that would eventually be required in order to have a playable prototype. While there are a number of different mechanics that all need to interplay together in order to work correctly, I tried to pick the one that would be both difficult and impactful to prototype first, that way I can tell immediately if something is fundamentally wrong or unsalvageable. The mechanic I chose to work on for this project was the "light" or "vision" mechanic, which is controlled using mouse movement:
Please disregard the ugly filler art
The basic idea of this mechanic is that the player can only see a small portion of the total visible area, but certain objects (such as the boundaries of the level or other key objects) are visible regardless of whether or not they are in the vision cone. Originally I attempted to accomplish this using shaders but eventually found that I could accomplish a workable alternative by using some clever camera tricks: everything that is hidden from the main camera is visible to a second one (used z-position and culling to accomplish this), and that second camera projects everything it sees to a texture that is rendered on a simple triangular polygon that is rotated to follow the mouse and visible to the main camera. I am very pleased that it worked out and the approach is flexible and solid enough that I am confident it would serve for use in a prototype.
I am not yet sure which component I will work on next (though, truthfully I will be focusing on feeling better before anything else), but there are a number of candidates I am considering:
- Input filters to modulate impact of input (broadly useful, as this can be used to slow characters in water or lock movement through animations. Tricky to implement correctly, and not actually essential)
- Netcode for simultaneous multiplayer (generally very difficult and huge scope, but I am reasonably confident that my existing skills will allow me to accomplish this, given sufficient time)
- Character movement and animations (broad subject that I could learn on any prototype. May be especially tricky to make readable, given the tiny view the player has)
- Attack particles and hit-boxes (probably not too difficult, I've at least worked a bit with each of these)
- Melee attacks (depends on animations, generally a source of trouble for me in the past)
- Surprises in the dark (probably highly impactful, but difficult to get right without mechanics like movement, death, etc. Will probably open a whole new rabbit-hole of mechanics to explore)
Thank you,
Mark