miniDooM: Hopping Sectors, Part 2

And we're back!

Intent on fulfilling my threats promises, here is an animated .gif showing some more progress. Details after the break.


miniDooM: Hopping Sectors

What's this? Another update? So soon?! This is madness!

Things on display:

  • The Doomie now has legs! And animated to boot! It's rather cute to see it hop merrily around.
  • The red lines are the collision lines of the underlying sector system. For now it's just a visual representation, more on the sector system later on.

I should look into making animated .gifs to show off progress without having to upload video.

I'm also going back and forth regarding the title of the game. Guess I'll make up my mind when I finally draw the splash-screen / logo.


miniDooM: There Be Tiles!

Most of the progress I've been making lately is still "under the hood", and hard to demonstrate in a screenshot, but at least a few things can be showcased:

So, new stuff what can be seen here?

  • Tile Map: A prototype of the Tile Map system. Underneath, the map is defined as a binary empty/full grid, and the system automatically assigns the tiles based on the nearby neighbors.
  • Layering: The animated white noise background is drawn under the map, and seen through the empty spaces. That will eventually become a background.
  • Directional Sprite: Hardly noticeable, but the Doomie helmet is facing south-west, and will turn to face the movement direction.
What can not be seen?
  • Frame-Independent Movement: Movement of the Doomie helmet does not depend on draw speed, which does not seem like a big deal, but it is the foundation of a computer-speed independent implementation of the engine, something anyone who plays old games in new hardware knows is vital.
  • Encapsulation: This is what I've been focusing on, moving each element (game logic, graphics rendering, user input) into its proper package, and making them interact with each other.
    The final result is shaping into a plug-and-play architecture where I can swap modules around as needed.
    That is actually my main goal here, to have the ability to add different modules with different gameplay logic, or rendering algorithms, and thus be able to quickly compose different games.

So there, an actual update. I'm still thinking about how to rename the whole project. I'm also spending a lot of time with normal-based lighting I might never use, but I'm learning lots!


Refactoring and You

So lately I've been suffering a severe case of coding-burnout back at work, which has delayed game development.

To relax myself, I've taken to doing something I quite enjoy, and find quite fun sometimes: Code Refactoring!

Namely, I take someone else's source code, and delve into it, re-organizing to fit my tastes, and learning new tricks along the way.

I find it is an interesting way to learn, as well as a zen-like relaxation exercise.

I usually look at the source code from entries into the Java4k competition, mostly because, needing to be as compact as possible, the code often lacks comments or a coherent structure, which forces me to actually understand what it does while refactoring.

As I've said before, the DooM4k miniDooM project came about as I refactored Notch's Left4kDead source. Good times.

As for the DooM4k miniDooM's status? I should make a post on normal-based dynamic lighting and why Java2d hates me.