#roblike

[stealthcoder]

Side-stuff updates

I haven’t posted since Christmas for the mandatory Ludum Dare spam, but that doesn’t mean I’ve been idle. On the one hand, I joined a project at work using Cocos-2dX, so I started a smaller project at home to implement a first pass on RTS mechanics using a top-down 2D view using that library. My reference is Castle Fight, a relatively well known mod for Warcraft 3 (Fun fact: if you think about it some of the most successful games right now both on mobile or PC (most MOBAs, Clash Royale, etc) can be traced to a mod of WC3/SC, or a variation). Progress is slow because life (and to be honest, Arena of Valor -_-). I’m trying to keep over-engineering under control, and I’ve started coding some construction logic. Hopefully soon I’ll be able to show something better than this.

Besides, this week began the #7DRL challenge. I’ve used the opportunity to check TDL, a Python-3 upgrade of sorts to libtcod, a c++/python library that has lots of useful functionality to code a roguelike. However, I don’t have any clear idea for a game that could use it, so for the time being I’m basically refactoring a tutorial. Hopefully I’ll come up with something. On the gif you can see how the player moves around on a map. FOV is provided  almost for free by TDL.

I tried to extend the tunnelling algorithm to support diagonal corridors with some old code for a C++ roguelike project using PDCurses. The corridors are built just fine, but I need to review how surrounding walls are built to avoid overlaps. And last, I also managed to shortly revisit Roblike. I had to upgrade it to Unity 2017, which broke the alpha blending shader. While I was fixing that I also managed to replace a custom masking material with Unity’s new and shiny SpriteMask. Then I thought that replacing my custom tilemap logic with Unity tools could be an interesting excuse to resurrect the project in the not-too-distant future.

[stealthcoder]

Just in time so I can have a couple of days to rest before #ld37, I’ve managed to implement a new Rob-like iteration adding orientation and rehashing the visibility logic. Together with the enemies I think I have the foundations to start focusing on how stealth gameplay would work, design-wise.

Basically, an entity can now have the following two traits:

Orientation (north, south, west, east), which determines where an entity is facing.

Visibility. This trait works as a sensor that lets an entity detect other entities inside a specific area inside the map. At the moment, it just consists of a shape (a cone or a “circle”), and a visibility algorithm, and it just determines if a tile is fully visible or not. In the future, if it makes sense, I want to make the visibility checks return an integer instead of a boolean, so we can have different levels of intensity. This will probably be handy if I implement noise. The possibility of having both sight and hearing suggests two more ideas.

First, define different sensor functions for the intensities.  One could be suited for sight calculations. Another one for hearing, yet another one for...I don’t know, heat sensors, whatever.

Second, allow one entity to have more than one sensor.

As of now I’ve only defined two different visibility algorithms: a simple raycast-based approach that casts rays against the world and a shadow caster. I’ll try to provide some diagrams and even code samples in a future post to show all these ideas.

In case you’re curious, these are the most important references I’ve used for this second pass:

An article on Rogue Basin listing several approaches to visibility on rogue-likes.

Eric Lippert’s series on Shadow casting.

You may have also noticed on the gif that there are now bats moving around. I wanted to have a quick pass on enemies and combat ready and worked out a super-simple “blink or hit” behaviour. I chose a bat because their behaviour made sense (also, in terms of plot our thief intends to begin from the top of the building, and bats entering through the windows will probably a be a common occurrence on those levels). In terms of development, for now I won’t be updating the latest build until the game feels more “gamey”. At the moment I’ve been hacking mechanics into the game, but they’re not working together, so once I’m done with a couple more features I’ll start polishing everything from map generation to combat or loot calculations so that I have at least one decent playable level. From there I’d like to keep expanding it so that tiny level becomes a proper skyscraper building with a couple dozen floors.

[stealthcoder]

Been playing around with Rob-like again to leave it in a state where I can resume work to turn it into a proper roguelike. Specifically, over the last week I’ve improved the following: 

- Got rid of the 1-sprite-per-tile approach, and defined a single game object for the tile map view! :D At the moment I’m generating the tile map texture manually  and redrawing only the dirty tiles. It works reasonably well for the time being, but generating the texture on the CPU can be cost intensive, so as the game progresses I will still perform further optimizations (dividing the view into chunks of reasonable size is one idea, but I also want to explore moving from a SpriteRenderer to a grid-like mesh) - Added support for larger map sizes. From the original submission, which had a single room occupying a whole screen I could have followed the Zelda / Binding of Isaac approach and create individual rooms per screen, but I preferred to have a more continuous level layout.  - With larger levels comes the need for some camera work. I created a world window object that clips the scene into some specific dimensions, and I’ve also implemented some basic player tracking. Constant camera movement can feel hard to the eye, so I intend to improve that soon by means of a rectangular frame that’ll allow the player to move without scrolling the camera until she exits its boundaries. I keep this article as a reference (even if it’s aimed at 2D side scrollers, I can adapt some of the principles to Rob-like) http://www.gamasutra.com/blogs/ItayKeren/20150511/243083/Scroll_Back_The_Theory_and_Practice_of_Cameras_in_SideScrollers.php#h.fotkmsbg57ip - Last but not least, I finally managed to fix the BSP map generation, which was broken almost beyond repair. On the animated gif above you can see a tiny in-game sample using small map and room sizes (otherwise it would have become long and boring). The header picture, on the other hand, shows an example of the generated texture for a map of 64x32 tiles. It seems there is a strange corridor leading nowhere at the bottom right, which means there may be still some lingering bugs, I barely altered the corridor generation today after all. With the map view finally clicking, I can focus on creating proper gameplay.