Repository navigation
jobs
If you've ever developed a game, you probably know that almost all games work the same way: they redraw the entire screen on every frame. That's exactly what we're doing here. On each frame, we call a bunch of functions to move, edit, or remove elements on the screen. This is what the JobManager does. By convention, we call each of these functions a Job.
All jobs are managed by JobManager. let me give you an example:
When you shoot a ball, it moves towards a larger ball in the center. We'll call this the APPROACHING ball. The APPROACHING ball should move closer to the target ball on each frame (until it reach's the large ball right?!). To achieve this, we call a function (so called job) that's responsible for moving the ball a few pixels closer on each frame.
So, again, All jobs are managed by the JobManager. This means that on every tick (think of a tick as each time the screen redraws), the JobManager calls all the registered jobs. This way, all jobs are executed with each engine update.
Critical jobs, as the name implies, are essential for our application to function properly. Here are some examples:
- CollisionJob: This critical job checks for collisions between balls. If a collision is detected, the engine must stop.
- MoveUpJob: As mentioned earlier, this job moves the "approaching balls" upwards.
- OrbitJob: This job handles the movement of orbiting balls on each engine tick.
There are some more Critical jobs like: SpawnJob, WinJob.
Leveraging the JobManager to handle functionalities streamlines development and allows for complex behavior without extensive coding. This approach is particularly well-suited for implementing optional features that enhance the user experience.
For instance, OptionalJobs can be used to introduce creative elements into the application. Currently, one such job exists: it randomly changes the orbiting direction during gameplay, adding a layer of difficulty.