miniDooM: Logging the Log

Not every week can have the same level of awful-video-ness, it seems.

Currently I'm working on the logging system, an often overlooked part of software development that, in the long run, is essential.

So yeah, not terribly exciting news.

On the other hand, after playing DooM3 BFG Edition, I've come to realize I prefer the old flashlight.

Those of you who know what I'm talking about probably hate me now.


miniDooM: Exciting Experiment!

This (long) weekend has been a journey of discovery! Not only have I learned a lot about how the Java graphics pipeline works, I've polished some elements of the program structure and come up with a few techniques I'll probably use in the final code.

And, I've also discovered a pretty nifty screen capture program in Ubuntu. Behold!

Explaining the video in 3, 2, 1...


miniDooM: Who said there was nothing to show?

Behold! An actual screen capture of the work in progress! I'm so proud.

Now, there will probably some amount of head-scratching going on, so let me explain.


miniDooM: On System-Agnosticism

Another week(+) gone by, and still no sexy screenshots to show. That is the hardest part of the process I call "software condensation" (when the project is transitioning from vaporware to an actual piece of software), a lot of work is going on, but there is little to show for it.

Anyway, therapeutic as it might be, ranting won't get stuff done.

The Display Manager is coming along nicely, in fact, being able now to display and handle windows, change to full screen, manage screen resolutions, etc...

The part I'm having some fun with ("fun" pronounced as "hysteria-inducing difficulty") is the attempts at making the software System Agnostic.

What does this mean? Essentially that all calls to the underlying system (Java's libraries in this case) have to be neatly packed away in a corner of the code, so when the whole thing is ported to, say, C++, I don't need to go around figuring out how to re-implement methods, classes and attributes.

So far, the encapsulation is working nicely, the System namespace where I'm dumping all system-dependent elements is shaping up to be a decent template for multi-platform development, and I'm really glad I decided to focus first on this part, or else having to "rewire" everything else to meet the new specifications would've been a nightmare.

So, to recap, this is what I have currently completed:


miniDooM: Sexy Screen Management

So, save some final polishing, seems like I finally have a satisfactory screen manager, one that handles switching between full-screen and window mode smoothly, manages different display devices and compatible screen modes, and even makes coffee!

Ok, I might have exaggerated a bit on that last one.

For those who don't know, I'm somewhat obsessive-compulsive when it comes to base class development. I want a program's infrastructure to be elegant and robust enough to allow for both easy maintenance and future modification... Which of course means I tend to be rubbish with deadlines.

Now the next step is to finalize the input management classes (Keyboard, Mouse and Gamepad), and then I will be ready to throw some sprites into the mix and try to have something move along the screen.

On other news, I'm considering using an actual normal mapping on the game's sprites to get a more flexible lighting solution. The trouble would be to keep the cel-shading style I'm aiming for, and keep processor load down too.

Well, I guess I'll see once I have a running interactive system and start experimenting with the rendering.


Real Life Attacks Again!

Oh, for the love of...

Yes, it's been a few weeks I haven't updated this. Truth be told, this time the Real-Life Attack  has been intensive... As in actual illness. Plus helping a friend move. Plus rain, lots of rain... Which shouldn't affect my programming schedule, but you know how it is, all that sweet rain out there, and everyone wants to stay indoors... Feeling forced to stay home really upsets me.


Humbled by '93 technology

Recently I've been poking around ports of the original DooM engine. I could say that it was research for my project, but that's be a lie, I actually found an online video about a modification that caught my attention, and looked into it.

Luckily for me, it has resulted in a whole lot of inspiration for the DooM4k miniDooM project, so yes, I am totally going to rationalize it that way.

First things first, the video that caught my attention was this one (Warning: gore and possible profanity):

That is the aptly named Brütal DooM mod.


Real Life Attacks!

Been a bit busy lately and missed last week's update. I should make sure to at least add a news update like this one.

Regarding the project, I've had to redo the Graphics System superstructure due to a couple basic design flaws that brought the whole thing down. Good thing, though, as the new version is coming up much more streamlined.

I've also been playing Poacher, by Ben 'Yahtzee' Croshaw. I didn't think I would like it, but I do like the game a lot, I find it very inspirational.

Oh, and I hurt my hand using a gamepad. Hadn't used one in quite a while. I'd better harden up, or the playtesting will kill me.


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.