Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags

Sam

7
Posts
2
Followers
1
Following
A member registered Aug 03, 2021 · View creator page →

Creator of

Recent community posts

Thanks for the review. The game is definitely very confusing and painfully slow at the moment. One thing worth mentioning is that pathfinding can randomly lag it even more due to your partner spawning somewhere the game finds hard to path, so it's possible that you got an ultra slow load, but even if not, it is just an impressively slow program due to a menagerie of reasons I know about, all of which are my fault. If you look in the map code (roguemap and map_scene), you will be able to see some of the reasons why it is slow, and you will possibly feel a little angry with me for writing it that way. In my defence, I wrote that code for a project with an endless map with the intention of optimizing it later, and the reason it's not currently optimized is that the lag doesn't annoy me personally as much as the absence of such critical planned features as poetry-based gameplay, career-ending injuries, fetch-quests, and abandonment by your team.

(1 edit)

Thanks for trying it. That's an interesting bug. I'm not sure how your current monster got set to None, maybe it's an issue where I forgot to set them to rez after you lose and then when it starts a battle in that state, it looks for someone to put in first but can't find them... I've written a lot of patches since the 7drl release but I'll double check that the bug doesn't still exist.

Edit: I was wrong, it was a much less complex bug where the whole "if self.opp_tag:" block in battle.py tries to tag in the player's monster instead, but none is specified. There's such a lot chance of opp tagging that it never came up in testing. (Which is why I should write unit tests I guess...)

Thanks for giving my game a go despite the janky distribution method! Dang, that's a weird one. The only thing I can think of that could be wrong is that blessed might be installed in a different virtualenv or on a different version of python. For example, on some systems the python 2.7 executable is called python and the python 3.x executable is called python3, with pip and pip3 respectively installing packages to them. If that's the case, running pip3 -r requirements.txt and then python3 main.py should fix, I think. For virtualenv, I use virtualenvwrapper so for me the workflow is mkvirtualenv --python=/usr/bin/python3 tournament-arc; workon tournament-arc; pip install -r requirements.txt; python main.py

I'm working on a post-7DRL release with binaries for each platform

The game is not correctly labelled as being only for Windows (no platform is indicated)

I get "error while loading shared libraries: libtcod.so: cannot open shared object file: No such file or directory" when I try to run the game, which is weird, because it's in the same folder, and I also have it installed on my system.

The concept is pretty interesting, and the feel of the game is good. It feels quite roguelikey for something made in love, which I enjoyed, and the writing is good. I didn't intuitively pick up what was happening in interactions when I started playing, but it feels like there's quite a bit to explore there, so I'll be coming back to it. The game produces an unresizable windows that's too big for my small screen though, so I have to do something really weird to peek at the hints for the controls. Downscaling would be much appreciated.

This game is a good example of what people should do to succeed in the challenge, in my opinion. (An example of what not to do would be my own submission :D)