On 8/18/19 5:55 PM, nathan tech wrote:
> Hi there,
>
> So I am running over some coding ideas in my head for creating a map for
> a game.
>
> This map would expand based on how far the user explores.
>
> I figure there are two ways to do this:
>
> 1: the list method:
>
> map=[]
> for x in range(3):
> temp=[]
> for y in range(3):
> temp.append(default_grid_format)
> map.append(temp)
>
> then when ever the user explores a square not on the current map, it
> would do this:
>
> for x in range(len(map)):
> map[x].append(default_grid_format)
> temp=[]
> for x in range(len(map[0])):
> temp.append(default_grid_format)
> map.append(temp)
>
> Obviously, though, this creates a lot of data for squares that are still
> ultimately unexplored.
>
> So here was my other idea:
>
> 2. the dictionary method:
>
> map={}
> for x in range(3):
> for y in range(3):
> key=str(x)+":"+str(y)
> map[key]=default_grid_format
>
> Then when user explores new square do:
>
> key=str(player_x)+":"+str(player_y)
> map[key]=default_grid_format
>
>
> Is this an efficient method compared to 1?
>
> Is it, code wise, sound logic?
>
>
>
> I guess I'm just looking for a second opinion from experienced peoples.
A few notes...
There's a nice little tension in design and programming of a project:
don't optimize too early, you may not need to, and/or your early guesses
may be completely wrong VS. if you pick a bad design up front, it may be
"too late" to optimize away the problems that brings later. Then again
they _also_ say "build one to throw away" :)
You haven't defined what needs to happen for a new square. If the "map"
(please don't use that as a variable name, by the way, as it's already a
Python builtin function) is a rectangular grid, each square has eight
neighbors. If you've ever played with minesweeper, you see this in
action... "exploring" from one point means figuring out which of the
neighbors has a mine. So what should happen for a "new" square? Do you
want to generate the information for all of those neighbors? Your
conceptual code seems to just add a row-and-column, which seems a little
odd... what if the exploration went in the other direction, i.e. "left"
or "up"?
Python has some support for "don't calculate it until it's needed",
called generators. Depending on your design you may or may not be able
to make use of such. Here's a silly little snippet to illustrate a
generator which produces the neighbors of a square (in this case, just
the coordinates):
def neighbors(point):
x, y = point
yield x + 1, y
yield x - 1, y
yield x, y + 1
yield x, y - 1
yield x + 1, y + 1
yield x + 1, y - 1
yield x - 1, y + 1
yield x - 1, y - 1
nlist = neighbors(point)
print(f"neighbors returns {nlist}")
print(f"neighbors of {point}: {list(nlist)}")
When run:
neighbors returns <generator object neighbors at 0x7f66ad4afad0>
neighbors of (7, 6): [(8, 6), (6, 6), (7, 7), (7, 5), (8, 7), (8, 5),
(6, 7), (6, 5)]
... the data (just the coordinates of a neighbor square) is not
generated until you consume it, which the string in the print call
forces by calling list() on it. The more normal case is you'd loop over
it...
It this was too complicated for where you are in your Python studies,
don't worry about it, but you'll get there eventually :)
Micro-comment: a piece of code I'd hope to never see again:
for x in range(len(map)):
map[x].append(default_grid_format)
this lazily produces a counter from the size of an iterable object
(similar in concept to a generator), and then uses the counter to index
into said object; that's not needed since you can just iterate the
object directly. Instead write it like this:
for m in map:
m.append(default_grid_format)
Micro-comment: you can use anything (well, anything "hashable") as the
key for a dict. So for:
key=str(x)+":"+str(y)
you can just do:
key = (x, y)
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
