next »

[Zireael]

Hello guys,
I'm new to TIGSource but I was directed here by a couple of nice souls such as Kyzrati.

I have been working on my game in my spare time for the last 3 years. The amount of said time varied from month to month.

The game is a roguelike with RPG elements. The title is a reference to the fact that most of it takes place underground (getting to the surface is a win condition). However the underground is not boring - there are caverns, mazes, as well as cities and whole other planes of existence to explore!

Quite a lot of the features are just things I, the dev, happen to like or wanted to experiment with. For instance, I liked the family/dynasty aspect of Crusader Kings 2, so one of the things I implemented was the ability to have a child. The game being a roguelike, having a child...



... can let you keep playing even if your starting character dies.

One of the things I loved about classic RPGs was the character portraits. So let's have...


... procedurally generated NPC portaits... as well as languages affecting the way your character communicates with the NPCs. These two know the same language, so they can communicate, and the game swaps some words for the words in their language. If your character doesn't know the language, the text is scrambled instead...

---
Some boring technical details:

Until September 2016, the game was a T-Engine module (for those unfamiliar with roguelikes, it's the engine ToME 4 uses)

ModDB page of the module


A maze under the thieves guild in the T-Engine version

In September, I decided to port the game to LOVE2D. Changing the engine allowed me to pull off more nice stuff, especially as far as the UI is concerned. However some of the features are not yet implemented (the kids, for instance).

I also further refined the design (for instance, instead of emulating the d20 ruleset, I am going to use an original one).


Torchlight effect in LOVE2D version


Inventory screen in LOVE2D version

A couple days ago, I realized LOVE2D lets me pull off something that has been a dream of mine, that is isometric graphics.


Current state of isometric version

The counter next to the thread title refers to the progress on the isometric version.

***
If you're interested, I could make the .love file available as soon as I finish reimplementing the UI in the isometric version.

Any tips? Ideas? The main reason I signed up here was to receive feedback on the game as I work on it.

[InterGalactic]

Hi, it looks like you put in a lot of work and seems to have nice amount of content, but firstly I think you should focus on introducing what sets it apart from other roguelike rpg dungeon crawlers? Also the graphics are really outdated, I mean I know roguelikes should have retro graphics, but these are the kind that doesn't inspire or have a wow-factor. I would suggest to look for an artist if you aren't one yourself. Hope it helps.

[Zireael]

I am not an artist nor do I have money to spare for gamedev .

I am using a freely available CC0 set of 32x32 tiles and considering an ability to switch to 64x64 tiles at will - the 64x64 tiles the artist has graciously allowed me to use - (given the fact that using bigger tiles necessarily reduces the amount of stuff you can see on screen)

As to what sets the game apart from other roguelikes, I am hoping to focus on the things I outlined at the beginning - so the ability to have kids... the languages playing a role... the NPCs by extension... (since a game could span years as you play 2 or 5 adventurers, it's important that the game world not be static). The simplest part of livening up the game world was having the languages play a role, as well as implementing various factions and cities. Factions open the doors to having a war play out in the town, for instance, between rival noble houses. The NPCs would also be able to have kids, re-using the same code as it's not player-centric, so you might see the same noble house led by the original Matron's daughter or niece.

Apart from the game world, I was hoping to implement a suitably modern UI. So the inventory has slots instead of being an Angband-style text list, etc. etc.

[InterGalactic]

I can't speak for others, but  for me the USP still seems too trivial, alike a mod almost. Regarding artists, try pitching your ideas to them, perhaps for rev share. Discord Game Dev League is a good place to look for one. Personally I did everything myself coding and art, but I guess I had a background in that since I was a graphic designer / web dev before I quit.

[Zireael]

I can't speak for others, but  for me the USP still seems too trivial, alike a mod almost.

What's USP ?
And bear in mind, until September the game *was* a mod. Additionally, roguelikes are a genre in which many elements are recycled and it's the setting and UI that matter the most.


Re: artists. The game is and will be free (as is the case for most roguelikes - Cogmind is the exception), so I can't promise them any revenue shares.

[Zireael]

The isometric version is now on par with the orthographic one as far as the GUI is concerned:



The stone texture for the GUI was picked for two reasons:
1) the game is set underground, so it fits the theme
2) it's meant to evoke old classics such as Eye of the Beholder, Menzoberranzan and Baldur's Gate

