Archived

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

Brainstorming: 3D Minesweeper?

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

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 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 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 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 on other sites
Another interesting variant. Doesn''t look very good though.

Share on other sites
@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:

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

Share on other sites
quote:
Original post by LNK2001
Another interesting variant. Doesn''t look very good though.
Aye... *shudder*

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

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

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 on other sites
quote:
Original post by ahw
Gee, I am sure there is more to be done than simply put a 2D grid on a 3D sphere...
I agree, which is what I''m trying to do. Did you read my description or did you focus on the demo LNK2001 linked to?

What you suggest, while very interesting and possibly something I will take you up on, once I snap out of this code slump and finish this off, is not minesweeper. A 3D maze game is... a 3D maze game. I''m doing this not to make "a fun game" but to explore what happens when a game with well-defined gameplay in two dimensions is extended into a third, equal dimension, and what adjustments may be necessary to maintain the fun factor. (Other games have made the leap into 3D, but they usually don''t treat all dimensions the same - you walk in two but jump in the third, for example. 3D minesweeper would be identical in every dimension, which singles it out for this study.)

Thanks for the contribution, though. Dissidence is necessary to achieve the best possible results.

Share on other sites
Minesweeper is a great, quick-fix challenge. Most people, however, don''t seem to understand it. Putting is in 3D complicates it and makes it harder for the laymen to understand. I think, focusing on this point, is what is most important in the gameplay. If you''re in 3D and you''re looking dead-on at a "block", how do you know what is behind it?

An important aspect of the minesweeper game is that you can look at a numbered block and possibly know what is around it because you know which blocks are free, which aren''t and how many blocks surrounding contain bombs. Although I''m intrigued by the idea, I can''t get my mind around how the player sees the state of the block. In 3D you are limited to your perspective. In the original game, you have an easy top-down perspective.

How exactly does the player view the numbered block? How do they know what''s behind it? Are the blocks not solid and I can see beyond them?

The player would have to be able to see all the surrounding blocks. Are we using wire-frame graphics?

I envision a wireframe view but the blocks fade off into the distance. Still, blocks that are numbered must have a way to make it visually easy for the player to know which block the numver is refering too. Make numbered blocks solid with numbers on the side while other questionable blocks are transparent?

This is an idea that demands much design in gameplay. I''m trying to visualise it but I keep running into frustrating gameplay.

- Jay

[ Here, taste this ]

Share on other sites
quote:
Original post by Oluseyi
once I snap out of this code slump and finish this off, is not minesweeper. A 3D maze game is... a 3D maze game.

Are we talking about a psuedo-3D game? Still two dimensions but the player is in a Wolfenstein-like perspective?

- Jay

[ Here, taste this ]

Share on other sites
quote:
Original post by coderx75
How exactly does the player view the numbered block? How do they know what''s behind it? Are the blocks not solid and I can see beyond them?

The player would have to be able to see all the surrounding blocks. Are we using wire-frame graphics?
Yep. Each cell is a wireframe cube with a smaller cube centered in it that indicates the number of mines around or is blank if there are none, shows either a flag or a question mark when right-clicked by the user and will show a mine texture if you mess up.

Later I may think about more graphical refinements like translucency or actual flag, question mark, mine and number models floating in the cell center.

Share on other sites
Heres an idea: Once you extend the 2d squares into 3d cubes, then the complexity increases rapidly as you noted due to the extra adjacent cells. I''d guess that this would remove alot of the playability and skill, and introduce more of a random element.

So, how about changing from cubes to triangle-based pyramids? This way you get a regularly tesselated 3d shape, but with the much reduced complexity of each cell only having 4 neighbours.

This is probably quite a bit more tricky to code though, as you have to deal with two distinct cases for each grid cell instead of just the one. Would be interesting to see how it changed the gameplay vs. the square and cube based games..

