I just tried it out. Reminds me a lot of Stardew Valley. The menu is a little strange, but once I figured it out it was easy to use. Considering the fact that there’s no start or select, the menu is pretty good. Nice job.
@North I played this game last night in the emulator on my phone for a couple of hours. I love it - thank you.
I didn’t get very far exploring the map as I went quite far once, got a bit lost and couldn’t find my way back. I decided to hang round the farm for a while after that! I really like the interface and can only think of a few conveniences that could improve it (but not suggesting they be done as I don’t know how to implement them!). I would love to see a game like this with expanded assets, farming options etc with the FX chip or a larger memory processor. Perhaps even the ability to improve forested or rocky areas of the map to make them suitable for farming.
Sheep are really well implemented. I thought I would reach the point where I could shear them all, sell the wool and buy a new sheep the same turn and reshear all the sheep, including the new one, on return from the market (they all get new fleeces when a new one is bought). Then go back to the market and sell the fleeces again and buy another sheep, beginning the process again within the a single turn. But the max sheep limit stops that from happening, which is a good thing.
Yep, I could improve the sheep part… but after the fifth sheep you should have everything that you can ever need (available in-game) so… I think it is fine like that for the moment .
I will come back eventually, I do want to clean the code, free some memory space and improve the menu system… as a “final revision / version”. After that I may create a new game (same theme) and try to use the FX expanded memory to add all the things I wanted.
I had a lot of ideas for the game, including bosses, a second area (besides the forest), different enemies, music, house upgrades, and so on… but I managed to use all the space with the basics stuff…
But I will come back at one point, so all the feedback is welcome, so thank you again!
@Pharap showed me a really nice way to enable the menus to be continuously scrolling, rather than “hitting an end stop”. I don’t know if you have the memory space but if you make the menu items part of an enum class then you make a custom increment and decrement operator that wraps around to the beginning of the class if you try to increment past the end or returns the last item if you try and decrement below the first item.
Then, in use, you can just use the ++ or - - on your enum class object and it will not need further code to manage wrapping around.
I have a request / comment that the menu remembers the last item you had selected. So, for example, if you were buying large seed packs then you don’t have to scroll past all the smaller seeds every time you go to plant.
The other convenience feature I was wondering about is to do with the “cursor” or where the planting tile is, relative to the sprite. In the case of the sword, its the tile where the sword sweeps into. I found myself having to plan ahead and line myself up from a few tiles away to get the cursor where I wanted it, when planting, shearing or fighting. I don’t know if it’s possible to query a “tool in use” bool and instead of moving the sprite on the first direction press in a given direction, move the cursor or “turn” the sprite on the spot. A second dir press in the same direction would then make the sprite move. If you didn’t want to turn first, it’s easy to stop using the shears / sword / seeds and then travel.
I don’t want to criticise your game because I think it’s brilliant but you seem open to suggestions for a release version, so please take my comments in a constructive and positive way.
I made the changes and I will upload it now to this thread. The only part that is a bit tricky is the movement… If you could give me feedback again (with this new version) will be nice.
Maybe It only makes sense when using the planting tool (for example).
The changes are:
Minor life quality improvements:
In-game menu options now circle around (allowing immediate change from last to first item)
Tool and seed current selection is no longer reset when exiting the in-game menu
Using any tool now changes the way the player moves:
First click will change the player orientation
Same orientation movement and holding makes the player move in that direction
Clicking back when holding a seed will send the user to the seed selection, instead of the tool selection
Minor tile changes and menu changes
Added a ‘Simon’ bird (name not in-game, so don’t worry… will only appear in a new game)
Thanks again!! good to see that you like the game.
You don’t have to use a scoped enumeration (enum class) to have ‘wrap around’ functionality in a menu.
As ever, there’s more than one way to do it, each with its pros and cons.
I tend to prefer using scoped enumerations (on Arduboy at least) purely because it means you end up working with meaningful names instead of meaningless numbers. That’s especially useful if you’re handling your menu logic with a switch, which is often the case on Arduboy because it’s cheaper than most other options.
It can also be done using plain functions rather than overriden operators, but I think most people would find using ordinary functions to be more verbose.
E.g. option = nextOption(option); versus ++option;
Personally I don’t mind either, but the latter is also harder to get wrong.
enum classes are enumerations rather than classes.
The existing keyword class was chosen to differentiate enum class (scoped enumerations) from enum (plain enums) rather than introducing a new keyword. Every time the committee creates a new keyword there’s a chance it will break existing code.
(Technically enum struct is also valid, but I’ve never seen anyone use it. I expect most C++ programmers aren’t even aware it’s legal. That’s one of those bits of trivia only a madman like me would know. :P)
Thanks! using enums will be nice indeed, but changing it now is a bit complicated… If not planned from the start is tricky… (right now if I change it, will easily exceed the memory limit, sadly). Please don’t judge the code quality too much xD thanks! (not that you did, I’m just joking :d )
I have the arduboy FX, maybe I can start checking it out… I miss having unlimited memory…
Enumerations should never be more expensive than plain integers because they’re implemented internally as plain integers.
But if you’re trying to use them to replace a uint8_t rather than uint16_t/int16_t then you have to rememeber to use : uint8_t to force the enumeration to only be 8-bits wide. If you don’t specify how big an enumeration should be it defaults to being the size of int, which is 16-bits wide on Arduboy, which is almost never what you want.
// Will default to the size of int
// Thus (sizeof(PauseMenuOption) == 2) on Arduboy
enum class PauseMenuOption
// Explicitly forced to be the size of uint8_t
// Thus (sizeof(PauseMenuOption) == 1) on Arduboy
enum class PauseMenuOption : uint8_t
Yes, it would be impractical at the moment because you’re using inheritance for your menus.