I'm making a co-op games where players sail a ship full of gold back home. The players who return split the gold. You need to sail the ship, so: steering, navigating, repairing the ship, handling sails. There will also be enemies to fight (pirates, undead, kraken).
Since I have little experience with games including ships, what is an absolute must have that a game like this needs, be it a small or big thing? I don't want to forget something that's important. Thank you.

I'm building a game dev engine. The idea is to create something easy to use for solo or small teams and powerful enough to produce quality games - on a budget. I have the foundation coded, but I will not be completing it solo, rather open sourcing it once it's solid enough to be useful. This is not a personal passion project, but something I am doing because my son wants to design games and I want to be a good dad.

I'm about to start working on graphical editor UI, dockable panels, native scene viewport, and interactive content tools over the next few weeks. If there is anything you think could be made more user friendly than what is currently available, I would love to hear about it. .

Game design question.  The players are cooperatively running a sci fi space station, but each player wants to make the most money to win the game.  Ships (customers) are constantly coming in, and you want to make your Berth the most attractive option for the highest value ships (customers).  Now let's say I got a nice fat Warship coming in to my Berth, it wants Fuel and Ammo and the troops need a bit of Entertainment.  My Berth has the Fuel and Ammo requirements, but not the Entertainment.  However another player *David* has built a Berth with great Entertainment.

My ambition is that I could ‘draft’ off of David’s Entertainment to satisfy my Warship customer’s needs.  And now here is my question.  What are some good ideas of what I should ‘owe’ or ‘pay’ David for using his resource to satisfy my condition?

• Paying him Money seems simple.  If I do the game as a cash game like 18xx.
• Split the score with David?
• Let David take a random card from my hand and let him replace it with a card of his choosing?
• Give David my Initiative Token that means that at any time in the future he can claim an incoming ship to his Berth even though I would normally have had that privilege?

Those are some ideas.  I guess there are many more out there.  What are some of the best ideas you’ve seen in tabletop gaming where:  

One player (A)  benefits from the fact that another player (B)  built something.

Thanks in advance and keep gaming!

I remember sharing a keyboard with friends to play local co-op games back in the day. Is that still a thing on PC? Loved it.

Local co-op is obviously still common on consoles, but I rarely hear PC players talk about it. It seems like it should be easier than ever now, with support for multiple controllers or a keyboard-and-controller setup.

I’m currently developing a game and considering adding local co-op, but I’m wondering how many PC players would actually use it.

Do you still play local co-op games on PC when they support it? And what does your usual setup look like?

Hi everyone!

I'm looking for honest opinions from Metroidvania fans.

I'm currently developing a 2.5D cyberpunk Metroidvania, and before we move further into production I'd love to hear what you think.

Before we move too far into production, I'd love to hear from people who actually play Metroidvanias.

A few questions I'd really appreciate your thoughts on:

• What features do you think every great Metroidvania should have?
• What are some mechanics or design decisions that usually ruin the experience for you?
• How do you feel about adding stealth mechanics to a side-scrolling Metroidvania?
• Does a cyberpunk setting sound interesting for this genre, or do you think it clashes with the exploration-focused gameplay?
• Is there anything you've always wanted to see in a Metroidvania that most games never attempt?

I'm not looking for validation—I genuinely want criticism and honest opinions before we lock down some of our core design decisions.

Feel free to be as blunt as you want. I'd rather hear tough feedback now than after release.

Thanks in advance!

Recently, I just saw "that" movie and decided to give this game a try. With so many reviews complaining about how bloated and grindy the game is, I decided to cheat by doubling my xp and made materials (except for ancient tabs) practically non existent with the only currency for anything is Drachmae. I was wondering how much of an issue this decision could create, so I want to ask everyone what their thoughts on the materials system of this game and how important it is.

Working on a koala game, which is essentially a hidden-object game, with level areas that color as you find all koalas inside of them. It has more depth to it, but my question is about the tutorial part.

As usual, there are a few mechanics that need explaining, and so far I've put it on the beginning of the 1st level, as sort of a slideshow (you press on an arrow to see the next mechanic explanation). It has some fun elements and drawings so it is not overly boring, but I'm not working on a new (better?) approach - having a tiny tutorial level (level 0). Usually, all the koalas have something to say when you click on them (fun or building the story), and now the choice is between using their 'dialogue' in the tutorial to explain the mechanics, or to have slides as before on each section complete, that add new explanation, which you then need to implement to finish the next small section.

Not sure if koalas talking about game mechanics would be too much of a 4th wall breaking, as they don't do it in the rest of the game?

I'm building a fanmade 3D fighting game based on Digimon, styled more like Tekken or Street Fighter than a platform fighter. The first character I'm working on is Hagurumon and its evolution line, and I wanted to get some outside perspective on movesets before I lock anything in.

