#slugdragoondevlog

[slugdragoon]

Devlog #1

Ok, I've been working super hard on my game this week, and I have something to show off. Generally, I did not want to start doing Devlogs until I had what I considered a working prototype, and that's what this is. I think I'm at the point where a lot of basic things work, and I will be able to focus on building it out, which will make for more interesting regular updates.

So, what we're seeing in this clip is:

SPLASH SCREEN - just a test of animation and the flow of booting up the game, it will not be in there for long, I just threw random assets in.

SAVING & LOADING - The title screen is plain, the "Settings" option doesn't do anything yet, but the "New Game" and "Load Game" do! They currently go off of one filepath and save games are stored as JSON so I can edit them easily for testing, and they don't yet prompt "are you sure?", they just do it, and the functions work. I can save my game and all the party and player stats and values load in properly. [Not shown: there is a save button in the Pause menu, but that menu is very basic]

BATTLE UI - All is placeholder, and ugly, but I focused down on getting it to work. That means, while I was throwing buttons in there for testing early on, I spent major time reworking menus to work with controller instead. I may do KB&M support later, once the UIs are actually fully designed, but doing them in parallel while I'm changing things would not be nice. We can attack, you don't have to click "Confirm" anymore, just a controller button, we have spells/skill and items which can target either enemies or allies, and both single-target an multitarget skills exist and flash up corresponding selector arrows, after which you can confirm your target. Party members have an HP/MP display and the character whose turn it is will be highlighted on their turn

MESSAGE OVERLAY - As you can see, I've worked out the system to have messages give the player feedback in-battle which can also be used for dialogue out-of-battle. It works off of a queue containing both messages that auto-play and messages that you have to confirm before moving on, so I can mix-and-match as appropriate. I wanted to have this in place so I can soon implement NPCs and shops, and the battles make sense to both me and the player as I add more features to it.

When we load into this test dungeon, we see the old sprite for a demon, I redrew them, as you can see in the first random encounter. None of this is final though, these were also pretty quick I just wanted to discard the really lazy MS Paint-looking sprites If I'm going to be showing the game off more, I want it to be in a better light. I'm not even sure Demons and Bats will be common enemy types in the game, it's just for testing. Nothing that you're seeing is final, or even really fits the vibe in my, mind yet, but it's approaching something that looks like it has the potential to be a game.

After all all of this I haven't added any new enemy types, items, or skills yet, the assets aren't anywhere near what they will be like, no levels have been created yet, but I think what I have is a lot of the "structure" of a basic RPG. I ate my vegetables, the boring parts are functional, and it opens up a lot of doors for what I can develop next.

NEXT GOALS -

NPCs in the overworld (+Shops, need to have a way to acquire items, currently the inventory is hardcoded into a New Game)

Implement a method to recruit and dismiss new Party Members, they are also currently hardcoded for testing purposes

There are still lingering menu navigation bugs, but nothing that can't be fixed relatively quickly

Move the starting area to a safe-zone that can be built out as the main hub and create multiple dungeon rooms with different testing conditions

More visual feedback. Having enemies flash on taking damage and displaying damage numbers would be a good start, more complex animations can come later, including spell animations.

[slugdragoon]

Devlog #3 (+ video)

This week, I felt as though I had a bit less time (life got in the way slightly more, my car broke this week, etc.), and what I did do was a lot of code refactoring, and less visual, but after recording the devlog, I'm actually pretty happy with it for a "slower" week.

PARTY SWITCHING - You can now switch around party members in the Pause Menu, take Party Members on and off your team, and considering you have many backup slots, this is an essential mechanic to have implemented. I'm gonna keep it real though, I messed something up with the swapping code and it's leaving null slots that introduce bugs, I'll fix that soon.

USING SKILLS IN THE OVERWORLD - Wanna heal up out of battle? now we can! The Pause Menu has a submenu for each caharacter's skills, if they have any that can be used out of battle.

IN-BATTLE TURN ORDER REVAMP - Now it's possible to choose any Party Member in battle, and have them use an action. The game keeps track of who has gone, and one condition for the turn ending is that they're already all done an action. Once I fix swapping from the Pause Menu, I'll add it to battle, too, and swapping in a Party Member will probably mark them as used for the turn.

TURN ORDER REVAMP PART 2 - I introduced a battle clock that's meant to control the flow of battle and be one of the unique mechanics that gives my battle system it's crunch. The turn ends when the battle clock passes over to the opponent's side of the clock, and vice-versa. There's push and pull where you do certain more powerful actions that spend more time, and that makes the enemies' turn longer. Right now they just do basic attacks, but in future, their AI will spend more "time" on big attacks if they have the initiative to do so, putting you in a dangerous spot. I also imagine ritual casting longer spells in the overworld will cost time out-of-battle that can mean you start a battle at a disadvantage. Faster characters like (eg. rogues and time mage types) may have abilities to set the clock back or allow other characters additional actions.

