Member Avatar for ben1996123

Hi, I'm making a console application, text based game, and what I need to do is be able to do more than one thing at the same time. For example, I need to be able to make a timer that runs constantly, whilst the game is being played. I also need to be able to print stuff to the screen whilst constantly listening for user input. I heard I could do this with multithreading (which apparently is very complicated). Is there any other way to do this? If not, where should I start to learn about threads and multithreading (I have never used threads/anything like this before)?

  • 2 Contributors
  • 2 Replies
  • 137 Views
  • 7 Hours Discussion Span
  • Latest Post Latest Post by ben1996123

Dani AI

Generated

Two realistic ways to solve this in a console game: run a single event loop that polls for input and advances timers, or use threads for background work. As pointed out, threads are simple in idea but easy to get wrong; for many small games a single-threaded loop is simpler and more reliable.

A typical single-threaded pattern:

while (running) {
  now = steady_clock::now();
  delta = now - last;
  accumulate += delta;
  while (accumulate >= fixedStep) {
    update(fixedStep);
    accumulate -= fixedStep;
  }
  if (inputAvailable()) handleInput();
  render();
  sleep_short();
  last = now;
}

Use std::chrono::steady_clock for timing to avoid clock jumps (see the C++ chrono docs). For non-blocking console input: on Windows use _kbhit()/_getch() (conio.h), on POSIX set the terminal to non-canonical mode and poll with select()/poll() or read with a timeout (see POSIX termios/select docs). Cross-platform libraries like SFML or SDL remove these platform differences and also give clean timing and input APIs.

If you do need threads, keep them focused: put I/O, networking, or expensive file ops in worker threads and use a thread-safe message queue to communicate with the main loop. Prefer std::thread, std::mutex, std::atomic, and std::condition_variable and avoid shared mutable state where possible. Always join() threads (or have a clear shutdown protocol) and use RAII locks (std::lock_guard) to avoid deadlocks. See the C++ threads reference for the standard tools.

Common traps: busy-waiting instead of sleeping, data races, and forgetting to join threads. Use sanitizers or logging to reproduce race conditions. For a simple text game, start with the single-loop model and only add threads when a clear need appears.

Recommended Answers

All 2 Replies

Member Avatar for Narue

I heard I could do this with multithreading (which apparently is very complicated).

You heard correctly. While threading is conceptually very simple, the subtle and difficult to trace errors of shared data access makes it among the harder things that most programmers have to deal with.

Is there any other way to do this?

Not if your goal is to avoid the complexity of threads. Other methods of achieving concurrency are just as complicated.

If not, where should I start to learn about threads and multithreading (I have never used threads/anything like this before)?

Have you tried Google?

Member Avatar for ben1996123

You heard correctly. While threading is conceptually very simple, the subtle and difficult to trace errors of shared data access makes it among the harder things that most programmers have to deal with.


Not if your goal is to avoid the complexity of threads. Other methods of achieving concurrency are just as complicated.


Have you tried Google?

Ok, I managed to get it working with the help of this website:

http://www.codeproject.com/KB/threads/MultithreadingTutorial.aspx

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.