2017/09/25

DooM fangame: Progress Report #8 - Time Bonus and Redesign


Ok, so I've added an extra month to the counter. Why? Because this last month I've been both very busy at work, and have had a nasty cold that kept me away from working on the project.



Now, I also decided a while back to cut down on some of the intended features for the first playable release.

On my original countdown post, I committed myself to finishing the entire game, which was very unrealistic in retrospect, so for the first deadline I'm shifting my focus to having something that is playable, with the bare essentials.

I'm expecting to pick up the pace once all the basic elements are in (easier to add monster variety, for example, when the basic monster framework has been coded in).

The features I expect for the first release are, fittingly, very similar to Notch's Lef4KDead mini game (sorry, no link, it was originally hosted at Mojang's site, but it is gone now), which means the following:



  • Goal: Player must reach the map exit.
  • Enemies: Just zombies, with the occasional swarm rush.
  • Weapons: Infinite ammo one-shot-per-click sidearm (Pistol) and ammo dependent longarm (Shotgun) with specific fire rate.
  • Items: Randomly spawned medkits and ammo packs.
  • Progression: The more levels the player beats, the larger the maps, and the more frequent the zombie spawns.

One thing I won't be doing yet is lighting, but on the other hand the procedural map generation is already built! I based my code on future data lab's procedural dungeon generator, with tweaks specific to my needs, but so far it's mostly their code, so go visit them!


So, if the cold and associated real headaches subside, I'll soon have some screenies of the map generation process!

2017/09/21

DooM fangame: Progress Report #7 - Tile-Based Headaches

So it's been a while since I last updated, and, sadly, I got no screenies today.

I'm working on the map rendering code, having to rework a lot of it to make it function properly.

The main issue has been using bitmasks to map situations where an individual tile has different types of neighboring tiles, like say, a floor tile sitting between a chasm and a wall.

After much headache and lots and lots of calculations, I had a revelation: What if I split my 32x32 tiles into four 16x16 tiles? That way they'll be guaranteed to only have, at most, two different types of neighboring tiles!

One of the many pages...

I, of course, immediately slapped myself after that epiphany, because that's a very common technique I should've been using since the beginning instead of my usual trying to re-invent the wheel.


That settled, I also decided to turn the rendering process on its head, as, in those screenies in previous posts, what I'm doing is calculating the bitmasks for rendering each frame, for each tile, which made locating the points where the calculations were failing quite a hassle.

Now I've reworked it so I pre-generate a map with the actual texture indices for the tiles at map load, so there are no calculations done during rendering.

Currently, I'm having difficulty defining a proper syntax for the  tile mappings (that is, the definition of which part of the texture to use based on the surrounding tiles), given that I have to consider different tile types, plus some exceptions.

But I feel like I can give it all a good push this weekend. We'll see.


2017/09/12

DooM fangame: Progress Report #6 - Tileset Bitmasking

So I've managed to get tileset bitmasking working, with some literal corner cases:




The way I handle corners, is to draw them over the base tile when needed, so I don't have to use a massive tile sheet with all the possibilities drawn in.

Something is amiss when drawing specific cases, I have to find out why. In any case, it' is looking good to me, and soon collisions will be implemented!

2017/09/07

DooM fangame: Progress Report #5 - Tilesets

Seems like my guess that I'd start speeding up and posting more screenshots was correct. Hope I keep it up.

Anyways, here's today new incremental step towards greatness:


The Caco moving is not really important here, but rather the tilemap, as it is being generated dynamically from an arbitrary data set, more precisely this data set:

0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,1,1,0,
0,0,1,1,1,1,0,1,1,0,
0,0,1,1,1,1,0,0,0,0,
0,0,1,0,1,1,1,1,1,0,
0,0,1,1,1,1,1,1,1,0,
0,0,0,1,1,0,0,0,0,0,
0,1,1,1,1,1,1,1,0,0,
0,1,1,1,1,1,1,1,1,0,
0,0,0,0,0,0,0,0,0,0 

Next step is to do some bitmasking magic so tiles are rendered based on their adjacent tiles, so it looks a bit less flat.

And then, after some housekeeping (lots of temporary code floating around right now) it'll be collision time.

2017/09/05

DooM fangame: Progress Report #4 - Spritesheets

Aaaaaaand..... Spritesheets!


So here we have me fiddling with the keyboard so our friendly Cacodemon looks around. That sprite is still a work in progress, but looks quite well, I think, really looking forward to finishing it.

Unfortunately there are a lot of flaws in this implementation, mostly regarding how I handle texture coordinates, but I expect to iron them out quickly.

Next stop, tilemaps!

2017/09/04

DooM fangame: Progress Report #3 - Rendering at last!

Behold! A screenshot!



Yes, I know, it looks like the preview of the cover art I posted a while back, but it is actually being rendered in-game.

I've finally managed to crack rendering in LWJGL3!

I'm really hoping things will speed up now as I finally can see more than just log messages.

I had been postponing creating content (drawing sprites and tilesets) until I could put them in game, since that's a pretty time-consuming task and would've been all for naught had I ran out of time.

Now, having a working framework? Even if I don't make the deadline, I will certainly have something to reuse for my next project.

Onwards!

2017/08/30

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.