DooM fangame: Progress Report #2 - Nuts and Bolts

Someone has posted a comment complaining that I don't do updates!

Such a remarkable event must be rewarded with an update! :P

TL;DR - Been working on under-the-hood stuff, so no screenies yet.

More in detail, I've been working a lot on all the underlying systems, updating a lot of the old code, as well as discarding a lot of the bloated mess I had first developed and replacing it with new bloated messes.

To summarize:
  • Window Management: I've redesigned the window management to work under LWJGL3, and along the way I've streamlined a lot of the design. The old window management code was extremely convoluted - I had dissected the basic Java structures to personally handle everything, from window properties to the drawing canvas to even the clickable area, it was a miracle that it ever worked - I have now encapsulated it properly and given up on tearing everything open.
  • Geometry Math: I have reworked my math.geometry library with a new philosophy - To define basic operations in a static low-level form. This means that, for example, the code to calculate the intersection between two lines, will be defined as a static function (that is, state free, not depending on any object instance) using only primitive types (if possible).
    The idea is to have more complex classes always refer to these basic calculations, so when corrections or improvements need to be made, there's no clutter from class-specific mumbo-jumbo in the way.
    This library is at the core of pretty much everything in the game, particularly collision detection. The older version worked properly, as seen in older posts where I show screenshots of lines intersecting stuff, but this version will, hopefully, be easier to maintain and upgrade.
  • Input Management: I've implemented a pretty elegant (if I may say so) input handling architecture, that can manage Keyboard, Mouse and Joystick (joysticks, gamepads, etc...) input on a specific window, in a very accessible way.
    It is pretty extensible, which I hope will prove useful in future projects if I try to use more esoteric input devices, like a wiimote or a guitar controller... Or VR!
  • Input Binding: Now this should be part of the previous entry, but since it is a major pet peeve of mine, I want to brag about it. Normally, people just hardcode the input handling, and that, quite often, results in games where you are bound to an specific configuration.
    I've hated this with the fury of a thousand burning suns since I ever began playing games, so I've developed system to register input bindings, independent of the actual input handlers.
    How this works is simple, a binding is created with a unique Id, and bound to an input. Say, for example, we create a binding as follows:

       Binding: 0
       Id: JUMP
       BoundTo: JOYSTICK_0,BUTTON_0

    This means that, anywhere on the program, I can just ask what the value of "JUMP" is, and not have to worry about what input handler or button value it matches. I can even have this:

       Binding: 0
       Id: JUMP
       BoundTo: JOYSTICK_0,BUTTON_0

       Binding: 1
       Id: JUMP

    Thus allowing multiple keys to be bound to the same action.
    The idea is to allow these bindings to be configured by the user, and then saved to a config file, as decently programmed games do.

So, enough bragging about stuff no one will even notice during the game! (Ah, the programmer's curse).

Next up is asset loading, which means I have to finish up the test sprites and tilesets! And that means screenshots!

No comments:

Post a comment