miniDooM: And There was Motion (and Polygons!)

So I finally decided to stop stalling and got around to installing and using some screencast capture software on Ubuntu. Here's the result:

Now for the analysis:


miniDooM: Intersecting...

Will you look at that? Turns out the largely untested intersection-detection code I had written is actually working! Must be my birthday...

Yes, that red line is the green Doomie "shooting", and yes, that square is indeed rotating and the intersections update properly... I really need to get on to recording animated gifs of these updates...

miniDooM: More Polygons

So I fixed the issue with the edges not rotating properly. The problem was... that I wasn't using the proper method (of the ones I programmed myself), so yeah, a bit silly, but, on the bright side, I got to test that other method too!

I've also realized why the polygons kept growing as I added more sides, and, again, it was a case of the algorithm working properly and me not using it correctly.

The thing is that, in order to create regular polygons, I would calculate the radius (distance from the center to a vertex) based on the side length, the formula being:

radius = sideLength / ( 2 * Sin ( 180 / numberOfSides ) )

Which means that, for a constant side length (as was the case in my tests), the radius will change as the number of sides changes.

So I've added a method that accepts a fixed polygon radius rather than side length, and here's the result:

For those who care to know:

Polygon2d( Point2d center, double radius, int edgeCount )

Oh, and yes, they are all rotating.

Incidentally, I need to rework that hexagon grid floor, it pops way too much for a floor texture.


miniDooM: A Wild Triangle Has Appeared!

I really shouldn't try Pokemon jokes, I've never really played the games...

In any case, here's a tiny little update:

What are you seeing here? Well, let's see:


Developer Shame

Figures. I add a countdown clock, and then proceed to totally miss every single deadline.

I must admit the lack of updates has been more of a shame-based vicious circle than anything else.

Essentially, I felt ashamed for not having a project update ready, and decided to keep pushing forward, but felt ashamed for not having posted blog updates, and thus would not update the blog until I had a software update...

In any case, beyond real-life issues that no one reading this really cares about, the major problem has been technical issues with the Java libraries. As follows...


Blog Design: Behold! Scripting!

So I've finally managed to insert some scripting into the Blogger template.

Namely, I've added a countdown timer to the Projects page, to indicate the time left to the next milestone. Here's an example of two timers pointing to two different times in the distant future:

Right now it is in a very primitive state. I intend to polish it, and possibly add it as a gadget on the main navigation pane or something.

Credit where it's due, the template is based off of the excellent templates found at Dynamic Drive. Go take a look!


I really suck at setting up schedules...

Question: What does usually happen during the summer that tends to mess up development schedules?

Yes, I've been vacationing this August, thus devoting zero time to development.

On one hand, it is good to take a break from time to time. On the other, I should've thought about it before setting an August 31st deadline.

So yes, I am pushing the dates back again.


miniDooM: Missed Deadline (Figures)

I've failed to meet the first deadline I had set up for myself:
  • July 31st 2013It's Alive!  MISSED

    Status of proposed goals:
    • Controllable Doomie: Doomie sprite plus movement and control implemented. Collisions not implemented.
    • Basic Map: Not implemented.
    • Basic Corpsie: Not Implemented.

The main reason for the delay, apart from my work schedule being lousy, has been my decision to split the code relating to geometry calculations into an independent library, which has resulted in a lot of effort being dedicated into making the library somewhat consistent and flexible, as I've recognized a series of future needs it will fulfil (Originally the calculations were only meant to handle the structure of the game map, but I've realized I can use them for pretty much every game object... If made properly flexible).

As such, I'll shift the deadline dates one month forward.

On the plus side, the deadline is working, as meeting it has been in my mind constantly. Since the goal was to avoid putting the project in the back of my mind and forgetting about it for long periods of time, I'd say it's been successful in that regard!


... and the Inevitable Conclusion...

After more development, I've finally decided to split the math-related code out of the project into specific libraries:

