next »

[assemblerbot]

About

The Baneshifter is RPG dungeon crawler inspired by the first Dungeon Master. The main focus of the game is combat and puzzle solving supported by character development and story. Levels will be manually crafted and possibly extended/added by a level generator later. Also full save/load will be supported at any time (optional hardcore mode/single save is in consideration).

Motivation

I've always wanted to create my own RPG game from first person perspective. That was my dream from childhood. I've spent years developing technical features for a potential game in c++ (everything had to be perfect and made by me .. I'm sure some of you knows what I'm talking about :D ). Then I switched to Unity and found endless possibilities. Finally I could care about the game and not the engine, the graphics api, how to import meshes and other complicated and time consuming stuff.

The development

The Baneshifter development started at the beginning of 2020 and since I'm developing it in my spare time it will take a while to finish it.


As a full time game developer for almost 20 years I already know too well how boring and usually frustrating the classic professional game development is. It usually starts with a lot of placeholders and TODO features and then - later they are continuously replaced by more and more final versions until the game is released. Honestly - I absolutely hate placeholders! They are just not fun to work with. So I've chosen different approach. Everything you see on the screenshots and videos is meant to be final - sufficient for release. The game is in playable, stable state (build will be ready soon for download). Of course as the development continues, some features needs to be adjusted or improved. But that's ok, I'm counting with that .

What's already done

• the game core (menu, game mode, editor mode)
• walls (first set), doors, levers
• basic movement and combat(that needs improvements)
• items, weapons and inventory
• containers (chest, torch holder but also an alcove)
• first two melee enemies
• basic magic: light, fire and ice effects

How does it look like

I've made all 3D assets in MagicaVoxel/Blender, they are NOT voxels anymore just meshes. UI is done in Aseprite (I like that pixelated look).






A gameplay video from the latest build:




I'll try to write project updates in regular intervals but cannot promise anything.
Have fun!

[vdapps]

Welcome to the forum!

I just have to say, The Baneshifter looks gorgeous and fact that it's build from beginning as final is amazing. I was not able to achieve that in my game. Several proto levels already ended up in bin in my case.

Looking forward for more updates.

[assemblerbot]

Thank you

Well, level design is actually not final. I already have easy to use in game editor, so the level on the gameplay video above can be created in less than a 10 minutes

[assemblerbot]

Download of the latest version:
https://www.assemblerbot.info/downloads/

If you have any questions or suggestions, please leave me comment here.

[Schrompf]

Beatiful. I like the premise. Hand-made levels, combat and puzzles. Wonderful. And judging from the video you already have a whole lot of gameplay mechanics together. Nice work so far!

Movement is not block-based, which I mourn because I'd really love a new Grimrock. But this might work, too. The art style is nice, too. The walls a bit too samish, though: some darker areas where dirt, moss, you name it wore the walls down would do some good. And from the video I have a really hard time seeing where some item dropped. You know your level by name, you sure know that some ring dropped out of the burning barrel. I didn't see it.

[assemblerbot]