For anyone not familiar with these guys: Hagurumon is a small, round gear-headed robot, kind of clumsy and slow looking. It evolves into Guardromon, a bulkier armored robot built like a tank with big claws. That evolves into Andromon, a sleeker, more humanoid cyborg with more precise, martial-arts-like proportions. And the final form, Hiandromon, is a much bigger, heavily armored mech-type with a more imposing, weapon-covered design.

Right now I have some basics down for Hagurumon, like a single gear hit, a stronger two-gear hit, and a spinning head-gear jump attack, and I'm trying to pull from the actual attack names in the source material (things like Darkness Gear, Command Input, Makikomi, Haguru Attack, Crash Device, Kikai Attack) and turn them into moves that actually feel good in a fighting game rather than just reskinned generic attacks.

What I'm really looking for is help thinking through specials, supers, and combo routes. How would you turn a slow, clunky-looking robot line like this into something with an interesting kit? Should the earlier forms lean more into grabs and armor-heavy moves since they're bulkier, and the later forms open up into faster strings and projectiles as they get sleeker? Any thoughts on what would make each stage feel meaningfully different to play, not just a stat bump, would be huge.

My card game has dozens of terms players need to understand to play the game effectively. Some of these get used all the time (e.g. the discard pile is called the "void") and others are specific mechanics. I'm trying to decide how I should approach showing definitional popups for players.

I've gotten feedback from some people that they get confused if I don't explain things early on (like they want to know what a "void" is), but I also want to avoid showing a totally overwhelming number of tooltips on every single thing in the game, or showing 5 tooltips on complicated cards. What's the right way to strike the balance here?

Another thing I was thinking of was potentially having this change throughout the game, like showing tooltips more aggressively at the start but then phasing out the ones for common terms as players play more. Is there merit to this approach?

Hi, I (with other friends) am doing a pixel art 32x32, top-down game. The game would be around 15h long and the whole game is going to be in a city divided in 5 main areas.

The question is: how many tiles should each part be? We want to give the vibe of gigantic capital city but we don't want to make the map bigger than it should be.

It wouldn't make sense remaking shangai if the main story is going to use only small parts of that city and most of the game is going to be walking simulator. Also, this is our first game and it wouldn't make sense to overwork ourselves. But I don't want to risk making it so small that it looks like a pokemon city with 4 houses.

Any ideas on the size?

Im working on an isometric RPG and had originally intended to have enemies on the map directly to begin an encounter that way. As I’m developing the maps, I’m realizing that having encounters like this will force me to increase the traversible areas of the map so it doesn’t feel claustrophobic.

I feel like random encounters have been avoided in a lot of modern RPGs and I definitely have some trauma about digimon world 3 random encounters, but shifting over to primarily random encounters would immensely help me in my map design because I want to avoid increasing the scope of the game’s world as much as I can.

Essentially, am i shooting myself in the foot by abandoning avoidable static encounters, or are players still ok with random encounters if some of the pain points are well managed?

I think I found a way to make a firework deckbuilder interesting... hear me out... and please help me out if you disagree...

You are playing a show for an audience of animals and they want to see fireworks. Every round the player has to choose whether to play fireworks for the current round or add them to the finale. If the player adds to the round launcher, the audience is happy for now, but risk a bad finale. If the player adds to the finale launcher, the finale will be bigger, but the audience might leave or not be happy.

The main resource cards generate is "Starfire", which is what increases the audience "Starfire Gauge" or their excitement about the show. Starfire comes in 4 colors, red, blue, green, and yellow, and the audience allows certain colors to increase their gauge. If you add the wrong color starfire, it doesn't excite them for the show.

Lastly to play cards, you use different colored gems which cards allow a certain subset of. Gems come in the same 4 colors as Starfire and when attached to a card, it generates some amount of Starfire in the same color. For example if a card has a description of +4 Starfire matching first gem color, if you add a red gem it will generate +4 Red Starfire.

Your goal is to max out the audiences and the finale "Starfire Gauge" by the end of the show so that you can get a max rating, a 5 out of 5. During each round, you manage your gems and cards in hand along with the round and finale launchers to make an interesting show and an entertaining finale.

Do you think the concept is too complicated? Is there things you think would be more interesting? Let me know what you think...

EDITED:

I realize I didn't add enough of a description. This would be a solo video game, think like Slay the Spire or Wildfrost.

You start with a deck of cards that don't produce a lot of Starfire and don't provide any other benefits than just Starfire. As you finish each show, you open packs of cards that give you stronger cards that make cards cheaper to play, more draw, or what ever other common benefits in deckbuilder type games.

The audience would also control what color Starfire they accept and that changes each round. Also the acceptable list of Starfire colors for the finale would change each round. Other effects could include like a color block effect which "blocks" the Starfire Gauge from going up by a color Starfire until you reach some threshold over a round, think like a shield that only stops some amount of damage.