Not only is this more convenient when reusing them, but the important reason right now is to keep code organized, and, truth be told, the package where I was developing these classes was growing out of control (it originally was a lowly "utils" package... How it has grown!).

The split doesn't just include geometry related code, but I've also split general math-related utilities code into it's own library, as well as fast-math implementations of certain operations.

Now, onwards to refactoring many of the structures, because I've realized the current naming scheme is a mess, and not too representative of the real object implemented.

On a happier note, being able to properly split things like this, somewhat cleanly I might add, really bodes well for the long-term, specially for my goal of having decent modularity!

And now, the hard question... Will I be able to get the Doomie running again soon? Will it be chased by angry polyhedra? Mystery! Intrigue! Pass...ably interesting.


The Wonders of Re-Inventing the Wheel

So I've been working into meeting my next deadline. My usual methodology is to focus on the next piece of code that needs to work, and take it from there... That methodology takes me to strange places.

It first began while perfecting the collision system for the game. I realized the collision calculations could be generalized into a 2d vector class. Which I implemented. But then realized I could split the location information into it's own 2d point class which handled the related distance/location based calculations. And then I though "why don't I take all those mathy calculations and move them to a static library so I can tweak them outside the class implementations". Which in turn lead me to organizing all those static methods into appropriate namespaces...

Suddenly I though "Hey! I'm losing focus!" so I went back to finalizing the collision system. And realized I needed to also check collisions with rectangular areas. But as I worked on the simple formulas, it turned out I needed also to be able to rotate said areas. So they were split into Bounding Boxes and Rectangles. And as I worked on the Rectangle I realized they were, in essence, and specific case of a Polygon, so the whole class was renamed Polygon and a new class inheriting from that one with a limited number of edges was created...

And then I pulled back, realized I had skipped dinner in my excitement, and was too late in the night to cook without bothering my neighbours.

So, in conclusion, I might end up creating my own 2d polygon library.

This, I think, is a good thing. I was considering using an existing library (straigthedge) that provides most of the functionality I need, but as I'm still learning many of the concepts involved, doing it myself, even if badly, is really helping me grasp many notions, which can only help when eventually resorting to using third party libraries.

So I'm mostly venting because despite churning out lots of code, the game is still at roughly the same point it was before, only with a more solid foundation.


miniDooM: First Deadline

I know I work better with a deadline so I don't just procrastinate. Here's to doing that very same thing with the DooM-4k miniDooM project.

For this summer, I am setting a monthly deadline, with the following milestones to be reached by the set date:

  • July 31st 2013: It's Alive!

    This first build should include the following elements:
    • Controllable Doomie: The Doomie should move properly, collisions and all.
    • Basic Map: A basic map should load, with support for multiple sectors and proper transitions/collisions. Different sectors should support different tilesets.
    • Basic Corpsie: A number of Corpsies should spawn around the map, and they should move towards the Doomie when they see it.

  • August 31st 2013They are NOT!

    Second build, with the following features included:
    • Basic Weapons: Ability to pick up and shoot weapons at Corpsies.
    • Basic Multi-Sector Pathfinding: Corpsies should move from sector to sector trying to chase the player even if they don't see it.
    • Basic Lighting: First iteration of the actual polygon-based lighting system.

  • September 30th 2013And Here We Are!

    Third build, including a single very troublesome feature:
    • Basic Multiplayer: Two networked clients should be able to link up, with each one controlling a different Doomie. Should also support local multiplayer.

Hopefully this schedule won't be.... too hopeful. With some luck I might be able to finish some of the elements for the following build in a previous build, resulting in some revision of the schedule.

Now it would be great if I managed to update the projects page to include this information... Need to work on the layout for that one.

Update: Consider this whole deadline thing to be a complete failure. I think I'll get back to the deadline system once I've completed the basic engine work and what's left is content creation and fine-tuning.


Real Life Attacks II: Return of the Finals

This is the type of post I hate most doing, essentially a poor excuse for my lack of updates.

