Jump to content
  • Advertisement


This topic is now archived and is closed to further replies.


Brainstorming: 3D Minesweeper?

This topic is 5612 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post

Link to post
Share on other sites
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.

Share this post

Link to post
Share on other sites
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.

Share this post

Link to post
Share on other sites
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]

Share this post

Link to post
Share on other sites
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.

Please. I''ll also Google to see what I can find.

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 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...

Share this post

Link to post
Share on other sites
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]

Share this post

Link to post
Share on other sites
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:

# 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.
w - The width (x) of the playing grid
h - The height (y) of the playing grid
d - The depth (z) of the playing grid
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.payload.append('' '')
def populate(self, numberOfMines):
""Populate the playing grid with a specified
number of mines.
numberOfMines - Number of mines with
which to fill grid
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.
cx - Cell x-coordinate
cy - Cell y-coordinate
cz - Cell z-coordinate
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.
index - Zero-based index into playing grid
A (cx, cy, cz) tuple of the cell x-, y- and
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).
cx - Cell x-coordinate
cy - Cell y-coordinate
cz - Cell z-coordinate
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.remove( self.getIndex(cx, cy, cz) )
return neighbors
def getNeighborsFromIndex(self, index):
""Obtain a list of the cells neighboring
the cell at index.
index - A zero-based index into the
playing grid.
A list of neighboring cell indices."
cx, cy, cz = self.getCoords(index)
return self.getNeighbors(cx, cy, cz)

# main.py

import os
import pygame
from pygame.locals import *
print ''Minesweeper3d requires PyGame. Exiting...''
raise SystemExit
from OpenGL.GL import *
from OpenGL.GLU import *
print ''Minesweeper3d requires PyOpenGL. Exiting...''
raise SystemExit
import GameState
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.display.set_mode((640,480), OPENGL|DOUBLEBUF)
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
event = pygame.event.poll()
if event.type == QUIT:
# todo: insert input logic processing here
# todo: insert appropriate calls to render
# function here
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.

Share this post

Link to post
Share on other sites
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 !

Share this post

Link to post
Share on other sites

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!