How to properly have an idea if your game sux?

This might be a bit off topic, but I invented some board games that do not need all the technology employed in HMH so far to deploy, so this might be really off-topic ... (they need only me implementing the computer playing against me which is beyond my skills as it needs minmax search).

They are just some variations of chess or hex/go, etc. So, no commercial value but that's not the main concern, but having a clue whether they suck as entertainment (of course without the sugary stuff like music, animation, etc).

How do you people who work on games usually have a clue before you show the game to anyone? Something like universal guidelines you keep in mind? I think my games suck but these ideas kept coming.

ps: there are variations of some games that could go as a HMH-like game, but then I'm even more clueless and think they suck even more, so for now I'd just be very happy if any of your would give some very abstract feedback about gauging suckness :).

Have some friends play your game. Do they have a good time? Then it doesn’t suck. 🙂

Having other peoples play it is a good way to know if it's interesting.

But friends are not the best persons to test an idea in my opinion, unless those friends are interested in that specific type of games and are able to give honest feedback without keeping things to avoid hurting your feelings. If you don't have friends meeting those criteria, you may want to find a "community" that fits that description, for example here (or on the handmade network discord as you might not get much feedback in these forums).

While good art and sounds are not a requirement in a early prototype, you still need to have good visual and audio feedback when it's relevant to gameplay. More generally you want to minimize the friction between the player and the game so that the feedback can be about the game and not about the implementation of the game.

Isn't this a bit dangerous tho?

What if someone makes a clone and sell it? That would make me very upset. I think the games really suck, no one cares about board games that much, but people sell stuff that suck on daily basis (not what I'm trying to do, just that the point is if I just release it on discord I have no control of what's going on).


