Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags

Game design input wanted for 7drl

A topic by dusimgames created Mar 08, 2021 Views: 325 Replies: 4
Viewing posts 1 to 5

(This is a repost of a reddit post I made yesterday - hope that's ok :O)

Hi everyone, I have been learning Unity for 3 or 4 months now and feel pretty well at home by now. I have a background as a C# programmer. I signed up for my first 7DRL to make my first roguelike - my first game ever, actually. I've spent the past weeks getting some of the basic roguelike stuff working - tiles, movement, collision, inventory, but: I need some help for some game design ideas.

I started out with a neat little, somewhat original idea, I think, and I didn't want to "spoil" it, but I think I have to, in order to get some help with what direction to go in. Basically I've always been fascinated with Conway's Game of Life, and it has some things in common with roguelikes (moving on a grid, "turn"-based etc.) so I thought, "Wouldn't it be great if I could walk around inside Conway's game of life and interact with it?" and so that's my idea. So the "life" moves one generation after the player takes one turn. I think it is an interesting concept, but where is the interesting gameplay? I thought about having the player fight a glider for example -- the glider could be coming to attack the player, or trying to get away, or trying to reach some object before the player. How can the player react? Maybe by casting a spell that spawns a living "life" cell somewhere (I have this mechanic implemented right now), and messes up the glider? Maybe the life takes two turns whenever the player takes one - but a spell could change it, so the life becomes slower. Or maybe another spell that changes the rule of the "life"? (Conway's game of life has the following rule: B3/S23, which means an empty cell comes to life if it has 3 neighbors, and live cells survive if they have 2 or 3 neighbors. All other cells die or stay dead.) Another brainstorming idea is that the player can spawn her own gliders/spaceships to fight against evil gliders/spaceships - so we now have two "lifes" battling(!).

But how would it work in practice? And a big question is how can I make it randomly generated? I mean, the glider and the object it tries to reach have to be set up kind of precisely to make it a tough but solvable challenge to the player. Any reactions, tips, ideas or questions would be very much appreciated. Thank you very much.

And to everyone participating, good luck on the 7DRL challenge week!

(1 edit) (+1)

Hmm, wow. This is ambitious in the sense of trying to get a fun game out of a difficult concept. If you manage, that could be pretty interesting.

I see three different possible ways to set up the core gameplay loop of the game:

-Puzzle game: the player has to think carefully about the consequences of every move they make, by working through the GoL rules.

-Like a causal RL, faster paced: how exactly the game will respond to the player's action does not really matter. The GoL rules are essentially a random number generator with visible state. The player takes actions quickly, bashes through the living blocks, mostly probably removing more than adding them, and dodges the formations that move towards them.  They will hopefully gain some intuition as to how to react to a particular formation but they can survive without it. It's like Space Invaders except the invaders move in highly complex patterns, multiplying and disappearing. 

-Like a traditional RL: combination of the above two. The game is not a series of carefully set up puzzles, it's a collection of  primitives like blocks and gliders which the player learns straightforward rules to deal with. After a short learning period the player makes decisions quickly much of the time, but in tricky situations they stop and think, working through the GoL rules to figure out what to do.

From your description I'm not sure whether you were going for #1 or #3, but probably #1? I personally would go for #3 as otherwise it's a puzzle game (isn't it meant to be a RL?), and in my experience playing with GoL in that way gets tedious.

Good luck!

(+1)

I'd argue you can add procedural generation to the starting distribution of living cells. You could also vary the rules for living vs dead cells by a variable that changes depending on the 'level' you're at, or just randomize it's value each game. You could also add walls to the level that act like the boundary, and the layout of the walls would be procedurally generated. It would affect what patterns get created in potentially interesting ways but you'd need large rooms or spaces so that everything doesn't die off too soon.

For gameplay, I'd suggest the typical rogue goal of 'reach level X then leave'. So, the board could change in size or shape or number of living cells at the start based on depth, and the goal is to reach a certain depth. To change depth, have a cell that you need to reach which is the stairs down (and it's like a wall: it doesn't get created or destroyed, it just waits for the player to reach it). The player could attack other cells to kill them off, so that they can make their way safely to the stairs, but make sure that there is a rule regarding re-spawning living cells so that the player can't just clear the board and then leave. I'd also argue against the goal being to kill everything, since it might be trivial or impossible depending on the pattern created; having to avoid those enemies while

Thank you both for the really great replies! In the end, I didn't manage to complete the game because, you know... life ;)

Submitted(+1)

Try again next year. 

What I did this year was my last year's idea (stored in my own backlog of ideas). And I'm also fascinated with GoL (and artificial life in general) so it's something that I would like to try out.

I'd start with something really simple. As AquaTsar said just traverse a level to reach an exit while avoiding living cells. I believe that adjusting your movements to the patterns is solid enough for a gameplay foundation.