基于文本的游戏中的Python计数器

Question

I'm making a text-based farmville clone using objects but I need to be able to control growth rate. I need some sort of counter that will run in the background of my program and determine how grown a crop is. for example:

class Grow(object):
    def growth(self, crop):
        self.grown = 0
        while self.grown < 5:
            <every x number of seconds add one to self.grown>

I need something like time.sleep() but something that does not stop the program from running. Thanks =D

Answer 1

If you only need to know how much the crop would have grown since you last checked, you can build this into your Crop objects:

from datetime import datetime

class Crop:

    RATE = 1 # rate of growth, units per second

    def __init__(self, ..., grown=0): # allow starting growth to be set
        ...
        self.last_update = datetime.now()
        self.grown = grown

    def grow(self):
        """Set current growth based on time since last update."""
        now = datetime.now()
        self.grown += Crop.RATE * (now - self.last_update).seconds
        self.last_update = now

Alternatively, you could define this functionality in a separate Growable class and have all objects that grow (eg Crop , Animal ) inherit the grow method from that superclass.

class Growable:

    def __init__(self, grown=0):
        self.last_update = datetime.now()
        self.grown = grown

    def grow(self, rate):
        """Set current growth based on time since last update and rate."""
        now = datetime.now()
        self.grown += rate * (now - self.last_update).seconds
        self.last_update = now

class Crop(Growable):

    RATE = 1

    def __init__(self, ..., grown=0):
        super().__init__(grown)
        ...

    def grow(self):
        super().grow(Crop.RATE)

Answer 2

There are different ways to do this, which depend on how you want to structure your app. Every game is basically running some kind of loop; the question is what kind of loop you're using.

---

For a simple "console mode" game, the loop is just a loop around input() .. While you're waiting for the user to type his input, nothing else can happen. And that's the problem you're trying to solve.

---

One way to get around this is to fake it. You may not be able to run any code while you're waiting for the user's input, but you can figure out all the code you would have run, and do the same thing it would have done. If the crop is supposed to grow every 1.0 seconds up to 5 times, and it's been 3.7 seconds since the crop was planted, it's now grown 3 times. jonrsharpe's answer shows a great way to structure this.

---

This same idea works for graphical games that are driven by a frame-rate loop, like a traditional arcade game, but even simpler. Each frame, you check for input, update all of your objects, do any output, then sleep until it's time for the next frame. Because frames come at a fixed rate, you can just do things like this:

def grow(self, rate):
    self.grown += rate / FRAMES_PER_SECOND

---

A different solution is to use background threads. While your main thread can't run any code while it's waiting around for user input, any other threads keep running. So, you can spin off a background thread for the crop. You can use your original growth method, with the time.sleep(1.0) and everything, but instead of calling self.growth(crop) , call threading.Thread(target=self.growth, args=[crop]).start() . That's about as simple as it gets—but that simplicity comes at a cost. If you have a thread for each of 80x25=2000 plots of land, you'll be using all your CPU time in the scheduler and all your memory for thread stacks. So, this option only works if you have only a few dozen independently-active objects. The other problem with threads is that you have to synchronize any objects that are used on multiple threads, or you end up with race conditions, and that can be complicated to get right.

---

A solution to the "too many threads" problem (but not the synchronization problem) is to use a Timer . The one built into the stdlib isn't really usable (because it creates a thread for each timer), but you can find third-party implementations that are, like timer2 . So, instead of sleeping for a second and then doing the rest of your code, move the rest of your code into a function, and create a Timer that calls that function after a second:

def growth(self, crop):
    self.grown = 0
    def grow_callback():
        with self.lock:
            if self.grown < 5:
                self.grown += 1
                Timer(1.0, grow_callback).start()
    Timer(1.0, grow_callback).start()

Now you can call self.growth(crop) normally. But notice how the flow of control has been turned inside-out by having to move everything after the sleep (which was in the middle of a loop) into a separate function.

---

Finally, instead of a loop around input or sleeping until the next frame, you can use a full event loop: wait until something happens, where that "something" can be user input, or a timer expiring, or anything else. This is how most GUI apps and network servers work, and it's also used in many games. Scheduling a timer event in an event loop program looks just like scheduling a threaded timer, but without the locks. For example, with Tkinter, it looks like this:

def growth(self, crop):
    self.grown = 0
    def grow_callback():
        if self.grown < 5:
            self.grown += 1
            self.after(1000, function=grow_callback)
    self.after(1000, function=grow_callback)

---

One final option is to break your program up into two parts: an engine and an interface. Put them in two separate threads (or child processes, or even entirely independent programs) that communicate over queues (or pipes or sockets), and then you can write each one the way that's most natural. This also means you can replace the interface with a Tkinter GUI, a pygame full-screen graphics interface, or even a web app without rewriting any of your logic in the engine.

In particular, you can write the interface as a loop around input that just checks the input queue for any changes that happened while it was waiting, and then posts any commands on the output queue for the engine. Then write the engine as an event loop that treats new commands on the input queue as events, or a frame-rate loop that checks the queue every frame, or whatever else makes the most sense.