Game Development with Java – Full Stack – Part 2

Teacher

omoniyi

COURSE DESCRIPTION

Happy learning from part 1. In this part of the course, we will start with the basic concept of computer science that will take you into another aspects of computer science called computer programming, where you will understand the general concept of computer programming, and take you deeper into specialized programming language (Java). This course aims to give you what it takes to become a world class software/game developer.

CERTIFICATION

On completion.

LEARNING OUTCOME

Module 10: Java GUI/Game Programming
- Understand Threads and Create a Screen for Games
- Restoring Screen Size and Full Screen Display
- Understand Images and Animation Processing
- Understand Scenes Manipulations
- Understand Full Screen with Buffer Strategy
- Understand Sprites Movement and Handling Key Events
- Understand Mouselooks draw Method and Using the Robot
- And Many More …
Module 11: Full Stack Implementation – Real World App
- Creating Window and Adding Object to the Window
- Understand Game Loop, Arrays and Drawing Pixels
- Understand how Rendering Works
- Understand 3D, Floors and Animation
- Understand how to Create Basic Movement
- Understand Graphical User Interface (GUI) Launcher
- Understand Color Processing In-Depth and High Resolution Rendering
- And Many More …

SYLLABUS

Week 10: Web Programming – Module 10
Week 11: Web Application Development – Module 11
Week 12: Web Application Development with Java – Module 11

CAPSTONE PROJECT

Topic: Hospital Emergency Simulator (Game)

The current usage of games is mostly for entertainment purposes but research has show how games can be use to change the way we live our lives and how they can actually contribute to our “resilience and well being”.
The game contains a database of patient types, each corresponding to a particular disease such as pneumonia, heart attack, or narcotic overdose. Each patient type is associated with a set of possible vital signs, physical exam signs, and a set of predetermined responses to player actions. These parameters are set for each patient based on current knowledge of the disease pathology.
The player will be able to choose from a series of actions and investigations in response to the patient. The object of the game is to respond appropriately in a given timeframe to the vital signs and parameters. The proper actions that should be taken are determined by basic principles of pathophysiology, as well as current guidelines in resuscitation medicine.
In designing the game, particular attention should be paid to abstracting the graphical interface from the patient medical information so that I can quickly and easily update the patient database as needed. It is important that the focus is on accurate medical information rather than on realistic graphical rendering

Overall Description
The game offers on demand, probabilistically generated scenarios encompassing almost every type of
life‐threatening issue that can arise in the emergency room or hospital setting at one’s computer at any
time, without a simulation technician or an instructor. It teaches the basic guidelines of how to stabilize such patients appropriately before they get definitive care, as well as how to generate the line of communication for the patient to get the type of definitive care that particular patient needs.
The game will be designed in such a way that modularizes the components of the game into the
generation of patients and vitals, the graphical representation of the scenario, and the input options of
the player. A probabilistic engine “throws” patients at the player in a distribution consistent with typical epidemiological patterns. Rather than having a set value for each parameter associated with each
patient‐type, these values are generated based on probabilistic distributions consistent with that of the
patient‐type’s underlying disease. As the player must respond to both the parameters generated as well
as aspects of the underlying disease, the player may need to respond differently to two patients of the
same type, consistent with real life.
The database of patient‐types, the probabilistic methods that the game uses to choose a patient‐type
and the parameters of that particular instance of the patient‐type, and the streamlined method for
creating new patient‐types without affecting the other aspects of the game differentiates this simulation
game from other type of simulations.
The graphical look of the game should be developed with significant thought as to what was essential to
impart the necessary information.
There should be four types of graphics in the interface. The first should be strictly informational graphics that display the information about the player and the patient. The patient’s vital information should not be initially visible but could be turned on by the user. The informational graphics are simply drawn on the screen as they are.
The second type of graphics correlate to the actions the player can take in order to gain more information about the patient, for instance turning on the monitors to see the patient’s vitals. An
informational‐action is triggered by the user interacting with its corresponding graphical button, and the action itself should has the ability to affect the graphics of the game only.
The player also should be able to trigger intervening‐actions in a similar way. Interacting with this third type of graphics will also affect the game’s interface, and in addition, has the ability to affect the patient’s state stored behind the scenes. An example of an intervening‐action is putting an oxygen make on the patient; this will update the graphics so that the mask is visibly on the patient and may cause the patient’s oxygen saturation to rise.
The last graphical category is the display of the patient. Each patient should be represented by the same generic image that displays different physical symptoms based on the patient‐type. Currently, this generic image depicts a male. One or two more generic images will be added to have gender‐specific patient-types.
You can consult with a few professionals who have experience with representational graphics and game interfaces as part of this project. It is important you give the complexity of the game to ensure that the interface is as clear and streamlined as possible to help ease the learning curve of gameplay.
The interface are an important influence on the player’s actions during the game. The simplicity of the
interface allows for the visible display of physical symptoms of the patient. This gives the player the
ability to enhance the crucial skill of using his eyes to access the patient. At least three‐quarters of the typical physical exam a doctor must perform on a patient can be accomplished in the game without
clicking any buttons. Instead, the player must learn to use his eyes and past experience to determine
how to respond appropriately to the patient.
Once the player has visually assessed the patient, he must determine what actions he wants to take.
The set of actions a player can take is independent of the presented patient. This corresponds to real
life scenarios in which one has the ability to respond to a patient using any of the medical tools
available, though some may be helpful and others harmful. The player is presented with two types of
actions to take: informational‐actions and intervening‐actions. As mentioned briefly above,
informational‐actions are used to provide the player with information that he was not presented with in
the visual assessment and affect only the graphical interface.
Intervening‐actions are those taken by the player to treat the patient once they have finished their
assessment. These actions will affect the graphical interface and will also have an effect on the patient’s vitals stored behind the scenes. If the action affected the vitals displayed on the monitors and the corresponding monitor is on then these changes will be visible to the player on the monitors as well.
As more levels are added, the actions the player can take will become more complex and we will have
the ability to add those in as needed. Again, because of the modularity of the different aspects of the
game, this will be easily accomplished by first updating the graphics to include the new buttons
corresponding to the new actions and then adding in the effects of the actions on the code.

1.1 Development Tools

Back-end development – Java; Database – Mysql or NoSQL
Front-end development – Java tool
Editor – Use editor of your choice.

Conclusion
In designing the game, particular attention has to be paid to abstracting the graphical interface from the patient medical information so that you can quickly and easily update the patient database as needed. It is important that the focus is on accurate medical information rather than on realistic graphical rendering.
I advice you consult a medical person for a better understanding of medical environment.

Project Duration: 1 Month