P-Machinery Theory

[+DZ-Jay]

I thought I'd include some basic theory on the use of P-Machinery, in lieu of writing an actual tutorial and guide (which I truly plan on doing, I swear!).

 

Overview:

P-Machinery is a simple game engine and programming framework for making Intellivision games. It is not a game designer wizard nor a full-feature development kit, but more of a programming model to simplify making games. It does include some basic infrastructure that takes care of a lot of under-the-hood housekeeping, letting the programmer concentrate on actual game-play logic.

 

P-Machinery uses an event-driven and task-driven model for the programmer. The game engine tugs along in the background, looping indefinitely, and whenever certain conditions or events arise, the specified handlers are executed.

 

This means that you don't have to worry about iterating through lists of tasks or figuring out how to put it all together--you just define your events by scheduling tasks or adding them to centralized game state handlers, and the appropriate code will be called at the right time.

 

A Simple State-Machine:

At its core, P-Machinery is a state machine that describes the various states in which your entire game could engage. By default, P-Machinery includes only three basic states. These should be sufficient for most games, but you can easily add more. The three basic states are:

• Title Screen - Displays a title screen and waits for input from the user to start the game.
  
• Game-Play - Iterates through the game-play loop indefinitely until the player dies.
  
• Game-Over - Ends the game and waits for input from the user to start a new game.
  

These three states are sub-divided into various sub-states. For instance, the "Title Screen" state can be sub-divided into "Initialization," in which the title screen is drawn; "Wait," in which the screen is just frozen, waiting for user input; and "End," in which the tittle screen is cleared and the game is engaged. Engaging the game means switching internally from the "Title Screen" state to the "Game-Play" state. P-Machinery provides handy macros and procedures to encapsulate state transitions and a simple dispatch table where you define the individual handlers for each of these states and transitions.

 

The Task Queue:

The most important part of P-Machinery is the Task Queue. This is the mechanism that P-Machinery uses to manage all game events, states, and scheduled tasks. In order to take advantage of this, you'll need to start thinking of your game as a series of tasks, or events, on which the game logic should react.

 

Let's consider a simple example, say, Pac-Man. If we break Pac-Man down into a series of reoccurring events, we end up with the following model:

 

On every game-loop iteration, we must:

• Check for user input and update his direction
  
• Re-compute Ghosts' target (AI)
  
• Update Pac-Man's position based on his velocity and direction
  
• Update Ghosts' positions based on their velocity and target
  
• Check if a collision occurred
  
• Update sound-effect and music state
  

By itself, P-Machinery does not do any of these. However, it offers a handy, built-in game-loop that calls a built-in routine on every iteration. This routine by default does absolutely nothing but enable the video display and update the video chip's registers to their latest values.

 

You can easily update this built-in routine with your own code to do the above. However, rather than just writing all that code in-line, you could create individual routines for each task and just add them to the queue. They will then be executed in the order they were added (FIFO, or First-In, First-Out).

 

Now, each of those tasks can result in changes to the game state. Consider the second to last task, "Check if a collision occurred." What if Pac-Man collided with a Ghost at this very point? Well, your collision detection code can then add another task to the queue that will update the game state from "playing" to "dying." P-Machinery will then update its own internal state and on the next game-loop iteration the "Pac-Man Death" handler will be engaged.

 

That way, you do not need to write code to connect one piece of logic to another. Instead of thinking in terms of a straight flow of logic, such as "if Pac-Man collided with Ghost, then we must do this...," you should think in terms of actions and reactions, events and handlers:

 

Event:

Pac-Man collided with Ghost

Reaction:

Engage death sequence

 

You break down the logic into small individual tasks, and write short, concise functions to handle each one. When the conditions are right, you add the appropriate function to the task queue, and let P-Machinery process them.

 

An Example:

An example of this event-driven model is Christmas Carol's "collision detection" logic. The collision logic is broken down into the following routines:

• PICKUP_PRESENT - check if Carol collided with an available present
  
• EAT_CANDY - check if Carol collided with a piece of candy or a snowflake
  
• STEAL_PRESENT - check if Carol collided with the Ghost
  
• KILL_ELF - check if Carol collided with the Snowman
  

On each one of these, a set of tasks are added to the queue depending on special conditions. For instance, after PICKUP_PRESENT detects an actual collision, it sets up the following tasks:

• DO_FLOAT_POINTS - displays a cool animation of score points floating up
  
• ADD_SCORE - adds the appropriate number of points to the player's score
  
• REMOVE_PRESENT - hides the present just picked up, and updates the present counter
  

In addition to these tasks, if Carol happened to pick up the last present, the game-state is changed to "Level End." This disengages the "Game Play" state. P-Machinery will then call the defined state handler for this new state, and the end-of-level logic is executed.

 

-dZ.

Edited February 2, 2012 by DZ-Jay

[First Spear]

I just listened to the Intellivisionaries podcast, and what I learned there makes this post even more awesome!

 

If I could [like] this 5 more times, I would!

 

This is really, really inspirational.

 

Is there any chance you would/could release a 2014 "game starter package" that aggregates the stuff above with other things you learned to make Christmas Carol? I would love to make something 1/4 as awesome at Christmas Carol!

 

Thanks!

[+DZ-Jay]

Hi Tinty,

 

I'm currently working on P-Machinery v2.0 which will be a full-fledge game programming framework kit for the Intellivision. The first edition, discussed above and available for download in another thread, was taken directly from Christmas Carol's code. The new version is being engineered from scratch, taking into consideration all the lessons learned, and trying to build a useful framework for my own future games.

 

I hope to have something ready for release at least in the middle of the year, though I cannot guarantee it. Of course, this is still a one-man design and implementation, so it may not suit everybody, nor will it be the right tool for every game. However, I aim to make it generalized and flexible enough to allow for others to contribute and expand its utility. At the very least, and I express this from my own experience, it should be better than the utterly "blank canvas" that most newcomers encounter when first trying to dabble in Intellivision programming.

 

-dZ.

[First Spear]

"Blank canvas" is my biggest problem...

 

Maybe you could make your kit old-school "shareware" in that if someone uses it they throw you some bucks for your time. I feel like you should be compensated for making it possible for lightweights that want to get into the game (pun intended) but are discouraged by what it takes to make a successful title.

 

So thanks, I'll keep poking around and monitoring the forums, and can't wait to see what your SDK brings to the table!

[+Gemintronic]

Bitcoins!

 

Bitcoins will make DZ-Jay add in macros to make it looks more like BASIC.. yesss....