next »

[vdapps]

Great video as always! This gives feeling to me like Dungeon Master on steroids. Also happy to see all those wands, swords, chest, locks. I'm big fan of this voxel art-style. This is the right way to give old-school pixelated feel to new modern games.

[assemblerbot]

=== Update #8 - Visibility (again) ===
Happy new year everyone!
Christmas time is for me time to do something relaxing, something I love to play with. For example 3D math!

My old ray-casting based visibility clipper was great for single-floor spaces. Since I've added vertical connections and holes, that old clipper needed few "improvements" and performance went so low in critical cases (like 100 holes in single room :-) ) that I had to fix it somehow.

I wrote another ray-casting based clipper. Full 3D this time. It was better but it produced artifacts in edge cases.

So I've decided to use good old fashioned sector-portal based visibility clipping as the old games like Quake, Duke Nukem, Chaser etc. have. I've started with BSP-tree building but in regular grid like the Baneshifter has it was complex and pointless. From my experience Voronoi diagram works better and it's much faster than that. Generating portals was easy. Clipping them to view frustum not so but I've managed to do it.

Here are few pictures for my debug tools.

[vdapps]

Nice! I like you have nicely mixed game and editor, editor even in the same style/fonts etc. as game itself.. will you plan also to release editor later?

And I like Chaser being mentioned together with Quake and Duke Nukem haha )

[assemblerbot]

The editor is already built into the game so it's just a matter of one switch. I have to make it a little bit more user friendly and then it can be released.

And about that look, it has a serious background . In past two decades I've started to make multiple games. Various styles: hacking simulation, text based rpg, racing, space shooter, etc. For every one of them I've made set of tools to create game content. Those tools were so complex that at the end I've realized that spent much more time making the tools than working on the game itself. Finally I've always reached the point where I wasn't able to continue but the time was already spent.

 So this time I've decided to spend as little time as possible on editor. Almost all assets used in the editor are the same assets used in the game. The underlying data model edited by the editor is exactly the same used in the game. So the whole editor was done in like 1 week and every time I'm going to implement anything new into it I think twice if it is really needed and whether it is possible to use something I already have in the game.

Thanks to that approach I have few very interesting features in the editor:
- I can interact with game objects inside editor exactly the same way the player interacts with them in the game (for example I can pull lever, it plays animation, sound, opens linked door etc.)
- game physics works also inside editor
- even AI can be used there if I allow it
- technically it is possible to edit save games, including flying arrows, spells etc.

So basically the editor is just another view to the game.

[assemblerbot]

=== Update #9 - TTT ===
A bit of gameplay after that boring stuff. I've implemented traps, teleporters and triggers. Triggers are not visible, they are just technical entities. Combinations are limitless

[JobLeonard]

That is awesome. Can't wait to play this game and mumble "I think I just failed a spot check" 

[Alain]

Every good dungeon needs traps and teleporters. I love these kind of riddles

[JobLeonard]

The most evil teleporter riddles are the ones where you don't immediately notice you were teleported, so they completely throw off your sense of directoin

[assemblerbot]

The most evil teleporter riddles are the ones where you don't immediately notice you were teleported, so they completely throw off your sense of directoin

They are already on my TODO list

[JobLeonard]

Looking forward to hating them, lol

[assemblerbot]

Don't worry, also compass and automap is on that list

[vdapps]

This voxel teleporter is awesome, also with this subtle animation when something is passing through. What I love is that the art is procedural!

[assemblerbot]

=== Update #10 - controls ===

This time just a short update. I've implemented reconfigurable controls . It's so standard but it was harder than it looks like 

Also the AI got a small upgrade - it can handle "soft obstacles" now (for example teleporters or static traps). It will eventually pass through them but always try to avoid them if possible.

Now I'm working on an automap.

[Alain]

Cool, I believe this is the first time we see your UI and it looking nice!

[mobilelast]

for the reconfigurable controls!

Which input system are you using (old input manager, new input system or some middleware)? I recently implemented rebinding for keyboard, mouse and multiple controllers with Unity’s new input system, and there certainly were (are?) many pitfalls on the way.

[assemblerbot]

Which input system are you using (old input manager, new input system or some middleware)? I recently implemented rebinding for keyboard, mouse and multiple controllers with Unity’s new input system, and there certainly were (are?) many pitfalls on the way.

I've tried Unity's new input system but it had so many problems: for example - it looks like that system is internally queuing controls when pressed and then it executes them even after they were released, so if the game runs on slower machine it's literally unplayable (reactions to input are delayed few seconds!). And there are just too many missing parts in it that I've decided to make my own input system based on Unity's Input class.

For now it supports:
- key controls: button, toggle and impulse (executes just in the frame key was pressed and ignores that key until it's released)
- axis controls: 1D, 2D (mouse)
- scroll controls
(joysticks and controllers needs to be implemented, but it should be no problem)
- stackable layers: for example popup window controls layer can be placed above game controls layer and block game controls, then it's just popped out when popup is closed and game controls layer handles input again
- serializable binding schemes
- default binding and dynamic binding with collision detection

My input system is not dependent on the game, so I'm planning to release it when it's finished. And I have to remove dependency on Odin (I was too lazy to make custom inspector script for setup ).

[assemblerbot]

=== Update 11 - Auto map ===

Hello, fellow developers.

Auto map is in the game! The main feature I've spent most of the time on was anti-cheating mechanism. Auto map does show secret doors, buttons, illusion walls and floors but only after the player is able to see them or after he used them. For example illusion wall looks like any other wall on the map until player can physically see through it, only then it's changed to illusion wall graphics and space behind it is revealed.

[assemblerbot]

.. and the HUD version of it

[JobLeonard]

Nice!

edit: I can also imagine some magic spells (like on a one-time use scroll) that would fill in the hidden doors/traps/etc for you on the map, which would still require you to find it in the rest of the game

[assemblerbot]

I can also imagine some magic spells (like on a one-time use scroll) that would fill in the hidden doors/traps/etc for you on the map, which would still require you to find it in the rest of the game

Yes, such items are planned.