[Zireael]

The isometric version is now equal to the orthogonal version. The only thing missing is somehow showing the FOV.


A short clip of the game in action

I also sneaked in a couple of improvements - the visible log above the bottom bar now always shows last 5 messages and a shield shows up instead of damage splash if the target was not hit.

***
Please, please leave some feedback - whether it's to ask a question or request a feature or say something (especially the UI) could be designed better.
Now that I am not limited by T-Engine, the sky is the limit, I only need to know what to focus on so that the game is received well by the non-rogueliking crowd.

[tpelham42]

Definitely shows a lot of progress and hard work here. I can certainly understand the limitations of graphics and, honestly, graphics are important, but what's more important is good game play. The family/child idea is interesting one. What are the core mechanics of the game? What is your "elevator pitch" for the game? Aside from some random ideas I'm not sure what the over all direction is other than a roguelike/rpg game. Is there a story or is it just a dungeon crawler?

Looking at the screenshots/info I don't see much that makes this different conceptually from a lot of other rpg games. This doesn't make for a bad or unfun game, but at present it doesn't draw me in.

Good work on getting so far and look forward to how it progresses.

[Zireael]

The family/child idea is interesting one. What are the core mechanics of the game? What is your "elevator pitch" for the game? Aside from some random ideas I'm not sure what the over all direction is other than a roguelike/rpg game. Is there a story or is it just a dungeon crawler?

For now, there is no story (as is the case with most roguelikes/dungeon crawlers) but I have seen a couple articles on procedural story generation and they made me realize that it's possible.
I guess I'll start working on the story once I have the basics ironed out.
That includes the level generation, which is my bane (I would often attempt to implement e.g. a cavern generator three or four times before it clicks despite knowing 'how it works' conceptually).

I think the main idea is that it's supposed to be a sandbox, but one in which your actions affect the world. I keep coming back to the idea that the player can establish his own noble house/guild/outpost or something. It would also give you a source of income other than "kill things" or "do quests".

I was mostly thinking of the cities and the scheming in them. And then the player character comes and throws a wrench in (if s/he wishes to, you could treat the city as a rest/shop and just go monster hunting and dungeon exploring).

So if you kill Matron X, her family will be mad. Most importantly, you won't see her again. No generic "dark elf leader" NPCs here. If you eradicate the whole house, a new one will rise in their stead.

If enough time passes, you (or the NPCs) are supposed to die of old age, so a part of the gameplay would be finding a way to achieve immortality and/or have a kid. The world won't get empty if the NPC dies since at some critical level, new NPCs would get spawned.

Most importantly, I plan to leverage procedural generation for replay value - every time you start the game, the world map will be different, with cities differently named and placed in different spots, with differing numbers and names of the noble families...

Good work on getting so far and look forward to how it progresses.

I know the idea of a "living world" sounds ambitious, but I have already done (in the T-Engine version, I mean) most of the things (NPCs reacting to your actions, factions, several kinds of quests, in-game lore, having kids, several cities, several noble houses, an in-game calendar). Others, I have seen in other free roguelike/rpg games (Shadow of the Wyrm tracks NPC age, Sol Trader did NPCs with compelling backstories/goals).

[tpelham42]

Thanks for the additional info. I like sandboxes, but I often find sandboxes these days have a bunch of toys, but little direction. I really like the idea of a living world and the player having a direct effect on that world. If there are side quests and player impact that definitely sounds cool to me.

I think the main idea is that it's supposed to be a sandbox, but one in which your actions affect the world. I keep coming back to the idea that the player can establish his own noble house/guild/outpost or something. It would also give you a source of income other than "kill things" or "do quests".

I really like the idea of having a space to call my own in an rpg game. I place I can improve upon over time even if it's static upgrades and not full decorating.

If enough time passes, you (or the NPCs) are supposed to die of old age, so a part of the gameplay would be finding a way to achieve immortality and/or have a kid. The world won't get empty if the NPC dies since at some critical level, new NPCs would get spawned.

So if this is a roguelike will there be permadeath? This is something that turns me off from a lot of games like this. If I'm going to have this big investment in the world I don't like the idea of being able to lose it all so easily. Aging is fine and if I'm on some sort of timer before old age and death then that's my motivation to go out and breed or become immortal.

