Learn Programming in Java

Event-Driven Software

Computer-Human Interaction: Who's In Control?

In all of the programs we have worked on so far, the computer is in full control. It waits for human input, but other than that, the human must conform to what the computer is expecting. This is backwards. Humans are the masters, computers are just servants. It will be a very long time -- probaby never -- before computers have the intelligence and self-image and will to do anything other than what the programmer intended them to do, like a computer with a mind, will, and emotions, in other words, to be a person.

Until then, the computer does just what its program tells it to do, neither more nor less, and the program is what you told the computer to do, neither more nor less. So when the computer is rigid, controlling, or abusive, it reflects back on you. Today we will look at how to make the computer more polite, more willing to let the (human) user be in control. It's the difference between linear programming (Unix) and event-(human)-driven (original Mac) software. Most of that is appearance, because of course the computer still only can do what the programmer told it to do, but did the programmer tell it to demand "My way or the highway!" or did the programmer allow the human user to decide what to do next?

When you use a word processing or painting program, who decides what to do next, you or the computer? You do! You choose a tool, you decide where on the canvas or in the document to apply it, you decide what words to type or what color to add it, you the human. These programs were invented for the (original) Mac. The idea of a "human interface" didn't exist before 1984 (perhaps you saw the original Mac SuperBowl commercial).

Now, as a programmer, you have the same freedom, but at a second-order level: you get to write a program that lets the human be human. Or you can push people down to the level of the machine, allowed to do only what they are told. Superstar programmers lift everybody up.

Do you remember the first of the Six (or Five) Principles? Sequence, doing things in order. With events we take that to a new level, where the human (real world) supplies the order. Your program responds to events and does what that event calls for.

Converting Flat to Event-Driven

The short answer is, you can't. When your program is driving the interaction you can take all kinds of shortcuts that are not available when you do it right. That's why the less-skilled programmers prefer to do it that way, it's a lot less work. I call it the Conservation of Complexity: either you (the programmer) do it, or your users do it every time they use the program, somebody needs to deal with all the messiness of the Real World. Better if you do it once.

I was going to except the Calculator because it has a single while-loop around the whole program, the theory being that you replace the while-loop with event handling. It works for the calculator, but not generally. In fact it wouldn't work for the calculator either, except that you only have two inputs, and they are very different in nature (1-letter command vs a bunch of digits for a number). You still need to add extra code to cope with deviations from the required sequence, operator before number, and how do you know the number is done? That's why an ordinary calculator has an Equal key; you didn't need it in our text version of the calculator, because Java (and the Kitchen computer before that, both) required an Enter key which served a double purpose.

TDD of Event-Driven Program

Do you remember all the work we went to in designing a hierarchical structure for PBJ and the Calculator and Guessing Game and RPS and Seaman? (If you don't remember, you might consider going back and reviewing). For event-driven programs, the first layer is easy:

"Any Event-Driven Program"
Initialize & Greetings
Handle Events

It's the "Handle Events" part you need to think about carefully. The previous advice we gave about considering the inputs and outputs is a good place to start. Remember, the user controls the inputs, your program merely needs to handle them. In a way, this is much easier than trying to figure out the whole program. Just list all the possible inputs, then group them in some logical way -- perhaps by what kind of effect they have on your game (or whatever), or maybe what kinds of data they act on -- and then those groups form the next layer of your design structure, for example, the Calculator:

"Event-Driven Calculator"
Initialize & Greetings
Handle Events
"Handle Events"
Number Keys
Operator Keys
Other Events {if any}

That might be enough to write code from. A more complicated program -- say Rock-Paper-Scissors or Tic-Tac-Toe -- would require more layers.

Get Started

You should make Pong your first GameEngine program (there are fewer widgets). The Pong discussion is built into the GameMaker documentation, so just go from there (ChromeBook start with Replit Pong video). You can use the Back button on your browser to resume here where you left off.

Other games that you already have working, which you can try your hand at making them event-driven -- plus they look much better in the GameEngine than with ASCII graphics:

Pong in GameEngine ----> ChromeBook start with: (Replit Pong video)
Event-Driven Calculator
Rock-Paper-Scissors with animation
Seaman with better graphics

<<Previous | ToC | Next >>

Revised: 2022 October 17