Replying to mrmixer (#25923)

There is always that possibility. But it can happen at any point in the lifetime of your game as soon as you show it (trailer, demo, finished game, "dead" game).

In my (very) small experience the impact of external feedback on an application or game is far more valuable than the possibility of someone copying my ideas. It's more likely that nobody will care about what you're making (unfortunately) than someone copying it. And if you're sure your game is bad, maybe someone will make something good with your idea.

An alternative to a public release of your concept would be to ask people to "register" (could just go through DMs) to participate in the test to keep more control. Once again my small experience with that was a very small amount of feedback.

Copying your game idea will happen whether you want or not. You should prepare for that happening eventually.

Just search on Google Play store "Wordle" or "Flappy Bird" to see how it happens.


Replying to da447m (#25928)

"no one cares about board games that much"

I am quite confused about that statement; why would that be the case. However, if it is really strictly a board game; then why don't you build a physical prototype of it (or create it in Table Top Simulator) before implementing it?


Replying to da447m (#25928)

I did that, I bought cheap plastic pieces and drew a board, but really I'm playing against myself so it doesn't help much.

In reality, I already solved the small problem of defining game rules in an ugly way so I can just edit code and implement different rules in different boards (hexagonal, squared, MxN, didn't try like other tiling cuz just too much complication). I even put sounds, and square highlighting, so it is mildly playable.

But what I wanted to do is to use minmax search to find out if the set of rules candidates for a particular game setup are trivial, by that I mean whether they boil down to some boring dominant strategy that makes the game mechanical/dull. This part is very HARD and my minmax is very dumb and consumes too much resources I still don't know why because honestly I don't know how recursion works in detail in the CPU/cache, and not trying very hard to fix this because I'm still considering if the games are good to begin with.


Replying to Mega Wolf (#25933)

For the ruleset, it is not very difficult.

In abstract way, you define a coordinate system. You will have your logic to move pieces around, also capture mouse in precise "squares" and also draw them.

If they are hexagons, there is a math overhead for that, but that's pretty much it. You define moves according to the degrees of freedom in that particular coordinate system.

So say you have a small fellow called pawn, just make this fellow

struct
    {
        Axis top_left{-1,-1};
        Axis top{0,-1};
        Axis top_right{+1,-1};
    }Pawn_Move_White;

`Axis is just the object of your coord sys that you will make your coord sys logic with

struct Axis
    {
        Axis()                   : q(-1), r(-1) {}
        Axis(int8_t q, int8_t r) : q(q),  r(r)  {}
        int8_t q, r;

        bool operator==(const Axis other) const;
        bool operator!=(const Axis other) const;
        Axis operator+(const Axis other) const;
        Axis operator-(const Axis other) const;
    };

Ideally you want this sort of stuff small because of minmax search.

Ok, back to rules. The first struct is nothing but a "physical" rule set for moves that fellow can perform. As opposed to "legal" moves. That fellow can go to "square" {q,r} physically (poetic license) if it is in square {q,r+1}, say, because top{0,-1} is a move, but it may not be legal if there is another friendly pawn in that square.

So now we define some other layer of legal stuff, who captures who, who can do special stuff with who, and so on and on, all the rules are nothing but a bunch of branching.

Some of them are not so trivial. For instance, if you have something like the Rook in chess (moves in straight "lines"), you want to do a check like this (hope I didn't screw up lol)

static bool rook_path_is_free(GPiece piece, Axis begin, Axis end)
{
    /// trivial case
    if (end == begin) return true;

    Axis diff = end - begin;
    Axis dir = Axis((diff.q>0) - (diff.q<0), (diff.r>0) - (diff.r<0));
    Axis current = begin;

    /// use do{}while(); instead of while(){} because we need to check when current == end
    do {
        current = current + dir;

        if(Board.get_piece(axis_to_idx(current)).id != Pid::NO_PIECE) {
            if (Board.get_piece(axis_to_idx(current)).color == piece.color) {
                return false;
            }
            /// if the piece is an enemy piece before the end square, don't let it move beyond it,
            /// but this check will return ok if the piece is at the destination (end) square
            else {
                if (current != end) {
                    return false;
                }
            }
        }

    } while (current != end);

    return true;
}

And other stuff can get equally complicated, perhaps more.

So that's it for the game logic abstract layer, it is actually fun. There is only some extra complication for me cuz I use bitboards because of minmax search (e.g. axis_to_idx() is such a func that will get the axis and actually retrieve from a uint64 bitboard a color, from other uint64 the piece kind, but that's not necessary to make any board game, prob a map w/ "axis" as key will do??)


Edited by da447m on Reason: more stuff added :P
Replying to Mega Wolf (#25933)

I didn't really answer your question. You have to define what doesn't suck means. The Hollywood answer is, it makes a lot of money. Another answer, it will be original, you will know it when you see it and like it, but it may not make money.

What makes money right now is almost always saturated, so if the incentives were all just simply to make money, that's a big barrier.

What is perceived as original is also problematic. Just look at contemporary art. New crazy things all the time, things you've never seen, thus original. Nonetheless, most of it is just awful?

Maybe a humble tiny thing that is different suffice?

I'm not trying to be coy or arrogant, I do want to make money, just that I'm really not willing to do whatever for it (and also I can't, right? like really, as if I could go beyond my own self).

As a rule, I now write down anything that I think about. But even some of what I thought would be interesting to do are either already done or just suck according to my own assessment.

For example, suppose a sokoban game where the blocks are bongard problems, and what you want to do is to aggregate them according to some other rules that will solve the problem. This is the sort of thing that I think is bad because it is just extra layer of complexity without context. In the case of the board games, being different games is their whole point.


Edited by da447m on Reason: well I think I went a bit overboard there
Replying to Shastic (#25932)

I've been thinking about what makes an idea good or bad, and I think the reason you don't see your ideas as good, is they don't solve any problems.

I don't know the exact reasons as to why I think they suck, they simply do not make me really excited about them. Maybe you are right, but how would they "solve a problem"? That reads more like a technical demand.


Replying to Shastic (#25939)

I get what you mean in general, but these are board games as per OP, there are really no levels and stuff like that.


Replying to Shastic (#25941)

Sorry, I forgot to check in here.

Well, in MinMax you normally stop after a few levels of recursion and evalute how good you think a specific position is (or often, you actually abort a lot earlier if you see what you are doing is either way too bad (e.g. you loose your Queen; that's probably something you won't do) or too good (e.g. you capture a queen); in that case, the player before would not allow this move). However, how to evaluate a game state is obviously super game-dependent and requires you to be somehow good at the game (which is obviously not quite the case when prototyping), you could switch to Monte-Carlo-Tree-Search maybe.


Replying to da447m (#25934)

Yeah,I might have made a mistake somewhere, but honestly I believe that my minmax funcs are correct. Just for the sake of completeness, I'll past them [as-is] below:

constexpr int16_t MAX_EVAL = 25000;
constexpr int16_t MIN_EVAL = -MAX_EVAL;

///Minmax evaluation with alpha beta pruning
int16_t minmax_ab(GPosition& position, uint8_t plies, int16_t alpha, int16_t beta, bool isMaximizer)
{
    if (plies == 0) {
        return get_position_value(position);
    }

    invert_color(GEval::EvalTurn);

    std::vector<PMove> validMoves = get_all_valid_moves(position);

    Pid capturedID;

    if (isMaximizer) {
        for (auto move : validMoves) {
            capturedID = Pid::NO_PIECE;
            perform_move(position, move, capturedID);
            alpha = std::max(alpha, minmax_ab(position, plies - 1, alpha, beta, false) );
            undo_move(position, move, capturedID);
            if (alpha >= beta) {
                return beta;
            }
        }
        return alpha;
    }
    else {
        for (auto move : validMoves) {
            capturedID = Pid::NO_PIECE;
            perform_move(position, move, capturedID);
            beta = std::min(beta, minmax_ab(position, plies - 1, alpha, beta, true) );
            undo_move(position, move, capturedID);
            if (beta <= alpha) {
                return alpha;
            }
        }
        return beta;
    }
}

PMove minmax_root(uint8_t plies)
{
    auto position = Board;

    std::vector<PMove> validMoves = get_all_valid_moves(position);

    /// assert((!validMoves.empty() && "no valid moves in minmax_root"));

    PMove bestmove = validMoves.back();

    Pid capturedID;
    perform_move(position, bestmove, capturedID);
    int16_t besteval = get_position_value(position);
    undo_move(position, bestmove, capturedID);

    for (auto move : validMoves) {
        capturedID = Pid::NO_PIECE;
        perform_move(position, bestmove, capturedID);
        int16_t eval = minmax_ab(position, plies - 1, MIN_EVAL, MAX_EVAL, false);
        undo_move(position, bestmove, capturedID);
        if (eval > besteval) {
            besteval = eval;
            bestmove = move;
        }
    }
    return bestmove;
}

Edited by da447m on
Replying to Mega Wolf (#25951)

I normally prefer the NegaMax variant; that's easier to read since on does not have two different cases.

Does the invert_color function do something to a global state? If yes, I somehow have the feeling that one should invert back when leaving the function again, no?


Edited by Tobias Wolf on Reason: Typo
Replying to da447m (#25953)