Thank you for feedback. Those dropped items are really hard to spot (I haven't noticed and totally forgot that ring for the first time too ). I've already put a note to my task list. Walls are more or less final but there are no decorations yet (moss, dirt, alternative wall meshes) but they are in my plan too.

The downside (maybe) of the development strategy I've chosen is that the game looks like final product very soon. What's on that video is practically it  . There is nothing more done yet.

In the next update I'll try to focus on combat, it feels very stiff and blocking/dual wielding is almost useless now.

[JobLeonard]

The voxel aesthetic is very nice, what is the creation process behind it?

[assemblerbot]

The voxel aesthetic is very nice, what is the creation process behind it?

It's very simple. At the beginning I've created a palette for all expected materials in MagicaVoxel. Then I set voxel density for the game (walls are 25 voxels/meter, weapons and other items are 50 voxels/meter and special items which looks bad in that scale are in 100 voxels/meter scale).

With that in mind I can create any type of asset very quickly. Some are exported directly as OBJ files to Unity and some needs extra pivot alignment, so I do that in Blender.

Same with characters. They are made of independent meshes - no rigging.

For example - my wall set:

[assemblerbot]

=== Update #1 - Attack animations reworked ===

Hi everyone,

it took me two weeks to rework all combat related animations and the controller that plays them. Especially the player animations needs to be as responsive as possible and I think I’ve reached that goal .

Also skeletons are now much more agile and ‘intelligent’. They react to player’s weapon, player’s actions and they also count with their own remaining health. Finally they can properly block with shield and two handed swords.

However a long road is still ahead. Next time I’ll implement bows and probably also magic staffs and magic wands. That should complete the combat set of animations for all humanoid creatures.

[Alain]

The combat in the video looks very tactile. I can imagine having a lot of fun with that!

[Thaumaturge]

I do rather like that the enemies keep their guards up, and seem to try to manoeuvre a bit rather than just rushing the player blindly. ^_^

[assemblerbot]

I do rather like that the enemies keep their guards up, and seem to try to manoeuvre a bit rather than just rushing the player blindly. ^_^

I'll be addressing that in next iterations. I'd like to add a bit more depth to the combat, maybe introducing stamina would help. Also an attack animation variants and combo attacks are on my TODO list (for both - player and enemies).

[Thaumaturge]

I'll be addressing that in next iterations. I'd like to add a bit more depth to the combat, maybe introducing stamina would help. Also an attack animation variants and combo attacks are on my TODO list (for both - player and enemies).

All of that sounds good, I think! ^_^

I would add a note of caution about stamina: it's somewhat the "flashlight battery" of combat, I feel, being a limiting mechanic that's widely included--and that I fear can be applied where it's more a nuisance than a benefit.

If your combat does call for it, then well and good! But it might be worth considering other options, too.

(And for what it's worth, this comes from someone who did end up including stamina in their own combat mechanic.)

[assemblerbot]

Stamina is an option I need to test first. I think variations and combo animations add better visual output. And let's be honest, the goal is to make some challenge and to entertain the player, not to really kill  . Even in the state it is now fighting two skeletons in a small room is pretty hard .. not to mention three or more. Moreover magic damage (fire/frost etc.) cannot be blocked just resisted by equipment. So now I'm focusing on ranged attacks and magic and then another combat improvements.

[Thaumaturge]

It sounds like you have a solid plan in mind, then, I'm glad to hear. ^_^

[vdapps]

I like this "solidness" of walls, objects, materials. Current games are very detailed, to make "wow" effect to showcase gfx, scenes are overhauled with details, which for my brain is "noisy". Here, it's relaxing for eyes, to see simplified, but yet beautiful graphics in game. Shading is really nice.

[smokesomefrogs]

The game is really beautiful! Great job :D

[assemblerbot]

Thank you 
Some decorations are planned of course but I still want to keep that Dungeon Master-like look. At least for the first wall set.

[vdapps]

Glad to hear that. Keep it that way!

In fact I replayed recently during Xmas, System Shock 2 and Deus Ex 1, then I tried newer games. And I noticed this difference for brain and eyes. In many new games, there is literally "lot of stuff" in scenes. I was able to focus way better to those older games than to new ones.

I don't want to say, we should move back to 2000-s gfx, of course not. But it's nicer if horsepower of new HW is used for nice shading, nicer overall look, and not just "throw lot of garbage" into scene so it looks realistic. Being able to perfectly focus on game adds more immersion than just overhauled scenes.

[assemblerbot]

=== Update #2 - Archers on the way ===
Hi everyone,
after longer "side quest" to the fantastic Pico-8 console I'm back and the development of The Baneshifter returned to the normal again. This time I'll write more philosophical post about how my new feature implementation workflow goes. If you don't like walls of text, just skip it :-)

Archers. Probably the most complicated NPC AI I'll be making. From the "definition" any archer should shoot arrows at his target. Sounds easy right? But there are few problems: How many arrows it should shoot? Where those arrows came from? Will be player able to pick them up?

Let's see how the other games dealt with the archers. In every game I remember, archers are literally factories that generate infinite number of arrows. That's nasty hack in game design that would cause access to infinite source of free arrows for the player and needs to be fixed - by another hack of course! Skyrim/Witcher/many other games solved it by 'virtual arrows' - so the enemy is shooting some kind of virtual projectile that sounds like an arrow (maybe even looks like an arrow) but after it hits a surface - it just doesn't exist anymore (I don't like it). Minecraft used more creative solution - arrows fly and hit the ground, they even looks like the arrows shot by the player, they just can't be picked up (I don't like it even more than previous hack).

The Baneshifter is my hobby project. And that means - no matter how hard it would be but I'm not willing to hack anything in my code! An architecture of the game code is really simple - there is an internal serializable game model and there is a visualization layer that follows the model. So everything that happens in the game model is (and should be) visualized. That ensures maximal readability of game mechanics (nothing goes in a background, player exactly sees what's happening).

So, my solution is following:
1. there is a limited number of arrows any NPC has in it's inventory
2. arrows must be clearly visible and they need to drop from the NPC upon it's death
3. NPC needs an alternative weapon that will be used if it runs out of arrows
4. player must be able to pick up the arrows shot by NPCs
5. everything must be visible and animated (no ridiculous weapon switching like in Skyrim)

Let's see the following animation of humanoid archer that prepares for fight (no aiming yet - TODO) :


The archer has 2 new item slots - a quiver on his back and a sword at his side. Note that the quiver contains in this case exactly one arrow. In the moment the hand reaches the quiver I moved the arrow from the quiver to archers hand in the game model which is projected into a visualization layer by changing quiver's representation and the arrow is spawned to the hand. After that moment the archer is literally holding a bow in primary hand and the arrow in his off hand. That gave me immediate benefits: if you kill him at that moment, he will drop the empty quiver from his back and the arrow from his hand. I may even allow the player to rip the arrow from his hand if he is close enough! Another benefit is the game state serialization that works without problems out of the box. If the archer looses a target he returns the arrow back to the quiver (that also works).

Aiming is still under development. I'm using my own animation system, so I have to implement one feature that allows me to do that - almost done.

I hope it was not too boring :-) Stay tuned, archers will come!