As threatened, here is my first real devlog post.
Work Since Last Devlog
I began a single-screen walking prototype in LÖVE. I’ve been procrastinating on this for a long, long time, so it feels good to actually start doing something productive on this front. Basic collision detection against a hardcoded tilemap of solid cells is implemented. Graphics are limited to rectangles generated with the love.draw library and debug printouts. Sound is not merged in yet. Input is hard-coded to the keyboard.
As little as it is, it’s still more than I had prior to this weekend.
I spent more time organizing notes and sketches that have piled up, and also playing with MilkyTracker and sample generation. Possibly I am using these as ways to procrastinate. I tried to separate my notes by topic, though I’ve yet to really go through them and prioritize what are good ideas and what should be thrown out.
Thoughts
In the fine tradition of the carriage leading the horse, here’s a quick and disorganized grab bag of things that are currently on my mind. I’d like to get more detailed in later devlogs.
Genre
This will be a platformer. I like these kinds of games, or at least a particular kind of them, a lot. My handle is an item from a game that lets you jump, in a genre and perspective that didn’t typically allow it at the time. Even though I’ve been more active with games lately, I haven’t made a platformer myself in ages.
Platformers don’t necessarily require the ability to jump, just that the player has some need to move across different platforms to achieve a goal, and the transition state between platforms typically puts the player at increased risk. Stairs, ladders, rope, grappling hooks, elevators, climbing, bouncing, teleporting, and moving the platforms themselves are all ways to get around, and they often appear as auxiliary travel methods alongside jumping.
Few platformers are built on platforming alone. Enemy characters, puzzles, and stage hazards are often thrown into the mix. Sometimes (or maybe oftentimes) being a platformer is the least notable thing about a game. Rigid definitions aren’t always helpful, and design and execution can be handled in many different ways.
Tone
I’m unsure about the best path to take here. My head says keep it light, but my gut wants to throw in some not-so-light themes. I need to hold off on this until I have more of the core game logic functioning.
Presentation
Visually, austere pixel art with few special effects.
- No parallax scrolling, no programmatic sprite rotation or scaling, no scanline interrupt-style effects, no zooming in or out of the scene.
- No programmatic lighting effects, such as a circular radius of light around a torch, or shadows cast as polygons
- Allow background animation so long as it helps ground the environment
- Camera shaking should be used sparingly, if at all
No dialogue. No written text outside of the menu systems, title screen and credits.
Keep cutscenes to a minimum. When scripted events must occur, try as often as possible to have the player in control during those moments, even if they are forced down a specific path.
I want to play around with scene transitions. For example, slow dissolves between two versions of the same room to show passing of time as the player does something monotonous. But not all the time: it has to be used sparingly. Also, the ability for the camera to briefly follow auxiliary objects of interest, away from the player, without messing up the scene state. Looking forward to testing these thoughts.
Accessibility
I am woefully uninformed on this subject. Issues that spring to mind immediately are the need for captioning audio cues, and ensuring that visual cues are distinguishable for colorblind users. It’s a big and nuanced topic. Need to research.
Diversity of human characters
The human cast can’t be all white, and classes of character can’t all be typecast by gender. Need to think about the protagonist design, what that represents, and maybe include user customization. I’m not very good at this.
Copy Protection, Obfuscation
No. Nothing good comes of this.
Old Hardware Support
Supporting older hardware within a reasonable limit is important to me. LÖVE lists Windows Vista and higher as supported operating systems, and is able to run on some Raspberry Pi models. As long as the game doesn’t try to do too much all at once, it should run on practically any PC in decent shape from the past ten years.
Framerate
For now, I’m just working with the expectation of a 60 Hz monitor, but I know that won’t cut it for a proper release. I’ll want to support variable framerates with delta time as well. The game should be mostly playable at 30 Hz, and partially playable at 15 Hz. Need to ensure that framerate fluctuations don’t break game logic, or desync things that are supposed to move predictably in lockstep.
Resolution and Aspect Ratio
I would normally default to a 4:3 ratio out of familiarity, but I feel the need to make the game in 16:9, as it’s the most common display these days.
I’m considering a couple of 16:9 resolutions that can scale up to 1920×1080: 320×180 and 384×216. The former feels a little too cramped, the latter a little too large. The core game engine needs more work before I can decide on this.
Sound and Music
I feel confident that I can make and record the necessary sounds for this game. For music, I am less confident, but willing to try making some tracker modules, and adapting some existing tracks that I’ve made in the past year for fun.
Plans For Next Week
- Merge in sound and music functions from earlier test projects.
- Add scrolling
- Implement test objects: Randomly spawning fireballs, simple patrol enemy, and a moving platform
(e 20/oct/2018: I’m trying to resist the urge to edit these posts, but I’ve added a screenshot from last week to the top of this post, and will continue to do so in new posts as I go.)
