miniDooM: Self-Imposed Control Limitations

I had a big post planned regarding the benefits of self-imposed limitations, but I think I'll just let this speak for itself.

This is the control input I'm designing DooM4k miniDooM for:

Yes, it is USB. Yes, it is awesome. Yes, I'm serious.

P.S. If you're interested, it's a Tomee NES Usb Controller.


Going Native...

So, I've stumbled upon a slight problem while implementing my game's infrastructure, namely a lack of features in Java's standard implementation.

Looking for ways to solve the specific issue (related to detecting if the display has been rotated) I ended up delving into native interfaces.

Also, I've been looking into the JInput library in order to add gamepad support, and I'm also looking into how these libraries interface with the underlying system.

Java Native Interface (JNI) is probably something that will have most Java programmers running in a fit of terror, and I see why, but I'm rather intrigued by the possibilities, mostly because given my long-term portability goals (Moving the codebase to C++), understanding how the JVM communicates with the underlying system is crucial.

Also, I'm acquiring this habit of taking exiting pre-defined Java structures and stripping them of anything I don't really need, and will possibly end up doing this very same thing with native interfaces, if only to learn more, and have fun along the way.

As far as actual development goes, I'm mostly coding away at the infrastructure for screen and input management, so there isn't much to show for my work. Once this step is done, I should be able to take any Java game and, with minimal tinkering, plug it into my system.


miniDooM: Mocking It Up

It is tempting to dive straight into coding rules and mechanics for a game, but the value of prototyping is often understated.

Now, in order to make simplistic prototypes, I first need to have the basic engine running, which I still haven't completed. But, luckily, there is a sort of prototype of a prototype: The Mock-Up.

Mock-Ups are just models of the final product, built to simulate ho they'll look in the end. In the case of   games, a mockup is something as simple as firing up an art program and drawing a game screen as it should look up.

Oddly enough, I've been doing mockups ever since I wanted to design games. As a kid I often drew, either by hand or on the computer, fake screenshots of the games I imagined. But only recently have I discovered the real power behind properly executed mockups.

Also, props to the Mockup thread at the TIGSource Forums, which opened my eyes about this.

So, without further ado, here is a first mockup of D4K miniDooM:

miniDooM: Code Foundation

The very first thing I got to do, before I began mucking about with sprites and assets, was set up a basic Java program structure unto which to build the project.

All too often, program development is begun in what I see as the development equivalent of "In medias res", solutions are devised for specific parts of the problem, without consideration for the whole, and thus later need to be stitched together, resulting in a precariously cohesive monstrosity. A Franken-program, we could say.

In Game Development this usually happens because it is very tempting to quickly code the screen rendering routines, the input listeners, and quickly draw something that moves, and move it around.
The the rest is added to this hastily created infrastructure, and before the developer realizes it, the program has developed quirks of such a caliber it is scary to even think about ironing them out.

To avoid this, and because I kind of get off on program architecture, I've devoted the initial week of D4K's miniDooM's development to organizing things. The current architecture might vary, but I'm confident parts can be altered without having too great an impact on the rest of the program.


The miniDooM Project

Time to Log some Devs!

If I were aiming for an epic feeling, I'd start with something like each journey has a fist step, each story has a first chapter, each first chapter has a crummy prequel... But I won't, I'd rather spend my creativity budget cracking silly jokes.

So without further ado, allow me to introduce my first serious Video Game Development Project (drum roll):

The DooM 4k miniDooM Project!

I reserve the right to rename it, though. Also, I've written the words "this is my first game project" so many times already it feels hollow. Here's to this time being different!


Booting Up...

Welcome to the DevLog, a site where I'll pour my thoughts on the development of my personal projects.

Everything on this log will be a work in progress, including the site itself, so don't be surprised if things keep moving around or changing.... or if they don't.

I'm really not completely satisfied with the look of the site yet, but I better start logging, and improve gradually, than lock myself again in the planning stages.

The plan: Weekly updates of whatever project I'm focusing on.