Most importantly, I plan to leverage procedural generation for replay value - every time you start the game, the world map will be different, with cities differently named and placed in different spots, with differing numbers and names of the noble families...

Procedural generation sounds interesting, but definitely implies an accelerated pace of the game. I, personally, would prefer to maybe see static cities/world, but procedural dungeon areas. This way you can slow down the game pace, but still make things interesting for replay value.

I know the idea of a "living world" sounds ambitious, but I have already done (in the T-Engine version, I mean) most of the things (NPCs reacting to your actions, factions, several kinds of quests, in-game lore, having kids, several cities, several noble houses, an in-game calendar). Others, I have seen in other free roguelike/rpg games (Shadow of the Wyrm tracks NPC age, Sol Trader did NPCs with compelling backstories/goals).

It is certainly ambitious, but only you know what you're capable of. Keeping the art simple allows more focus on game play and function. I think most indie devs have to play that balance game as there is only so much time in the day. You can end up with a really pretty game with little function or an ugly game with lots of function. There are some very popular games that don't look all that great, but have rapidly become classics.

[Zireael]

So if this is a roguelike will there be permadeath? This is something that turns me off from a lot of games like this. If I'm going to have this big investment in the world I don't like the idea of being able to lose it all so easily. Aging is fine and if I'm on some sort of timer before old age and death then that's my motivation to go out and breed or become immortal.

Yes, there will be permadeath, but I am thinking of difficulty levels (again, the engine I used previously had them). If an "easy" difficulty level is not enough, I am brainstorming ways to avoid death.

For now, I have:
* having a kid
* paying an outrageous sum of money and xp for a resurrection crystal (an idea gotten from some d&d site or other)
* having a good standing with your patron deity

(Those three I had in the "mod" version)

I am thinking that immortality/lichdom/vampire-ness would be an effective "final" solution, but maybe you have other ideas?

[The Armorman]

i love you for your 100% commitment to isometric graphics. i would kiss your graphics were they a man

[Zireael]

i love you for your 100% commitment to isometric graphics. i would kiss your graphics were they a man

Haha, thanks 

***
Expect an update every Saturday (CET time).



Pretty debug item creation screen


Funny bug with outline shader


Visibility overlay that allowed me to find a bug in FOV calculations

Changelog for this week:
    Implement a debug menu
    Implement a debug summon NPC option (creates a selected NPC next to the player, with some caveats - e.g. if we're missing the tile for it, we don't spawn to avoid crashing the game)
    Implement a debug create item option (creates an item on the player's tile)
    Implement "egos" in Angband-speak (item magical properties) - for now only for armors, for test purposes
    Spend the rest of the day making debug item menu look pretty
    The debug create item allows you to add multiple "properties" (see above), provided they don't conflict (e.g. you can only add one "material" or one "bonus"). Yaay for my own code, no more problems with a leather armor +1 +3 or mithril adamantine leather armor lol (speaking of, I should disallow some materials based on whether it's a leather or metal item, too)
    Write a function to spawn an item with a defined property (e.g. "spawn a leather armor +1 at x,y") outside of the debug menu
    Shuffle the treasure table/list to a data file (no need for it to bloat the Treasure class)
    Suddenly remember I forgot the outline shader (funny bug along the way) and the Cogmind-style labels above actors/items
    Discover a bug in FOV calculations thanks to the labels code, write a debugging visibility overlay, five hours later discover I had a typo in the "does this tile let light pass" function >.<
    Draw actors only on visible tiles, items on visible tiles or those that were once visible
    Write a wrapper function for a ROTLove library function to muzzle printing the whole Dijkstra map to console every time it was recalculated
    Comment out/remove or move to log many debugging prints (the game initializes noticeably faster)
    Adjust the label locations to prevent them overlapping

I would have done more if I wasn't busy trying to understand the ECS. I think the components would be a godsend for complex stuff such as the actors. But I'm stuck on how to make ECS work alongside inheritance.

For now, still rolling along with an old T-Engine solution for classes based on an obsolete Lua "module" keyword. Haven't found a LOVE class library that would allow multiple inheritance (many of my classes rely on it). Ran into loops when "requiring" stuff a couple of times so started to look at components (see above)...

[Zireael]

I spent the last few days trying to speed up game's startup. I rearranged the loading order, so that actual classes and tiles are loaded AFTER you decide to start the game (since a player could exit at the main menu for some reason). This made the main menu loading almost instantaneous.
I removed some unnecessary debug logging and shunted the 'open log folder' function to a keypress, but still the game starts slow enough (3-4 seconds) to warrant adding some sort of a loading screen.

Here it is:



I tried to optimize it further, but hit a wall:

Code:

 class/Actor.lua   : init  :   21                : 0.694       : 74.62%      :       4     

That's right, creating four actors takes 0.7s... That's no bueno for something that's going to be called a TON of times. Simple maths says 10 actors would take 1,75s, assuming no additional overhead, and 50 actors would be 8,75s.

That's not kosher! I can't figure out how to optimize it further at this point, so I started to look for some alternatives... More on them in the next post (today afternoon or tomorrow)

[Zireael]

An unexpected power outage means this devlog is later than planned.

So, the solution I found is to drop Lua+Love2D.

I decided to move to Python. The reasons?
1) it's supposedly #3 as far as job demand is concerned (http://www.codingdojo.com/blog/9-most-in-demand-programming-languages-of-2017/)
2) used in a ton of non-gaming contexts (https://github.com/svaksha/pythonidae)
3) it's fast
4) has built in classes as well as some other constructs Lua is missing
5) I found some tutorials in my native language
6) after day 1, it's very similar to Lua

At that point I realized I already had a Python interpreter... we used it briefly at uni in Computer Linguistics class.
I had to find a Python IDE as running stuff manually is a PITA because the command prompt closes too fast to let you see what went wrong with your code. I could have brute-forced ST3 or something to launch Python code but after using Zerobrane Studio for Lua I wanted the strengths of a language-specific IDE. I picked PyCharm Community Edition and I'm very pleased with it.

I started looking for a library that would let me draw similarly to LOVE2D (multiple tiles overlapping, tinting).

My first choice was pygame, and I breezed through the libtcod+pygame tutorial on YouTube in 2,5 days. However it seems tinting kills draw performance in this library, so I decided to try pyglet. Right now I have two parallel versions of the code, one using pygame the other pyglet, performance is almost identical (but pyglet looks easier to optimize due to built in batch functions).

***
I am also working on a website for my game, more to promote myself in hopes of getting a job than to promote the game, since it's a $0 game on a $0 budget. The site's hosted on GitHub Pages and since getting Jekyll working is a PITA on Windows, I am teaching myself HTML+CSS to create the page. Currently I have the main page laid out: https://zireael07.github.io/veins-of-the-earth-love-sti/

[Zireael]

Drawing performance with a simple caching solution (load if not in table, otherwise get image from table).
Test case: a 20x20 map (explored tiles outside of current FOV are shaded) with a single AI and the player.

Pygame:
game start: 62 FPS
all map explored, AI out of sight: 23-26 FPS
all map explored, AI visible: 21-27 FPS
all map explored, AI dead: 21-27 FPS

Pyglet:
game start: 9-13 FPS
all map explored, AI out of sight: 8-14 FPS
all map explored, AI visible: 7-10 FPS
all map explored, AI dead: 7-9 FPS

Looks like I'm sticking with pygame. Pyglet just doesn't cut it. Pygame looked bad at first but that simple caching solution improved matters a lot.

***
Currently looking at Java since it's no. #2 as far as job demand is concerned and more used in my country than Python, according to a friend who works in IT.
I will probably make the same stub of a game (20x20 map, one AI, one player) to be able to compare performance between python+pygame and Java and whatever library I'll end up using.

[Zireael]

So as I said last time, a fellow dev pointed out Java means more job opportunities in my country.

I picked libgdx as the library. For roguelike specific stuff, SquidLib goes nicely with it.

My Java (mis)adventures:

