Skip to main content

Treasures Of The Deep Dwellers: A Real Time Grid Based Roguelike?


Hello again!

It's been quite a while since I posted here. I've been working on other projects, and spending a lot more time with my family, but the core reason is that I just lost interest in the project as it stood.

But wait! I haven't given up. I just needed some time and some ideas to remake my vision in to something that:
A: I can finish.
and
B: Is actually fun.


So read on for the next chapter in the development hell of:

TREASURES OF THE DEEP DWELLERS!

 
This time last year I took a break from this project since it was wearing me down.

I realized I was making a game for me, with stuff that I liked. But which I would probably never play.


What I really wanted to do was capture some of the excitement and joy of playing an RPG / Roguelike for the first time...

And package that as something that modern players would actually find enjoyable.

So it's clearly time to start over.


 Where do I go from here then?
Well, one idea I had was for making the game real time, and grid based.
I've made two complete games lately using this system, so it seems to improve my productivity anyway. Everything is just so much simpler. 

But single tile grids give too much of a blocky feeling that real world players complained about. I decided to make the grids more granular.

So now a default agent takes up a 2x2 chunk of the grid. They still move one square at a time though. You can see the debug function showing which squares are occupied by the agent. I talked a little about how I did this in an earlier blog post

  
The system makes it easy to scale up agents to 3x3 or even 4x4. A giant spider, a dragon or daemon perhaps? This is something I've wanted in the game from the very beginning. Different size monsters really add a great deal to an RPG. If everyone is human sized it gets boring fast.

Pathfinding has also been greatly simplified. I found a nice form of dumb AI which makes for quite interesting encounters, as the characters spend behave more unpredictably. 
The basic premise is that monsters will try to get closer to a seen enemy and will not backtrack until they get stuck. It's like water running downhill. It just keeps draining down until it gets blocked and then it tries to find a way around. Eventually it can overflow and fill backwards.
The most important point is that it allows for a large number of agents working in real time with no noticeable logic drain. So it's great for a python based game.


You might wonder why I chose 2x2 as the default character size. Why not 1x1? Well I'm saving that size for smaller creatures, like rats or insects which can swarm through small gaps... You can imagine the small creatures darting in, making an attack and running away again. Better pack a crossbow on this adventure!

Overall the game is going to be simpler. It's aimed at teenagers or kids playing a classic RPG for the first time. I want to make it fun. I want the thrill of an arcade game with some of the deeper options of an RPG.

Essentially though I want to get it finished! I'm going to be focusing on game play and functionality. No more wasted time on graphics which I might or might not use! 
(Final last words of an artist!!)


Comments

Post a Comment

Popular posts from this blog

Back to Vinland.

I'm going back to my real time tactics project, Vinland 1936.
While working on the other project I overcame the problems which were stopping me from saving/loading the game and also cleaned up the base code a lot.

After a few weeks I'm getting near the the state I was in before.


Infantry are back to their previous state, and vehicles are running OK.
This time I'm going to push ahead with mocking up the combat system though before I work any more on the vehicle builder or graphical aspects of the game.

Rockets

I finished working on the code for adding foliage and having some extra time I decided to experiment with the code for rockets.

The original idea I had was that rockets would be large vehicle components that can be fired very quickly, regardless of how much manpower is used for reloading.






They would use up a lot of ammo, so they would run dry after a short but devastating barrage.
The problem here is that it's easy to take advantage of this by adding a lot of ammo, which is much smaller than in bulk than the rockets.

There's also the problem of firing large caliber rockets. In real life rockets of up to 30cm were used, but I think that will be too powerful for the scale of combat in this game.



lol. Somehow that one trooper survived the mother of all explosions...

A 30cm rocket could contain nearly 30KG of explosive. That would be a very large explosion.

I've tried to balance the game by using a simple equation to make bigger guns more powerful, but hopefully not too powerf…

Infantry combat and entering buildings.

I've been working a lot on the game recently and I've nearly rebuilt it to the level it was before. Past that maybe, since now I have the beginning of a working combat system and the ability to save and load the game.


Infantry can now occupy a building. It's quite an abstract representation, since they stay at the door and turn invisible. But they can then fire from one of the windows and take damage from shots at the windows too. I think I've set it up well so that when building damage and destruction is working then the system should continue to work.

For combat I tried some new ideas, but they didn't work out that well. It seems that it's important that viewing range should be further than shooting range. Now shooting range is pegged at 18 units of distance, while viewing range can extend out past that.

In the above image one unit has an officer, so has further viewing range. The other can only see as far as they can shoot, a dangerous situation since the en…