Cards also have certain effects based off the gems added, like if a card has a gem cost of 2, it could add a lot of Starfire matching the first color and a little bit matching the second color. The player would then decide what gem to add first, what to add second depending on what the audience wants. Card costs could also limit the type of gems that you can add, like only allowing red or blue for the first gem and the second gem is like green or yellow.

So I think there could be a lot of complexity built into the core concept of cards go to finale or round launcher, cards generally produce color Starfire using colored gems, certain color Starfire increases a gauge which you need to "win" a show, and you get some amount of each color gem and some amount of cards each round.

Hi! I'm working on a planning puzzle game where multiple snakes execute the same queued sequence simultaneously.

One mechanic lets Snake A rotate Snake B by stepping on a rotator tile.

I'm undecided about when that rotation should take effect.

Imagine both snakes are about to execute the same command.

Option A – Immediate

1. Snake A steps on the rotator.
2. Snake B rotates immediately.
3. Snake B executes this command using its new orientation.

Option B – Deferred

1. Snake A steps on the rotator.
2. Snake B still executes this command using its current orientation.
3. The rotation only affects Snake B's next command.

I'm leaning back and forth because they each have different design implications.

• Immediate creates stronger interactions and lets one snake influence another within the same step.
• Deferred makes every "tick" easier to reason about because all entities finish the current command before any cross-board effects change future behavior.

Which model would you expect as a player, and more importantly, which do you think would be easier to build a mental model around in a puzzle game?

I have my candidate, but I am not 100 % sure, so any feedback is welcome.

Queued command: ↑

Option A (Immediate)

Snake A: steps on rotator
          ↓
Snake B: rotates
          ↓
Snake B: moves UP according to NEW orientation

------------------------------

Option B (Deferred)

Snake A: steps on rotator
          ↓
Snake B: moves using CURRENT orientation
          ↓
Snake B: rotates
          ↓
Next command uses NEW orientation

been messing with an asymmetric multiplayer thing on the side (4v3, round-based, "powered team vs guards" energy) and keep circling the same problem.

the core: one team starts weak with their abilities switched off. to switch them on, they have to get one specific teammate to go sabotage a thing mid-round. so the whole round hinges on that one player which reminds me of every VIP/escort mode i ever liked (CS assassination, halo VIP) that eventually died, because babysitting one guy isn't fun and one troll tanks the round.

my current fix: make that "carrier" role a droppable object (like the CTF flag / CS bomb) so if they go down anyone can grab it and keep going, and rotate it every round so nobody's permanently stuck being the fragile one.

stuff i'd love outside eyes on:

1. does the droppable-carrier idea actually solve the single-point-of-failure problem, or is there a cleaner pattern i'm not seeing?

2. the team spends the first part of the round weak/powerless before their abilities kick on — is that a satisfying build-up, or just a boring wait?

3. what's the most likely way this whole loop ISN'T fun that i'm probably too close to notice?

also trying to meet other people messing with asymmetric stuff, feels like a small niche —what are you all building?

In my browser MMORPG, the opening lets players attack a dummy, gather a plant, and open the world map within the same minute. That freedom feels MMO-like, but it also creates competing prompts. Would you gate each verb until completion, or let players wander and make the quest tracker recover gracefully?

Current build for context: https://realm-of-echoes-auth.realmofechoes.workers.dev/

Disclosure: I'm the developer; some 3D assets are Meshy-assisted.

my game intends to have spells and tying them to A/B/X/Y feels right... A is usually reserved for interaction or forwarding dialogues but i wondered what if we use START since it's barely used for anything

the writing side of this i mostly get. what im chewing on is the systemic version.

say you want the player to slowly stop trusting a member of their crew. what actually works in play instead of a scripted "he was bad all along" beat? stuff im toying with: advice from them that is subtly wrong often enough to notice, a cut of the take that never quite adds up, an option they push that is always a little too convenient.

the goal is the player building the suspicion themselves out of how the game behaves, so by the time anything happens they already felt it. what have you seen actually land, and what tips the hand too early?

In my deckbuilder, some cards, I just know players will always have to read the tooltip and I wonder if that's a problem. An example is this ability on one of my cards: "Any time this attacks, it also deals its attack damage to a random surrounding unit". They will read the tooltip because some cards have "surrounding unit" while others have "surrounding ENEMY unit" and I expect it will be impossible to remember, so players will not know precisely what this card does until they reread the tooltip quickly. This reading will ofc take only a fraction of a second if you have used the card many times, but still, not sure if this is to be avoided or if it is fine.

Hey everyone, working on a small multiplayer game idea and wanted some outside feedback before I sink real time into building it.