Anyway, had exams, had stressful workload at work, and had to play Bioshock.

I still have to play though Bioshock, though, but I now have time to resume game development.

And I don't mean Bioshock: Infinite, I mean the first one. Have never played it before, I'm loving it so far, and since I rarely play current games, I'll probably won't touch Infinite in a long time.


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.


miniDooM: There is a reason working titles exist as a concept...

... and that reason is that coming up with a decent title for a project is neutronium-level hard.

I personally don't like the DooM4k title for a series of reasons, chief among them being:

  • It is an unispired title
  • It is not a Java 4k game
  • It might get the project confused with the (hopefully) upcoming DooM 4
  • It is very uninspired
  • Feels like I'm trying to ride on the coat-tails of the DooM franchise, instead of making a homage.
  • Did I mention uninspired?
  • There is no BFG4k planned

The confusion with the still in development hell DooM 4 has me specially worried, as it might attract the attention of zealous lawyers seeing me as a threat to their IP.

So I'm looking for other options. I'd set up a poll, but I don't have either the audience or the confidence in said audience not choosing the worst possible option just for laughs.

My current runners up are the following silly plays on the title:

  • DooM-Dee-DooM
  • (Big) Ba-da-DooM
  • DooMieS
  • Bah-DooM-Tish

Ok, I'm only serious about one of those. Let me have my fun.

Update (2014-01-30): And the winner has been.... None of them! The project is now called miniDooM. The observant might have noticed I've taken the time to correct all blog posts. Yay for tedious work!


Recently, in my quest for cutting corners inspiration, I came across an interesting project with similarities to mine:

Apart from being a kickass roguelike, this project is similar to mine not only in theme, but also in some general gameplay aspects, such as:

  • Top-Down perspective.
  • Line-of-Sight mechanic.
  • Procedurally-Generated maps.
The big differences would be in my project being real-time and meant to be played as a Cooperative game, as opposed to the single-player turn-based focus of DooMRL.

Another important similarity is that both projects make use of their own assets (images, audio, map layouts) rather than using the originals, thus giving each their own personality.

DooMRL, in fact, even has a "pure" roguelike mode with ascii-art!

So I guess what I'm saying is that, if you like both Roguelikes and DooM, you owe it to yourself to check this game out!


Moving Never Ends


Since the end of January I have been subjected to the horrors of moving to a new place, including all the rent-the-place-and-fix-all-the-things tango.

Right now I'm still unpacking stuff and setting up furniture, which means my workstation is sitting in between a few boxes, possibly cowering in fear.

Will I ever finish the move? Will I get back on track with development? Will I get a new sofa?

Find out, next time! Or not...

From Wandering Bohemian Photography


Projects Page is Up and... not exactly running...

The first draft of the Projects page is up. It is meant to list my projects, their current status and info on them.

For the time being, it's just a plain old table with colorful icons. I need to wrestle Blogger into allowing me to do the tricks I want to do for it, but for now, at least I get to put up the icons.


Crawling Back from Oblivion...

No, I haven't been playing The Elder Scrolls IV: Oblivion... Been playing Morrowind.

Just kidding, I've actually been buried under a lot of things to do, mostly studying, which is rather sad, seeing as how I'm having less free time during the holidays.

Anyway, DooM4k miniDooM has been on a hiatus while I looked into other stuff (Mostly stuffing myself at all the holiday dinners I had to attend).

I've been tinkering around with a few things, though, refactoring some code and experimenting with basic algorithms (Sprites, lots of array management, and some combinatorics).

The big letdown, for me, has been the Indie Speed Run, mostly because I signed up, but have been unable to participate. A shame. Hope they run it again next year. I'm also looking forward to the results, so I can feel as a talent-less hack when compared to other people's entries.

This month I'll still be busy with academic stuff, but hopefully I'll get back on track come February... Wait, I'm supposed to move to a new place around then. Oh boy.