Throughtout the week: hang out a lot on Freenode #libgdx IRC channel trying to get help

    Day 1 (Saturday evening): get JDK, Netbeans IDE and Libgdx. wrestle with Netbeans IDE not finding JDK because I had a 32-bit version instead of 64-bit. Get the 64-bit only to have it fail still because somehow the installer didn't set JAVA_HOME environmental variable.
    Day 2 (Sunday): faff about a lot, somehow make a stub of an orthogonal game with isometric graphics. Aaargh why does it have 0,0 in the bottom left?! Player moves, though. And batching draws is very easy.
    Day 3 (Monday): discover SquidLib, run the demo a couple of times, fail epically at replacing the ASCII drawing with tiles.
    Day 4 (Tue): figure out basics of Gradle, set up a new project with only the utility part of SquidLib. Discover that Libgdx has built-in Tiled map loader (roughly equivalent to LOVE2D's STI library), use it only to have half of the map wind up outside the camera. Generate the map by code instead of loading up a real Tiled map. Hack on the tiled map loader trying to fix it and determine what tile I'm mousing over.
    Day 5 (Wed): Bin the hacks. Spend the rest of the day trying to get the game to properly determine what tile I'm mousing over. Figure out basics of camera/viewport interaction thanks to a Spanish tutorial. The game window can now be resized without blurrying and/or stuff winding up outside the camera.
    Day 6 (Thu): Set up a local-only repo for the game. Plug in all the stuff from scratch to have nice looking commit history. Look at github trying to figure out how to rename repos. Update libgdx version to "snapshot" (aka the bleeding edge github version). This lets me offset the map using the new functions without hacking on the tiled loader.
    Day 7 (Fri): Get answer from github help. Bin the non-gitted folder. Attempt to figure out Libgdx's stage/scene2d classes used for the GUI. Figure out that I need to use a different viewport than the non-scaling one used for the game if I want my GUI to stick to the screen positions.
    Day 8 (Sat): Just started.

I'm starting to like Java. Netbeans makes it laughably easy to find/fix errors and import necessary stuff. Libgdx's UI classes seemed scary at first, but they let me do a lof of stuff (buttons, lists, windows, dialogs, tables) without forcing the look or layout on me. The layout is configured somewhat like HTML and the look is controlled by a file that is JSON without the quotes. The only downside is, finding open source libgdx projects is difficult and the documentation is... unclear. Most tutorials are mobile-focused and end up in a flappy bird clone

***

No screenshots to show at this point yet. But I'm fairly confident I can get back up to speed (I mean to the features I had in the LOVE2D version) soon.

I plan to rename the GitHub repository with the original T-Engine version so that the new Java version can use the veins-of-the-earth repo name. With that out of the way, the GitHub page will also live under this repo so the URL will be easier to remember.

[InterGalactic]

These new screenshots in your OP ( top 3) are looking MUCH better than the last 3. It's the use of a really ugly texture I guess that ruins it for me, whereas the top ones don't have that and look more fine / nicely retro.

[Zireael]

These new screenshots in your OP ( top 3) are looking MUCH better than the last 3. It's the use of a really ugly texture I guess that ruins it for me, whereas the top ones don't have that and look more fine / nicely retro.

Unfortunately the textures used in the top 3 came with the original engine I used and the license doesn't let them be used outside the engine.

What is wrong with the stone texture? I took it from somewhere on the net but I'm 99% sure it was taken from Baldur's Gate 1.

[InterGalactic]

These new screenshots in your OP ( top 3) are looking MUCH better than the last 3. It's the use of a really ugly texture I guess that ruins it for me, whereas the top ones don't have that and look more fine / nicely retro.

Unfortunately the textures used in the top 3 came with the original engine I used and the license doesn't let them be used outside the engine.

What is wrong with the stone texture? I took it from somewhere on the net but I'm 99% sure it was taken from Baldur's Gate 1.

Diablo 2:


Bulders gate 2:


Yours:


Because you asked nicely, guess I can elaborate. If you just do a comparison of that to your game right now, even though all these are supposed to represent retro graphics, you can see that the top two are more fine in their choices. Not only is your choice of texture flat, but it also has the colours of green in it, reminding of sewerage. One other thing is that from my eyes which are that of a designer, I can see that the image looks like it has artifacts, suggesting image compression, possibly a compressed jpg or really low res image stretched unproportionately.

Now you mentioned bulders gate 1, well here's a screenshot from that game (below). As you noted, it's not just one flat texture in all instances of these screenshots. There's depth, variation, different embossings to make it seem much more intelligent than just slapping a texture on a rectangle and calling it a day. Also, graphics evolve for a reason, so in my opinion this one looks pretty bad compared to the screenshot from Bulders gate 2.

The best newly developed retro looking games (e.g. Shovel Knight) bring out the good sides of retro graphics and learns from the mistakes made by bad graphic design / ui design / art direction in the past.