Messages

1

7DRLs / [7DRL 2018] Search for the Crown

« on: March 22, 2018, 05:52:00 AM »

My incomplete entry for this year. Go with a team of explorers (and bloodhounds) to search for the Golden Crown in a trap-filled dungeon. It can be played in the browser here: http://aquatsar.itch.io/search-for-the-crown-7drl

I considered it incomplete because the game just feels unbalanced and unpolished. It's probably my best entry so far though. The version currently on Itch.io has a recent patch that fixed the controls and some bugs that made the game unwinnable in certain circumstances.

2

Early Dev / Re: Harvest Moon style Roguelike

« on: February 20, 2016, 06:14:52 AM »

Since the author also knows about Rune Factory, combat is a viable option for this game. How boring the farming part becomes depends on how much players like the original grindiness of Harvest Moon (which could be added to this game) and how much the farming connects to the rest of the game. As much as I liked Rune Factory, the farming parts tended to be disconnected from the combat. At best, you used the farm plots to get money, advance the storyline (and open new areas), or recharge stamina. The latest Rune Factory may have added other stuff here, but it would be interesting to see farming take on a stronger role.

Alternatively, the farming could itself become more of a puzzle. Perhaps you need to plant things in a way that protects them against disease or provides optimal growth. Perhaps you need to arrange the farm plots so that they get water from limited sources or are defended against wild animals. Maybe what you plant one season affects what else goes there. And so on.

In Harvest Moon, farming itself was usually the goal instead of a means to obtain something else. In most roguelikes, combat is a means to obtain the goal (getting the shiny object back or killing the final boss). So the farming could be made more interesting by making it the means for obtaining some other long-term goal.

3

Early Dev / Re: Harvest Moon style Roguelike

« on: February 18, 2016, 03:03:43 PM »

