In this part 2 of the course you’ll practice critical java code evaluation, and you’ll develop game from scratch using java and its UI rich tools. In the final Capstone Project, you’ll apply your skills to develop real-world game.
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
Course Features
- Lectures 83
- Quizzes 0
- Duration
- Skill level All levels
- Language English
- Students 7
- Assessments Yes
-
Module 10: Java GUI/Game Programming
A program's graphical user interface presents an easy-to-use visual display to the user. It is made up of graphical components (e.g., buttons, labels, windows) through which the user can interact with the page or application.
- Java Game Programming – 1 – Threads
- Java Game Programming – 2 – Starting Threads
- Java Game Programming – 3 – Creating a Screen for Games
- Java Game Programming – 4 – Restoring Screen Size
- Java Game Programming – 5 – Creating a Full Screen Display
- Java Game Programming – 6 – Making Text Smooth
- Java Game Programming – 7 – Loading Images
- Java Game Programming – 8 – Beginning Animation
- Java Game Programming – 9 – Changing Scenes
- Java Game Programming – 10 – Finishing the Animation Class
- Java Game Programming – 11 – Loading Pictures for the Movie
- Java Game Programming – 12 – Main Movie Loop
- Java Game Programming – 13 – Completing the Animation
- Java Game Programming – 14 – Making a Better Screen Class
- Java Game Programming – 15 – Finding Compatible Modes
- Java Game Programming – 16 – Comparing Display Modes
- Java Game Programming – 17 – Full Screen with Buffer Strategy
- Java Game Programming – 18 – Updating Display and Restore Screen
- Java Game Programming – 19 – Compatible Buffer Images
- Java Game Programming – 20 – Creating Display Modes List
- Java Game Programming – 21 – Run and Movie Loop Methods
- Java Game Programming – 22 – Finishing the Perfect Animation
- Java Game Programming – 23 – Introduction to Sprites
- Java Game Programming – 24 – Finishing the Sprite Class
- Java Game Programming – 25 – Starting the Sprites Movement
- Java Game Programming – 26 – Watching the Sprite Move
- Java Game Programming – 27 – Creating a Core Class
- Java Game Programming – 28 – Intro to Keyboard Input
- Java Game Programming – 29 – Handling Key Events
- Java Game Programming – 30 – Final Keyboard Input
- Java Game Programming – 31 – User Mouse Input
- Java Game Programming – 32 – Final Mouse Input
- Java Game Programming – 33 – Intro to Mouselook
- Java Game Programming – 34 – Mouselooks draw Method
- Java Game Programming – 35 – Using the Robot
- Java Game Programming – 36 – Final Mouselook Program
-
Additional Resources
-
Module 11 – Full Stack Implementation – Real World App
This module will cover Game development using the Java component available.
- Java 3-Game Development -1- Window
- Java 3-Game Development -2- Game Loop
- Java 3-Game Development -3- Arrays
- Java 3-Game Development -4- Drawing Pixels!
- Java 3-Game Development -5- How Rendering Works
- Java 3-Game Development -6- Playing with Pixels!
- Java 3-Game Development -7- Performance Boosting
- Java 3-Game Development -8- FPS Counter
- Java 3-Game Development -9- Alpha Support and More
- Java 3-Game Development -10- Beginning 3D
- Java 3-Game Development -11- Floors and Animation
- Java 3-Game Development -12- Rotation
- Java 3-Game Development -13- User Input
- Java 3-Game Development -14- Render Distance Limiter!
- Java 3-Game Development -15- Basic Mouse Movement
- Java 3-Game Development -16- Textures + More!
- Java 3-Game Development -17- Walking, Crouching, Sprinting + More
- Java 3-Game Development -18- Exporting Runnable Jars
- Java 3-Game Development -19- Small Adjustments + Birthday!
- Java 3-Game Development -20- Creating an Applet
- Java 3-Game Development -21- The Beginning of Walls
- Java 3-Game Development -22- A Few More Things
- Java 3-Game Development -23- Creating an EXE File in Java
- Java 3-Game Development -24- Rendering Walls
- Java 3-Game Development -25- Continuing Walls, Fixing Bugs, and Managing Crashes
- Java 3-Game Development -26- Texturing Walls, Fixing Clipping, and Fixing the Mouse
- Java 3-Game Development -27- Random Level Generator + Properly Fixing Clipping
- Java 3-Game Development -28- Graphical User Interface (GUI) Launcher
- Java 3-Game Development -29- Making Our Launcher Work
- Java 3-Game Development -30- Writing and Reading Files
- Java 3-Game Development -31- Custom Resolutions
- Java 3-Game Development -32- Decorating the Launcher
- Java 3-Game Development -33- Continuing our Custom Launcher!
- Java 3-Game Development -34- Launching The Game
- Java 3-Game Development -35- Colour Processing In-Depth
- Java 3-Game Development -36- Sprites!
- Java 3-Game Development -37- Sprite Mapping
- Java 3-Game Development -38- High Resolution Rendering
- Java 3-Game Development -39- Entities
-
Additional Resources