Hello everyone,
thank you so much for your responses.
When I said efficient, I meant in terms of storage, both in a file for
saving maps if the user chooses to save, and in the computers memory.
Low memory programs=happy users. sometimes.
These responses have been really helpful, and I did not realise I could
do something like:
key=(x, y)
game_map[key]=bla.
LEarned a lot, so thanks!
Nathan
On 19/08/2019 15:02, Mats Wichmann wrote:
> 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
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
