Brainstorming: 3D Minesweeper?
There was recently a minesweeper thread in the lounge, in which I asked if and how minesweeper could be adapted to 3 dimensions. A comment a while later from someone else gave me an idea which I am now working on developing, just to see how it plays.
Classic minesweeper is about intersections in 2 dimensions. What happens when you have intersections in 3, when instead of a maximum of 8 mines surrounding a given cell you have 26, when the indicator "2" could describe two of twenty-six cells? I''m envisoning a sort of ethereal floating environment where each cell is a cube which may or may not contain a mine. The user moves from cell to cell using the keyboard (we need up/down, left/right and forward/backward movements) as well as selects and "explodes" them. (Mouse control is possible, though probably more awkward... though a scroll mouse could provide all the controls conveniently.) Rather than a solid cell as in classic minesweeper, each cell would be wireframe, with a sphere/smaller cube at the center. When opened, the center atom would reveal either a number or... a mine (tadaaa!) Pretty simple.
The question is, does gameplay become too difficult because of the spatial explosion (7 axes rather than 4, etc)? Are there artificial constraints that could make the game more playable - like restricting the number of cells, or ensuring that every game is solvable (by whatever means)? Or do you have completely different ideas on how minesweeper can be adapted to 3D?
I should have a playable prototype up in a day or two; I''ll update this post when I do.
I think a playability issue may arise with depth. Do you only work downwards, towards the core, or can you select any cube at all?
--------------------------------------------
Democracy may only be a few steps removed from anarchy, but at least it isn''t as loud.
--------------------------------------------
Democracy may only be a few steps removed from anarchy, but at least it isn''t as loud.
With love, AnonymousPosterChild
If you''re curious, there is a 3D minesweeper game out.. made with blitz3D. It''s actually quite fun to play (though I would change some parts of the "gameplay"). I''ll see if i can dig up the link.
Disclaimer: "I am in no way qualified to present advice on any topic concerning anything and can not be held responsible for any damages that my advice may incurr (due to neither my negligence nor yours)"
nice little game to test some crazy interfaces ... you might want to try some futuristic style interfaces that allows the use of the mouse ... I doubt keyboard only game would be so well accepted nowadays ...
[edited by - eglasius on June 3, 2003 6:16:59 PM]
[edited by - eglasius on June 3, 2003 6:16:59 PM]
Eglasius - I can see how the power flows within you, open your eyes and live in a new world.
Another interesting variant. Doesn''t look very good though.
"-1 x -1 = +1 is stupid and evil."-- Gene Ray
@AnonymousPosterChild:
Precisely my concern, which is why I''m throwing together a demo (just need to add bombs and logic) to try it out. The field size is also flexible, so I''d like people to see if there are any issues with certain depths or if there''s an "acceptable depth threshold." Should be able to knock this out by tomorrow.
@falkone:
Please. I''ll also Google to see what I can find.
@eglasius:
I''d love to hear your interface ideas, though I suppose I ought to present the playable, tweakable demo first.
A few notes on the demo:
It''s written in Python. This is actually a plus, even if you don''t know Python, because of how simple the language syntax is - yet very powerful. I''ll be sure to comment liberally.
It uses OpenGL through the PyOpenGL wrapper and SDL through PyGame. So you''ll need to install Python (2.2+, though I''d recommend sticking with 2.2 if you''re just downloading; ActiveState''s ActivePython is a good distribution), PyGame and PyOpenGL (I used 2.0.0.44) if you don''t have them already.
I have neither prettified nor optimized the code as yet. It''s not ugly, but it''s not what I''d consider "production" quality yet. Okay, back to the snakepit...
Precisely my concern, which is why I''m throwing together a demo (just need to add bombs and logic) to try it out. The field size is also flexible, so I''d like people to see if there are any issues with certain depths or if there''s an "acceptable depth threshold." Should be able to knock this out by tomorrow.
@falkone:
Please. I''ll also Google to see what I can find.
@eglasius:
I''d love to hear your interface ideas, though I suppose I ought to present the playable, tweakable demo first.
A few notes on the demo:
It''s written in Python. This is actually a plus, even if you don''t know Python, because of how simple the language syntax is - yet very powerful. I''ll be sure to comment liberally.
It uses OpenGL through the PyOpenGL wrapper and SDL through PyGame. So you''ll need to install Python (2.2+, though I''d recommend sticking with 2.2 if you''re just downloading; ActiveState''s ActivePython is a good distribution), PyGame and PyOpenGL (I used 2.0.0.44) if you don''t have them already.
I have neither prettified nor optimized the code as yet. It''s not ugly, but it''s not what I''d consider "production" quality yet. Okay, back to the snakepit...
quote: Original post by LNK2001Aye... *shudder*
Another interesting variant. Doesn''t look very good though.
quote: Original post by falkone
If you're curious, there is a 3D minesweeper game out.. made with blitz3D. It's actually quite fun to play (though I would change some parts of the "gameplay"). I'll see if i can dig up the link.
nah its played the same way as 2d except you work your way through...
i think the idea Oluseyi had on his mind was that you can move the angle of the camera and begin at any point and being able to get different perspectives ...
And by the way, i have a whole summer free so if anyone wants to start a project like this id be happy to lend a hand
edit: nevermind about the 'btw' ...
i dont think adding in another 18 neighbors will make the game excessivly frusterating, unless you are on the intermediate/expert settings (it would like an all day endeavor)
[edited by - MrPoopypants on June 5, 2003 7:54:33 PM]
(0110101101000110)The Murphy Philosophy: Smile . . . tomorrow will be worse.
Update: I''d say I''m about 70% through.
I haven''t written a game in a while, so I''m really rusty on the kind of focus needed to knock one out in a straight binge. Also, I''m using relatively new tools - though they''ve been an unqualified benefit, not a hinderance in any way.
Might as well post what I''ve written so far (within the last 24 - 36 hours); someone might jump hop in and finish it up:
Currently, nothing shows up in the application window (there''s no render function as yet; I could post a separate demo which creates 3D grids in user-specified x, y and z dimensions) nor is there any input handling. Essentially, that and the generation of the appropriate vertices are what I''m still hacking up.
I haven''t written a game in a while, so I''m really rusty on the kind of focus needed to knock one out in a straight binge. Also, I''m using relatively new tools - though they''ve been an unqualified benefit, not a hinderance in any way.
Might as well post what I''ve written so far (within the last 24 - 36 hours); someone might jump hop in and finish it up:
# GameState.py import random class GameState: """The GameState class encapsulates all data to describe the current state of a game. It also contains several functions to help instantiate and update such a state.""" def __init__(self, w, h, d): """Create a GameState instance. Parameters: w - The width (x) of the playing grid h - The height (y) of the playing grid d - The depth (z) of the playing grid Returns: A valid GameState instance.""" # useful quick reference variables self.X = w # x-extent of grid self.Y = h # y-extent of grid self.Z = d # z-extent of grid self.N = w * h * d # number of cells in grid self.layer_size = w * d # number of cells per layer self.proximity_count = [] # number of mines around each cell self.payload = [] # keep track of which texture to use for each cell payload self.texture_index = [] for i in range(self.N): self.texture_index.append(27) self.payload.append('' '') self.proximity_count.append(0) def populate(self, numberOfMines): """Populate the playing grid with a specified number of mines. Parameters: numberOfMines - Number of mines with which to fill grid Returns: No return value.""" # obtain random number generator g = random.Random() # populate grid; use asterisk to indicate mine for n in range(numberOfMines): x = g.randint(0, self.X) y = g.randint(0, self.Y) z = g.randint(0, self.Z) self.payload[ self.getIndex(x, y, z) ] = ''*'' # determine proximity count - how many mines surround cell for n in range(self.N): p = self.getNeighborsFromIndex(n) for c in p: if self.payload[c] == ''*'': self.proximity_count[c] = self.proximity_count[c] + 1 def getIndex(self, cx, cy, cz): """Obtain the linear index of a cell at the coordinates (cx, cy, cz) in the grid. Parameters: cx - Cell x-coordinate cy - Cell y-coordinate cz - Cell z-coordinate Returns: A zero-based index into the grid. Raises IndexError if out of range.""" if cx > self.X or cy > self.Y or cz > self.Z \ or cx < 0 or cy < 0 or cz < 0: raise IndexError return cy * self.layer_size + cz * self.X + cx def getCoords(self, index): """Obtain the (cx, cy, cz) from a linear index into the grid. Parameters: index - Zero-based index into playing grid Returns: A (cx, cy, cz) tuple of the cell x-, y- and z-coordinates.""" if index < 0: raise IndexError layer_offset = index % self.layer_size cy = (index - layer_offset) / self.layer_size cx = layer_offset % self.X cz = (layer_offset - cx) / self.X return (cx, cy, cz) def getNeighbors(self, cx, cy, cz): """Obtain a list of the linear indices of the cells neighboring (cx, cy, cz). Parameters: cx - Cell x-coordinate cy - Cell y-coordinate cz - Cell z-coordinate Returns: A list of neighboring cell indices.""" neighbors = [] for y in range(cy - 1, cy + 2): for z in range(cz - 1, cz + 2): for x in range(cx - 1, cx + 2): if x >= 0 and y >= 0 and z >= 0 \ and x < self.X and y < self.Y and z < self.Z: neighbors.append( self.getIndex(x, y, z) ) neighbors.sort() neighbors.remove( self.getIndex(cx, cy, cz) ) return neighbors def getNeighborsFromIndex(self, index): """Obtain a list of the cells neighboring the cell at index. Parameters: index - A zero-based index into the playing grid. Returns: A list of neighboring cell indices.""" cx, cy, cz = self.getCoords(index) return self.getNeighbors(cx, cy, cz)
# main.pyimport os try: import pygame from pygame.locals import *except: print ''Minesweeper3d requires PyGame. Exiting...'' raise SystemExit try: from OpenGL.GL import * from OpenGL.GLU import *except: print ''Minesweeper3d requires PyOpenGL. Exiting...'' raise SystemExit try: import GameStateexcept: print ''Failed to locate GameState module. Exiting...'' raise SystemExit # todo: world prep function# todo: render function def main(): # todo: add more comments here. this could serve # as a very good tutorial for "advanced beginners", # be contributed to the PyGame site and so forth... pygame.init() pygame.display.set_mode((640,480), OPENGL|DOUBLEBUF) glEnable(GL_DEPTH_TEST) glMatrixMode(GL_PROJECTION) gluPerspective(45.0, 640/480.0, 0.1, 100.0) glTranslatef(0.0, 0.0, -3.0) glRotatef(25, 0, 0, 0) while 1: # main loop glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT) event = pygame.event.poll() if event.type == QUIT: break # todo: insert input logic processing here # todo: insert appropriate calls to render # function here pygame.display.flip() pygame.time.wait(10) pygame.quit() if __name__ == ''__main__'': main()
I''ve already put in links to the various library sites, from which documentation can be obtained for anything not related to the game. I commented the source liberally and used descriptive variable names too, so it should be easy even for non-programmers to follow the code. Python''s readable syntax doesn''t hurt either.Currently, nothing shows up in the application window (there''s no render function as yet; I could post a separate demo which creates 3D grids in user-specified x, y and z dimensions) nor is there any input handling. Essentially, that and the generation of the appropriate vertices are what I''m still hacking up.
Actually, why not make it more like a 3D maze sort of thing ?
You start in the middle of a 3D mine field, each step, you can either rotate, or move in the direction you are facing.
You only get "readings" for the direction you are facing, reducing the problem to a 2D one, in a way.
The goal of the game is, instead of clearing the board, to get out of the area without getting blown up.
Gee, you could be an earthworm, or an ant, or some other digging insect, that rely on its sense of smell/sight/hearing/electromagnetic perception, to sense the danger ahead. The danger could be anything, from a giant enemy insect waiting in ambush, to an underground river, to a big rock that cant be digged through (in which case you dont actually lose). You could sometimes find some already digged up tunnels (the fill effect that you get when you press in one empty area, but here it would be adapted to the new paradigm), possibly you could find bonuses, like being able to send a sonar ping to "see" all the danger facing you, but for a very brief moment, or the ability to shoot ahead, destroying whatever is in front of you without being hurt, etc, etc.
If you digged through a pocket of whatever, maybe you could have the water naturally expand (filling up empty spaces and drowning you...)
Gee, I am sure there is more to be done than simply put a 2D grid on a 3D sphere...
Sancte Isidore ora pro nobis !
You start in the middle of a 3D mine field, each step, you can either rotate, or move in the direction you are facing.
You only get "readings" for the direction you are facing, reducing the problem to a 2D one, in a way.
The goal of the game is, instead of clearing the board, to get out of the area without getting blown up.
Gee, you could be an earthworm, or an ant, or some other digging insect, that rely on its sense of smell/sight/hearing/electromagnetic perception, to sense the danger ahead. The danger could be anything, from a giant enemy insect waiting in ambush, to an underground river, to a big rock that cant be digged through (in which case you dont actually lose). You could sometimes find some already digged up tunnels (the fill effect that you get when you press in one empty area, but here it would be adapted to the new paradigm), possibly you could find bonuses, like being able to send a sonar ping to "see" all the danger facing you, but for a very brief moment, or the ability to shoot ahead, destroying whatever is in front of you without being hurt, etc, etc.
If you digged through a pocket of whatever, maybe you could have the water naturally expand (filling up empty spaces and drowning you...)
Gee, I am sure there is more to be done than simply put a 2D grid on a 3D sphere...
Sancte Isidore ora pro nobis !
-----------------------------Sancte Isidore ora pro nobis !
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement