Devlog 3: Adding EXPLOSIONS, doors and cute aliens

Devlog 3: Adding EXPLOSIONS, doors and cute aliens

As the core of the game engine is slowly settling and becoming a solid base, I started this week with adding some of the extras on-top of it all.

First was adding doors to the level generator. My first solution was fairly simple: When a room starts to generate itself, it picks a template, and based on the amount of exits it has it will generate various corridors leading to the adjacent rooms. So placing doors was as simple as changing the corridor-generation code and place doors for the North and East corridor.. seeing as the South and West corridors always connect to the North and East they don’t need special door code (or else you end up with a double-door).

As simple as it sounds, it all worked and I quickly added the code for the door-entities themselves.  BUT .. and there is always a but.  The important doors need a key! As explained in the video, that’s when the problems begin, because my simple solution wasn’t enough to handle those cases.

By limiting locked-doors to the “1-exit” rooms only (dead-ends in our maze) it does simplify the problem a lot, altho it did need a few extra checks to my simple solution. In the end the code for deciding what type of door goes where ended up looking like this:

if (exitNorth)
{
    for (int x = midX; x < midX + 4; x++)
    {
        for (int y = 0; y < (1+wallTop); y++)
        {
            if (x == midX || x == midX + 3) tileMap[x + (y * World.roomSpaceW)] = World.tUNDESTROYABLE;
            else tileMap[x + (y * World.roomSpaceW)] = World.tEMPTY;
            
            
            // ADD DOOR
            if (doorsAllowed && y==0 && x == midX + 1 && (exitCount==1)) // || WorldGenerator.getMyRandomValue(100)>30))
            {
                if (exitCount==1 && generatedID!=0)
                {
                    tileMap[x + (y * World.roomSpaceW)] = World.tLOCKEDDOOR;
                    hasLockedDoor=true;
                }
                else tileMap[x + (y * World.roomSpaceW)] = World.tDOOR;
            }
        }
    }
}

if (exitWest)
{
    for (int x = 0; x < (1+wallLeft); x++)
    {
        for (int y = midY; y < midY + 4; y++)
        {
            if (y == midY || y == midY + 3) tileMap[x + (y * World.roomSpaceW)] = World.tUNDESTROYABLE;
            else tileMap[x + (y * World.roomSpaceW)] = World.tEMPTY;


            // ADD DOOR
            if (doorsAllowed && x==0 && y==midY+2 && (exitCount==1)) // || WorldGenerator.getMyRandomValue(100)>30))
            {
                if (exitCount==1 && generatedID!=0)
                {
                    tileMap[x + (y * World.roomSpaceW)] = World.tLOCKEDDOORH;
                    hasLockedDoor=true;
                }
                else tileMap[x + (y * World.roomSpaceW)] = World.tDOORH;
            }

        }
    }
}

And then similar for the South and West corridor generators. I also kept the corridor generator simple by always placing corridors at the dead-center of a “room”. The room-templates can take various shapes by filling the room with solids or “void” tiles, but the exits always need to be in the center of the edges.

All these little choices and strict rules are part of my plan to have a smaller development cycle for this game. I can spend another day working on making more interesting maze structures by not sticking to these rules, but in the end I don’t think it enhances the gameplay I try to achieve in any impactful way..

CARDS AGAIN!

I don’t think these weekly dev-updates will happen without any word on the card system, because I’m still figuring out a bunch of stuff and trying to improve it and make it flexible enough to handle all variations of the gameplay.  This week I ended up restructuring a lot of the code making it much more intuitive to use. The structure of the card interface now looks a bit like this:

uicards – A class that handles a single card, it contains the rendering of the card, the highlight of the action-radius on the map, it tracks the “owner” and the “opponent” of the card, and it handles triggering interaction,response,action on both the “owner” and the “opponent” when the card is properly played. On top of that it now also handles any sound-effects it might have to play based on the type of card it is.

uideck – the battle interface showing the top 5 cards of the player’s global game-deck at the bottom, with an interface for the player to select the cards, and then at the top of the screen it shows the player’s picked card vs the opponent’s picked-card. It also keeps track of who’s turn it is.   So if the player starts the fight with an alien by attacking it, it will be the players turn first, than the alien gets to counter it.. IF the alien attacks the player, the alien will play it’s attack card, and than the player get’s the counter that.

uiplaycard – this is for the special cases where a player interacts with entities like crates or doors. These entities don’t play a card, so it looks like uideck, except that it shows only 1 played card at the top of the screen (the players card) and the top-5 deck cards are not fighting cards but “freely-usable” cards instead (keys, bombs, etc).

It’s a lot of fun figuring out all this stuff, as I never did anything like it before. It IS a bit of a risk towards my goal of keeping the development-cycle small, because figuring out the new stuff is usually the biggest reason to have a game delayed!  But I’ve been pushing myself hard on working this all out and getting something up and running as soon as possible while having it expandable with new features in the following weeks/months.

The changes to the card-structure and type of cards now allows for weapons to cover multiple tiles, and adding items like bombs to blow up your surroundings.. ALWAYS fun!

See ya next week!


Come live chat with the developer and other gamers, get exclusive information on new games, features, discounts and BETA access, join the Discord: https://discord.gg/orangepixel