Share on other sites
quote:
Original post by OrangyTang
So, how about changing from cubes to triangle-based pyramids? This way you get a regularly tesselated 3d shape, but with the much reduced complexity of each cell only having 4 neighbours.
Hmm, interesting. Maybe I''ll do that when (and if) I finish the cube-based one. You do realize that the most stable and aesthetically pleasing scenario is for the triangular pyramids to form a geosphere?

quote:
This is probably quite a bit more tricky to code though, as you have to deal with two distinct cases for each grid cell instead of just the one.
How so? I can''t see any special cases using triangular pyramids.

quote:
Would be interesting to see how it changed the gameplay vs. the square and cube based games...
Definitely. Great idea!

Share on other sites
clicky

has popular games(including minesweeper clone) in 2,3 and 4 dimensions. (represented in 2d only)

ed: clicky

[edited by - kuladus on June 8, 2003 12:17:03 PM]

Share on other sites
quote:
Original post by Oluseyi How so? I can''t see any special cases using triangular pyramids.

My bad, i don''t see any problems now i think about it properly, my mind was entangled with the 2d case of tesselating triangles i think.. Some sort of decent structure to point to adjacent cells and everything could be handled quite neatly.

I hadn''t realised that a geosphere would be the optimal configuration, and suits the game quite nicely (more so than a huge triangular pyramid that i was imagining). If i wasn''t so damn busy i''d take a crack at trying to code it myself.

Share on other sites
Would it help to make a game winnable if the player was given the ability to get a hint, several times throughout the game.

Ie. That they have an item that they can put on a blank square, that can be used to reveal how many adjacent mines it has, or even to reveal directly whether there it is a mine.

These would be only usable once, and would help in situations where there the only way forward was guesswork (ie. in the end-game).

Share on other sites
From following through the thread. I''d almost go with a geosphere if it was in 3d. Kinda like that game that was linked to... just add depth to it... a core to delve into. I think it would still be quite hard. But for me... i think it would be easier to work on peeling the orange(doing the outside part) before getting inside of it. Just a thought.

-DD

Share on other sites
quote:
Original post by OrangyTang
I hadn''t realised that a geosphere would be the optimal configuration, and suits the game quite nicely (more so than a huge triangular pyramid that i was imagining).
That''s also an interesting configuration. In fact, the game could present several different spatial configurations as different "levels." Using triangular pyramids as the fundamental component one can construct a variety of symmetric shapes (including a cube) by varying the side dimensions - ie, making the triangle faces non-equilateral. Three right-angled triangles and one equilateral give you half a cube (hope you can visualize that), for example.

quote:
Original post by Ketchaval
Would it help to make a game winnable if the player was given the ability to get a hint, several times throughout the game.
Actually, if you go with triangular pyramids then each cell only has four neighbors, making the game less complex than the traditional 2D version ("classic" minesweeper). I don''t think a hint would be necessary. However, in more complex scenarios like the cube-based one, hints could be a good gameplay element. Having a feel for when to use them could be the difference between winning and losing - or advancing and having to repeat the level/round in head-to-head or online multiplay.

Share on other sites
I just got blown up by a mine playing Wolfenstein: Enemy Territory, doesn''t that count as a 3d minesweeper game?

Brian J

Share on other sites
On the whole issue of turning a 2d game into 3d..you should check out this!. It''s Rubik''s cube translated from 3d into 4d

-Luctus

Statisticly seen, most things happens to other people.
[Mail]

Share on other sites
Ah, sorry it took so long.. here''s the link

http://www.binary-people.com/game.php?id=3

It''s called Matrix3d

Share on other sites
falkone, that Matrix3D is pretty much it for the cube-based variant, except we want actual cubes for the cell indicators, not flat polygons (rotate to arbitrary angles and you''ll see why). Their use of billboarding created some visual problems at times. The lack of depth of the "open" cells (the ones with numbers in them) also created a perception problem for me.

Other than that, it was pretty cool. Now let''s see if they''ve got a triangular pyramid-based variant...

• Forum Statistics

• Total Topics
628721
• Total Posts
2984394

• 25
• 11
• 10
• 16
• 14