NEW ASSETS - I've done a quick asset pass just to take a look at the general look of the game, and experimented with what I'm able to make just by recolouring and reshaping the assets I've made. This is just a start, but I wanted to get a sense of what I need to make to build up the town and dungeon interiors.

That isn't such bad progress considering how tangled I thought I had been this week in sub-menu code. I'm sure there are better practices but trying to get sub-menus to have exactly the behaviour I want is the most difficult thing I've done for the game so far, and it's so important.

This week I may focus on some more fun things like more skills/abilities. Can't really test the battle clock without a more robust set of skills, and it forces me to implement some enemy AI as well.

[slugdragoon]

Devlog #2 (+ video)

Another great week this week! I'm planning to do devlogs once a week from now on, aiming for Monday, but later in the week if I can't.

A lot of progress has been made again:

ART - Decided on a colour palette for the game - this was a prerequesite for some of the assets I want to start making more of- needed to have it decided so assets don't need to be replaced later. I made brick, wood, and dirt textures, currently just blocks, but I plan on adapting them into tilesets based on them.

HEIGHT CHANGE - I noticed that the verticality I have with the stairs made the stairs look massive from the old perspective, so I raised the camera. This led me to add a crouching mechanic, which I think can help design for more hidden crawlspaces in dungeons. Changing the scale also forced me to finally add continuous movement when you hold the button, as without it moving a cell at a time feels slower.

INTERACTABLE PROPS - Added a working treasure chest that stores it's open/closed state and gives items to your inventory. Added a working door. Added a basic NPC that just says queued messages when you interact with them, still need to add UIs for shops and choices in dialogues, NPC movement, all that. Also, added out and inner-corner stair types to make various shapes of raised platforms/elevation possible.

PARTY RECRUITMENT - Party Members now have a spot on the pause menu to see their stats, and enemies can be recruited to add to the party, but the system is very basic and incomplete. Still going to add the choice to recruit/reject a new party member, so randomness to recruitment, as well as party member swapping and deeper stat examination menus, and accessing field-usable skills like healing.

[slugdragoon]

Devlog #0

My dungeon crawler game is in the extremely early prototyping stages (like no art at all, just placeholders, the battle system is nothing so far). I didn't think I'd show it or make this blog anything other than my thoughts about RPGs for a long time. But, I've been really liking Tumblr and seeing what other people have been making, so I'm just getting that feeling.

I've really only prototyped basic movement mechanics, and am working on implementing the battle system, but I think next steps are including at least some basic concrete enemy types, party stats, and attacks to build it out. I don't see myself replacing the art until the game is quite playable, the faster I can iterate and delay committing to a specific look, the better. That's why I've been thinking so much about character.enemy/unit classes in RPGs.

What I've done so far that I can be a bit proud of:

