0

I'm currently working on a mini game project, and I have a problem with this specific mechanic:

void monsterMove(){
   //monster moves randomly
}

void playerMove(){
   //accepting input as player movement using W, A, S, D
}

However, the project requires the monsters to keep moving at all times, even when the player is not moving.

After some research, I figured out that multithreading is needed to implement this mech since both monsterMove() and playerMove() needs to run concurrently even when playerMove() hasn't received any input from user.

Specifically there are 2 questions I want to address:

  1. Which function needs to be made as a thread?
  2. How to build the thread?

Sadly, I found no resource with specifically this type of question because everything on the Internet just seem to point out how multithreading can work as parallelism in a way, but not in such implementations.

I was thinking that monsterMove() will be run recursively while playerMove() will be made as the thread, since monsterMove() will need to run every n seconds even when playerMove() thread is not finished yet (no input yet). Although I might be wrong for the most part.

Thank you in advanced!

(P.S. Just to avoid misunderstandings, I am specifically asking about how thread and multithreading works, not the logic of the mech.)

Edit: Program is now working! However, any answer/code related to how this program is done with multithreading is immensely appreciated. :)

bolakecil
  • 66
  • 1
  • 7
  • 3
    What is your platform? Anyway, you don't need multithreading for this. – Jabberwocky Jun 11 '22 at 08:26
  • @Jabberwocky I'm using Windows! Oh, and I did try to use `kbhit()` to imitate the progress, yet my mentor pointed out that I need to use multithreading for this question. Just curious, can you detail the non-multithreading solution? – bolakecil Jun 11 '22 at 08:29
  • 1
    @bolakecil A non-threaded version would just scan the keyboard in a non-blocking fashion – Ted Lyngmo Jun 11 '22 at 08:35
  • @bolakecil maybe you should ask your mentor why he thinks multithreading is necessary here. – Jabberwocky Jun 11 '22 at 08:40
  • 2
    IDK why your mentor is dead set on multithreading, this is the typical situation that is solved in a single thread using a "game loop" that runs at a fixed rate - at each iteration input is checked in a non-blocking fashion, state is updated (or not) accordingly, all components actions are evaluated and finally a new paint is done. It's also similar to how GUIs work anyhow (it's not like there's a thread for each widget on screen to keep it updating even if the user doesn't interact). – Matteo Italia Jun 11 '22 at 08:41
  • 1
    @bolakecil Everything except the implementation is available in Jabberwocky's answer below. `if(_kbhit()) { char ch = _getch(); ... }` – Ted Lyngmo Jun 11 '22 at 09:14
  • @MatteoItalia well, a GUI has nothing else to do after a paint and so will block on its input message queue. So, it's not quite the same:) – Martin James Jun 11 '22 at 09:16
  • Thank you everyone! I manage to get the program up and working (without multithreading stuff). – bolakecil Jun 11 '22 at 09:28
  • 2
    I wish teachers would make it clear if the intention of some homework is to use a certain mechanism like multithreading (no matter how usefull/useless that is) or just to solve the task in an efficient way. – Gerhardh Jun 11 '22 at 11:20
  • @MartinJames yeah but you can set timers... but it's true, the comparison was a bit misleading, as a game loop is "more" like polling, a GUI is "more" event based, my the point was that you still have lots of stuff going on (multiple objects receiving lots of events) with a single thread. – Matteo Italia Jun 11 '22 at 11:52
  • 1
    @mar The comparison is actually far more accurate than you make it appear. There's nothing wrong with spreading game state and graphics calculations across as many threads as the hardware supports. When it comes to input processing (both user as well as AI) you will want to keep that absolutely synchronous. A game is only special in that its GUI *is* the game, but like any other GUI you do not want it to reflect an inconsistent or stale state. Keeping input processing single-threaded is a common way to make sure this is the case. – IInspectable Jun 11 '22 at 13:03

1 Answers1

2

You don't need multithreading for this:

The basic structure is depicted in this pseudocode:

while (1)
{
   check if input is available using kbhit

   if (input available)
     read user input using getch

   move player depending on user input
   move monsters
}

You could use multithreading using the CreatdThread function, but your code will just become overly complex.

Jabberwocky
  • 48,281
  • 17
  • 65
  • 115
  • Ah! I might be not specific enough in this, pardon me. With the code above, the monsters won't move until any input is accepted, correct? I need the monsters to move even when the user hasn't inputted anything, just like how the ghosts will move in Pacman game without us moving. – bolakecil Jun 11 '22 at 08:57
  • 1
    @bolakecil no, if you had read the documentation of `kbhit` you would know that this function is non blocking. I made the answer more clear – Jabberwocky Jun 11 '22 at 08:58
  • AH! Thank you. After analyzing your answer, it seems to me that I put `monsterMove()` in the wrong order, hence bugging. Now it's giving my desired output :) Thank you! – bolakecil Jun 11 '22 at 09:27