2017/11/08

Getting an Education: Overdue Edition

Back on ancient times... Or more precisely on May of 2016, I said the following:
As for the original Legend of Zelda, I got it too (classics series for the GBA) but... There's something about it that just doesn't engage me, and after wandering around for a bit I tend to lose interest.
 Oh how young and ignorantnaive I was!

So yeah, I decided to try and play the original Legend of Zelda on my GBA, but this time I armed myself with the proper tool to avoid the reason I never managed to stick with it: A MAP!

Gold Cartridge... Quality!
See, the only real complaint I have about the game (besides some minor nitpicks) is that there's no overworld map, making it hard to track progress and know where you're going.

Now, some might be screeching at me for such heresy, claiming that drawing your own map is part of the fun/challenge... And yes, I get that, I really loved making my own maps back in the day... Unfortunately, when I play these games on my GBA, I tend to be on the go, maybe sitting at a bar, and not in a position to craft my own maps and notes. Also, these games usually had a map included in their manual (I mean, look at the box caption above), which I don't have because I bought the cartridge alone, since GBA boxes and manuals seem to be crafted from unicorn blood and the dreams of pixies seeing how expensive they are (or are collectors items, more probably).

So yeah, I just looked up an overworld map that indicated where everything was, then it turned out the map I got was for the second quest so it still didn't make sense, and when I finally got the proper map... I started to really enjoy the game, both as a player, and as a game designer... That game is pretty tightly designed!

The Second Quest map that had me questioning my sanity
It has its flaws, of course, and feels primitive, but it manages a lot with very little, and I was pretty impressed, which is no mean feat considering I had already played through A Link To The Past and The Minish Cap!

I'm even playing through the second quest mapless!

The great thing is that this game is, perhaps, the closest to what I was trying to do with the DooM fangame (minus all the blood and bullets), so I've decided to adapt my existing design to more closely resembling this game... Starting by forgetting about complex tilesets and just have them work!

Soon (hopefully) I'll post my new design plan, for the time being... It is a secret to everybody!


DooM fangame: Progress Report #8 - Time's up!

To be precise, time was up a week ago, on Halloween.

So... What to do? My stated commitment was to either release something playable or discard the project and work on something else.

But it's so easy to cheat oneself.

Thing is, I know if I start something new I'll probably never see it to completion... And I've gone so far (relatively speaking) with this project.

So I think I'm going to "discard" the parts of the project that were holding me back, and rework it into something different.

What is going out the window?

  • Procedural Generation: Yes, I even have the algorithms set up, and was debugging them, but even with the Proc'Gen code up and running, it would make balancing the game more complex, so I'll shelve it for the time being.
  • Extensibility: This one hurts because it goes against all y instincts, but trying to make everything extensible (future-proof) has been a major burden throughout, I'm going to focus on specific functionality and will look into extending things later on. After all, my next project will probably result in major rewrites anyway.
  • Multi-Level Maps: One of the things making my life miserable was having to design the tile-rendering system to account for several floor levels, much like in the modern Zelda games where you can have different heights in the same room. I'm giving up on that idea for now, it's proving to be much too complex.
What else is changing?

Well, I've been playing a game I should've been playing since the beginning, which has again reminded me of how much you can make with very little, so I've reworked my design to approximate how said game works... And yes, I'm purposefully omitting which game it is.... So I can make my next post about it. It shouldn't be surprising.

Now the important bit.... Do I reset the countdown???

2017/10/23

DooM fangame: Progress Report #7 - Tilehell

I have a tendency to fixate on doing something a certain way, and can get carried away.

In fact, that tendency is why I settled for a fan game, do I didn't get lost in content design.

Well, today I got all my tile masking code and commented it out so much it now looks like a particularly controversial YouTube video.

I've decided to use plain simple tiles so I can have a shot at the Halloween deadline.

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.