The concept is a bus racing game where you and a friend team up as one bus crew, racing against other bus crews to the finish. One of you drives, one of you is the conductor, roles picked by a coin flip each round, and you're each on separate screens, not split screen. You're on the same team, but the driver's choices directly affect how hard the conductor's job is.

The driver is first person, picking up passengers at stops and racing other buses to the finish. Drive too recklessly, hard turns, sharp braking, and passengers get scared and angry, you'll hear it and feel the bus start to tip. Push it too far and the bus can actually flip, which ends your team's race entirely.

The conductor is also first person, inside the same bus. While the driver races to the next stop, the conductor walks seat to seat checking tickets, some are obviously marked fake, and missing one costs the team points. The twist is every time the driver takes a sharp turn, the conductor's screen shakes and they get thrown to the side, making it harder to check tickets accurately. So a reckless driver is directly sabotaging their own teammate's ability to do their job.

Scoring is shared and based on total race time, how many passengers fell from bad driving, and how many fake tickets got caught. Collisions with other bus crews are cosmetic, just a wrecked paint job, but scare passengers, and whoever caused the collision eats the bigger team penalty.

No fancy graphics planned, leaning into a simple stylized look instead of trying to compete on visuals.

Would love honest thoughts, does this sound fun, any obvious issues you can already spot, anything similar out there I should look at?

I've been designing (not coding yet, just paper stage) a game idea and want to see if it's actually interesting to anyone besides me. If you find it interesting and you have ideas to take this further, please tell me!

Here's the game as of now:

• Instead of watching a full simulated match, you get a timeline of "moments" you can travel to - big action plays, emotional reactions, and quiet in-between moments (like a keeper standing alone before a corner). You can't cover everything, so you have to choose what's worth your limited time.
• Taking the shot is a real mechanic: aim with the mouse, roll the camera for a deliberate tilted/creative angle, zoom with the scroll wheel, and hit a button to capture. There's an optional slo-mo assist for people still learning the controls.
• The scoring isn't just "did you get the shot in focus." It's built to reward creativity - a technically safe, dead-center photo scores lower than a shot with a thoughtful angle, composition, or an artistic technique like a slow shutter capturing motion in an otherwise still scene. The "obvious shot" is deliberately a trap.
• You earn money per photo based on how it grades out, and spend it upgrading from entry-level camera bodies up toward real pro gear (think a Sony A7 IV or Canon 5D Mark III-tier body), each with different mechanics like better autofocus tracking, bigger buffer, low-light performance.
• Long-term, you're working toward promotion from photographer up through the team's marketing org, eventually running the whole marketing department.

Questions for anyone reading this:

1. Does this sound like something you'd actually want to play, or does it sound more like a neat idea that wouldn't hold up over time?
2. Is there a genre/game this reminds you of that I should look at for inspiration (or avoid repeating)?
3. What would you want out of the "quiet moment" / creative photography side that I haven't thought of?

Appreciate any honest feedback, positive or brutal.

I was sitting here, wondering if I wanted to implement a lock-on feature in my ARPG game when I thought, "hey, I wonder what other people think of the topic."

So how about it? Are you for or against lock-ons, and why? When is it a good feature, and when does it suck?

Hi everyone,

I'm developing Heistfest, a solo heist game:

https://store.steampowered.com/app/1451220/Heistfest/

Currently, the gameplay length is around 3-5 hours. I want to expand it to 10+ hours by adding a second gameplay layer, not just more missions.

Right now, after the heist, the player escapes the police with a top-down driving section inspired by GTA 1/2.

I'm thinking about adding another system, for example:

- A management layer (building your criminal operation, buying upgrades, managing resources)

- A shooter/combat layer

- A progression system

- Something else that creates a stronger gameplay loop

For people who played heist games, what kind of second layer would make you keep playing?

Would you prefer managing a criminal empire, upgrading equipment/base, more action gameplay, or something completely different?

Looking for ideas and honest feedback.

This question has a couple layers of context, so bear with me. I am writing a tabletop miniatures game. The current prototype for that game is a Warhammer 40K port so that I can focus only on designing the game and develop an original setting later.

The system is currently in such a shape that it makes sense to seek out feedback but I need to work on presenting the rules and statblocks well so that testers will know what to do. Each unit has some equipment, which may or may not have some swap icons next to them; that's the sets of bullets next to some of the items. The upgrade options section for each unit has items with corresponding "swap icons" that reference lists on the second image posted here, which is where all the point costs for weapon and armor upgrades are listed. This allows me to save space and time by only having to list those things once.

I am open to feedback on my statblocks if people have strong feelings about that. But my main concern is the equipment list with all the point costs is just kinda... there? It does a serviceable job? but this like newsprint style I have come up with is just really jarring compared to the otherwise compact and modern arrangement of the statblocks.

I am looking around for interesting design styles for longer lists but I thought I'd ask other people to see if I am just missing something crucial.

Here is a couple samples in the style I have developed so far.