As the creator of HarvestRL (which I'm still working on to some extent) I thought I'd offer some suggestions. Note that I have not tried your game yet, so these comments might already be resolved.

Although Krice could be trolling with his comment, potential boringness is actually something to take seriously. For example, in Harvest Moon/Rune Factory you use a tool by pressing a button and the direction in which you face. So, your character is facing left, he's holding a hoe, and you press a button to till that tile to the left. Then you do this X many times and you're done that task. I attempted to automate this; in HarvestRL, you equip a hoe and then walk onto a tile to till; if you can till it, your character automatically does so. Likewise with watering and harvesting plants. The effect of this is that the task of watering/planting feels much different than in the original game, most obviously because it is faster. I'm attempting some other improvements on making the farming aspect "faster" in terms of button presses and such.

Part of my concern is: if I remove those actions then what is left of the game? Did players enjoy the grindy feeling of repeatedly pressing buttons to water/plant? Or was there something more they enjoyed? While it is definitely possible to just take Harvest Moon and add procedural generation to the landscape / dungeons, you may want to consider how the farming itself is done.

Oddly enough, many of the arguments surrounding the grind of Angband and such games are completely applicable to the non-combat aspects of Harvest Moon. Is it fun to "improve" relationships with townsfolk / potential spouses by repeatedly "talking" to them every in-game day? Could something else be done to make that more fun, or is Harvest Moon enjoyable specifically because of that grind?

There's another game (whose name I forget) that is a farming simulator / tower defense (not Plants vs. Zombies). You farm so as to gather food / materials that are used to strengthen the town and improve the defenses of your farm, and then fight off zombies during particular times. This is not Harvest Moon, but it is something that tried to add on to the farming aspect to make it more interesting / enjoyable. I'm not suggesting you use that idea, but that you consider the "why" behind the farming, even down to every button press that needs to be made. As much as I love Harvest Moon, I quickly tire of the grind; I suspect other people feel the same way. HarvestRL I wanted to enjoy without the grind and I'm still figuring out how best to do that.

4

Design / Re: Sorting order of inventory

« on: November 09, 2015, 03:33:06 PM »

The first category should probably be whatever the player uses most frequently. If it's a game where the player has to regularly switch weapons and armor then that should be first. Otherwise, commonly used consumables should be first (such as wands/staves, or maybe potions if the game has a lot of these).

As an example from Brogue, I tend to use potions and staves far more readily than anything else. Throwing items fall just behind that, then scrolls, and then pretty much everything else (I don't change equipment often). If that is the common playstyle of the game (based on how the item mechanics are designed) then that should be the order of items. However, if a game allows many different playstyles, or a large quantity of items that the player can figure out what to do with, then the game may want to auto-adjust the categories based on what the player uses most frequently (and save that for future plays).

Regardless, do not change the hotkeys for specific items. I don't want "m" that was the key for a wand to suddenly change to a scroll. That would be pretty disastrous.

... it could also be annoying for people who like to have a fixed order of item categories.

Easy to fix. Just have the auto-sorting of categories be turned on/off by a checkbox in the game options, and allow the player to customize the order of categories. Some players would prefer pre-defined categories, so that they don't have to do anything, while other players would rather organize it themselves. Allow both and everyone is happy.

5

Traditional Roguelikes (Turn-based) / Re: Roguelike Archive

« on: November 09, 2015, 03:02:08 PM »

Regarding the method used for compression, if you can include a copy of the compression program then it's largely irrelevant.

For example, if you use 7zip, and 7zip allows distribution of the executable in such packages, then just include a copy of the 7zip executable in your archive (perhaps in the root folder). That way everyone would be able to decompress the files you include in this package, regardless of whether they have a copy of the program already and regardless of whether the program is still even available (such as in the distant future).

6

Design / Re: Thoughts on this "Hunger" system.

« on: August 29, 2015, 02:42:31 PM »

There's also the issue of how you get food/water, and how much of it exists. In the original Rogue, food was a fixed resource; it was not infinitely generated. So it served as a clock against grinding and an overall game timer.

Alternating food and water per floor is fine, but this just means any one resource has to last two floors--their current one and the next one--or the player may feel rushed (which could be appropriate). Both of these clocks will fail if the resource is too abundant. Since thirst ticks down faster than food, the player has less time to spend on the food floors (since they need to get to the water floor faster). This is just something to keep in mind for when you generate food/water.

The colors you're using for the hunger bar also seems very similar to the background color. You may want to change that, or add a border around all the bars to more clearly distinguish them from the background.

While I like the idea of having two states (hunger then starving, thirst then dehydrating) do you think it'd be better to have two bars for this? Couldn't you have 150 hunger, and then when it gets down to 50 it changes to starving and drops faster? My concern is the difficulty interpreting the hunger bar at a glance, since it's in the same place. Maybe the two bars would be fine if the second bar was more obvious (e.g., it blinks or is a brighter/more obnoxious color).

7

Early Dev / Re: Rogue Harvest Extended

« on: April 22, 2015, 04:16:09 AM »

Thanks, it's fixed now. I'll make another post there soon once I get a development plan worked out. Although I think a feature list isn't particularly helpful, a feature list that is sorted in order of preference (with an estimated timeline) could be helpful and might actually be interesting for people other than myself. Especially now that the mouse stuff is done.

... of course I want to redo the UI again but I'm going to resist the urge. Otherwise, this game will languish like my other RL projects.

8

Early Dev / Rogue Harvest Extended

« on: April 20, 2015, 04:58:53 AM »

With the 7DRL HarvestRL done, even if it is really unbalanced, I'm remaking it and extending it in a way I wanted the game to be originally. I'm starting with UI changes, so that I can address some of the major complaints of the 7DRL version and improve accessibility. Once I get those changes complete, I can start working on mechanical changes (such as better monsters, more meaningful / less tedious farming, actual villagers, etc.).

I don't have much to report at the moment except how the new Inventory screen looks/works. Those brown button-like things are clickable buttons, though I think the brown might be a bad color choice. Mouse targeting for throwing doesn't work yet; improving the targeting for ranged effects is next on the agenda.

9

Early Dev / Re: High Tech Survival

« on: April 07, 2015, 04:05:55 AM »

Btw. What information about words is needed for proper localization?

That is a huge topic. Do you mean any word or just nouns (e.g., items, terrain, creatures)? For nouns, your list should be fine: plural form, gender (male, female, neutral), and article ('a' or 'an'). However, you may need to care about their position in a sentence, depending on how you localize such phrases.

p.s. Probably detailed information about how to connect machines can be presented in form of manuals on the bookshelf in the cockpit?

You could store them there, but first-time players may not think to look in the bookshelf unless explicitly told to do so; and in that case, why have it in a bookshelf and not a help menu? Perhaps the books could give the basics and hints regarding specific arrangements, but the basics are always available in a help menu.

10

Early Dev / Re: High Tech Survival

« on: April 06, 2015, 03:25:56 AM »

Isn't it a bit too harsh?

It depends on what you want to include. Obviously surviving on the side of Mercury that always faces the sun would be very different from surviving on some plant- and water-rich world with normal temperatures. Simply having running water available (or animals to catch for food) makes that resource far more trivial to obtain.

Different starting gear could be a good idea for this, or you could require different equipment that varies in power-usage or maintenance. Perhaps when there is running water on the planet surface you just need to hook up a filtration unit, but it needs regular replacement of filters (that you need other resources to make). In contrast, the water condenser for worlds without running water can be placed anywhere and doesn't require maintenance but it uses a lot of energy. Similarly, on worlds with harsh temperatures you don't have animals but just need to limit your time out in the sun (or something); worlds without harsh temperatures with animals means you have to deal with annoying creatures that might disrupt or steal machines.

Balancing your tools and machines this way might be another way of keeping the hazards roughly the same in terms of difficulty, but still vary in interesting ways. Or you could just assign a "danger" level to things and ask the players at the beginning of the game how difficult they want it. (i.e., how hard of a planet do you possibly want it to create?)

11

7DRLs / Re: HarvestRL - Success?

« on: April 06, 2015, 03:13:14 AM »

Thanks for the comments! I agree that the game needs more work in several areas.

I don't plan to implement run (or auto-explore for that matter), but I do want an auto-travel (between important places) and "move-to" function (select a tile and move there). Neither run nor auto-explore would be needed if the maps weren't so huge, so I think shrinking the maps and making them more interesting is a better design decision. And mouse support... that would help a lot.

The farming is similar to how it's done in Harvest Moon, minus extra key presses, but I think it could be automated better. Perhaps you designate the area to water, plow, or harvest and your character just does it (similar to auto movement and such). That would allow you to spend more time making decisions with it, such as choosing what to plant. At the moment though, those choices aren't sufficiently interesting (even in Harvest Moon/Rune Factory they aren't particularly meaningful). Having food differ in terms of how much needs to be eaten, or having plants provide different benefits, would make the farming something more than a chore.

I wanted to keep limited HP so that combat was still interesting, but that definitely failed due to the way combat actually happens. I'll have to experiment more with this.

12

7DRLs / Re: HarvestRL - Success?

« on: April 04, 2015, 06:54:30 PM »

Well, my fixed version still had bugs preventing you from finishing the game. Those are now fixed, so the game is finally in a fully-playable state. The new version is available here for those interested.

I plan on improving the UI and game overall, but it will be a different project I think.

13

Early Dev / Re: High Tech Survival

« on: April 04, 2015, 02:15:19 PM »

Deserts are not necessarily hot, they are just extremely dry (very low to no precipitation, no or extremely rare vegetation). The polar regions and high mountain plateaus are often called deserts for this reason, even though they are not hot.

On that same topic, collecting water from dew sounds good but you could also collect rain water. This could also be automated if you want, having dew or rain collectors or you have to manually do this by using barrels or nets. If you just had a method by which precipitation falls at various points in a day (depending on the frequency of rain) then you could also change the type of precipitation based on the planet. For example, there is precipitation on Venus but it's not safe to drink nor even safe to be standing in (photos from the Venera spacecraft on the surface showed parts of the probe had melted off and were lying on the ground). This way you could also require water filtration on some planets and have it unnecessary but helpful on others (to avoid harmful bacteria or something).

Hence, you could have hostile environmental conditions to avoid: sandstorms to damage machinery, acid rain, daylight being too warm for your suit, electrical storms that could disrupt your equipment, etc.

Your on-board ship computer could provide a synopsis of the dangers of the planet, and you could augment it with additional sensors for tracking weather or something.

You could also grow small plants, algae or moss for oxygen and possibly food. If your planet lacked soil, perhaps you could process plenty of rock with other chemical elements to produce some. Alternatively, you could try aquaponics (growing plants in only water) which would work out great for algae. Combined with a bio-reactor for energy, you'd be able to harvest plenty of necessary resources assuming you had a surplus of water.

For developing this, I would start by hard-coding the type of planet and getting all possible sources working there. For example, start with a barren rock planet with no atmosphere (and hence no precipitation). Add in the ways to get oxygen, food, water, and energy. Then change the soil type of the planet. Then, add a faint atmosphere with wind and some of those effects. And so on. By the time you get to a jungle environment (the more interesting one, with animals and such) you would already have a large suite of working possibilities for resources, so you can focus on the animals [basic plants and insects don't need to be in a jungle so you would've developed them already]. For releases, whenever there is more than one planet type available just randomly determine which one is used; for development though, I think it's best to hard-code the one you are working on so you can test and expand it.

Although you could just randomly assign values to things like atmospheric-oxygen-content or surface temperature, these values could be calculated from more abstract concepts (e.g., planet density, distance to sun, orbital rotation speed for length of day, atmosphere density and composition, etc). Again, gradually add the possibilities of these and expand on them; start with the worst circumstance (no atmosphere, tidal locking for permanent day/night, etc.) and add from there.

14

Programming / Re: Different methods for loading/saving

« on: April 02, 2015, 01:37:02 AM »

Regarding the chest issue, you could also just have a separate PRNG for such things. One could be for terrain and/or rewards, while another could be for combat results or spawning. This way, the player won't change the rewards of a chest by saving the seed and then moving around.

On another point though, most RLs with permadeath do not keep the save files after they are loaded. The kind of behavior you're talking about would actually be save-scumming, since otherwise the player wouldn't know what was in the chest and choose to move around in the hopes of getting something better.

15

Programming / Re: How do I actually use libtcod?

« on: April 02, 2015, 12:53:50 AM »

Can you describe what and where from had you downloaded to get such version?

All I did was: uninstall and remove my previous version of MinGW, get the latest version from http://sourceforge.net/projects/mingw/files/ using the "latest version" link, used the downloader to install it, used MSys to download the latest version of the source for libtcod (likely 1.6.0), and tried to build it. I only ran into the compile problem mentioned by OP, and did the workaround suggested in the link (added a compiler flag to the libtcod makefile), and then had no problems.

My comment about older versions of MinGW stem from me trying to find particular versions of it when I suddenly have an urge to program C/C++ after a year or three of not doing anything. I've resigned myself to just using the latest version, which isn't necessarily bad. I just found this particular bug with MinGW most annoying/amusing since I just noticed it on the final day of the 7DRL challenge.