Movement in a basic tile-based dungeon (maybe the way I did it was suboptimal, but it isn't how you often see movement tutorials for these game engines, the player controller has to have collision boxes in adjacent tiles as "feelers" for walls, to disallow some moves). You can strafe like in Etrian Odyssey or SMT: Strange Journey, so your movement direction isn't the same as your looking direction. There is also a feeler on the bottom to see if you should be falling after moving.

I have working stairs. The stairs have collision boxes at the bottom and top to decide whether you're going up or down, and the player also can mount stairs smoothly from the side, but falls off if doing the reverse. Honestly making this work was surprisingly difficult without having the camera clip through the stairs, more though went into these movements than expected.

I have a working door/teleporter to take you to other rooms in the dungeon.

A random encounter system. It can pull up different groups of enemies based on the areas encounter table, and ends the battle and returns you when all are down. There's an arrow to select your target. All enemies die in 1 hit right now. You can run away too.

It might be a while until my real Devlog #1, as I think this one was a bit early, but I finally felt I should keep a record of this early stage for later.

[slugdragoon]

Devlog #0.1

Ok, so I've been experimenting with Blockbench, and it's really nice for keeping low-poly models simple in terms of geometry and texturing, but it isn't set up for animation like Blender is, but I think I'm getting the hang of it.

Using this tutorial (MisterGriimm @ YouTube), I was able to get inverse kinematics working (the endpoint link at the end of a chain affects the links above it in the chain, like a tail), but what I realized after experimenting a bit was that it seems like the rotation of links that I use IK on were locked. That is, if I were to put a hand as the endpoint of a chain consisting of a hand, forearm, upper arm, and shoulder, I couldn't rotate the hand. So I thought, OK, maybe I do need to learn more Blender animation and do low poly assets here, then bring them over there to animate.

However, it seems that if I make a separate group that is a child to one member of the chain, I can have it rotate freely, but it moves with its parent! So, I believe I can make a skeleton rooted at a body, with multiple chains (ie. arms, legs, neck/head), but have side-group that act as the muscle/skin that has more freedom of movement, that are not part of the chain itself! So, in the GIF above, imagine the skeleton made of the brown sticks, and a covering of blue blocks, low poly but smartly designed to hide joint seams. It's like a make-your-own armature, and it seems to be totally possible in Blockbench.

Probably a lot of the 3D elements will be out of battle, and have simpler animation that don't require a skeleton, but this gives me just enough flexibility to attempt something more when I need it.

I'm still not even calling this Devlog #1, as I'm still building up the skills I need to fully make my own game, but besides this, I've been working on some in-game battle menus, which are partly implemented, and formulating the setting story, which is becoming more and more clear in my mind. Trying to develop a colour palette for the sprite work as well, and my 3D assets won't look quite right to me until I settle on a palette for the whole game, which will first be directed by the pixel art.

[slugdragoon]

Devlog #4 (+Video)

Most of the work I've done this week was focused on a few features, but I think they're quite major and the first in particular I think really helps ass flavour to the combat!

MINION SUMMONING - Certain skills summon Minions to the side of the enemy or party member that summoned them. The two test minions I put in are Snakes which attempt to Poison you, and Sheep which can put you to Sleep. The idea is to aid in making status effects more viable by adding more texture to those playstyles. I envision being able to allow players to put bosses to Sleep if they work to set it up, for example, which many JRPGs frequently disallow. Think of minions as smaller and less impactful individually than a full party member, but adding texture to skeleton-wielding Necromancer or animal-calling classes.

STATUS EFFECTS - Did some work on building out the framework by which status effects work generally. A placeholder version of Poison and Sleep have been implemented, but those implementations will be refined and balanced.

ENEMY AI - Enemies now have their own SKill lists and can use them based on simple rules currently. The logic will be fleshed out to allow myself to build interesting encounters and synergies between enemy parties, but for now they can use stronger Spells and make use of their side of the battle timer.

RECRUITMENT UPDATE - Recruiting enemies at the end of battle now has a screen which offers you the choice of whether or not to recruit the chosen enemy.

ANIMATION - I didn't spend hardly any time on art, but I've been showing static sprites for so long I wanted to give a peek at my animation process through a simple WIP idle silhouette, so that anyone looking at the game can at least tell it's something I can be capable of once I do get around to putting in art/animations in a serious way

PAUSE MENU UPDATE - Honestly just touched on things that are helpful for testing, but a lot of the code was rewritten, and some placeholder elements are now more accessible. I'm allowing it to be ugly for now while I work on other things.

[slugdragoon]

Video Devlog #1

Since I considered my last post my first "official" devlog, I figured it would be a good time to start a YouTube channel, never too early to start reaching an audience, or at least, if I want to promote the game when it's a lot more finished, it will be good if the game has a long history onlint. Mostly it reiterated things I've already posted here, but I'll probably be accompanying my text posts with videos from now on.

[slugdragoon]

Devlog #0.2

Wow, I have had an incredibly productive past two days in terms of my game development. I've been sticking to naming my devlogs 0.x because I didn't consider them "real" until my prototype was playable/not embarrassing, and I didn't want to start with #1 until I thought I'd be doing it regularly, but all of a sudden, it seems very close.

I thought that, after my Devlog #0, I wouldn't post about it at all for some time, but it's been 24 days and I felt the need already to provide two more updates. Every time I post my thoughts about other games (which is fun), I always think I'd love to have something to show for mine, and coming back keeps me connected and working on it.

I think posting on Tumblr has really motivated me. Really, indie devs, and particularly solo devs are so motivating to me (shoutout to artists too), and I feel more accountable to the 5-10 or so people who have been viewing my posts so far. If that's you, thank you, if you even just took a small look.

Just a text post this time, but just in the past two days:

Party members are now implemented with their own stats and skills. Currently I have dummies hard-coded in there, but it is possible to add new ones to the party. Probably recruitable enemies will have a method to create a party-version of themselves.

The basics of the battle system work. There is a system in place to maintain turn order between party members and enemies. For the player turn, we have skills that target either your own party members (healing spells) or enemies (hurting spells), and both have single and multi-target variations. Enemies do basic attacks. Death of party members is not yet implemented.

New UI elements (ugly ones for testing functionality) have party member stat windows in-battle displaying their remaining health and magic, which update when they change. These windows are outlined in a highlight currently for the player whose turn it is, and selector arrows are shown for targeting of spells at both the party and enemies.

Oh, also for at least few days before the last two of coding, I wrote out a decent bit more in my design doc for planned skills/mechanics/enemy types, and worked on some art. They go hand-in-hand in my workflow, and each side pushes each other along, as I need to know what's going in the game to know what assets I need, but sometimes drawing and animating makes a idea clear that goes back in the design doc. Just in a creative zone right now!

The next stretch will be doing some work on items, NPCs (especially shops, and an out-of-battle menu for accessing Party Info, Skills, and the Items.

[slugdragoon]

Working on a character portrait, a finished version of this will probably end up in my game somewhere. The hair is unfinished, and the clothes/arms are not started at all, but I like the face so I think I'm saving this for later.

If I'm really showing my hand, this is one first draft at a possible protagonist portrait (may be a few options, in the end), though I'm not ready to implement this in the game yet, so a lot could change. If not, they'll end up as an NPC.