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