Request For Comments: P-Machinery improvements

[+Gemintronic]

Ha! Er, I guess I just came back from a time warp. Thought P-Machine was done and you were asking about potential improvements. I guess my point is, maybe a higher level language isn't needed if a good development environment/IDE is available.

[+DZ-Jay]

Ha! Er, I guess I just came back from a time warp. Thought P-Machine was done and you were asking about potential improvements. I guess my point is, maybe a higher level language isn't needed if a good development environment/IDE is available.

 

Well, P-Machinery 1.0 was done, but it only offers the most basic game engine and task queue. I am working on version 2.0, which should offer a more complete game development environment. Indeed, I was asking for ideas on what to incorporate in that one.

 

Your idea of an IDE has merit, (I myself am not that good with a plain, command-line debugger). Hopefully we can get to that someday.

 

-dZ.

[+Gemintronic]

My idea would be to further structure the framework. Divide things into screens and objects. Allow for an event driven system. For instance, screens could have startup code. Objects could have creation events, events that happen once per engine cycle and collision events with other objects. All this could be put into the game template. If you already have a task queue you may as well use it to offer an event driven system.

[+DZ-Jay]

My idea would be to further structure the framework. Divide things into screens and objects. Allow for an event driven system. For instance, screens could have startup code. Objects could have creation events, events that happen once per engine cycle and collision events with other objects. All this could be put into the game template. If you already have a task queue you may as well use it to offer an event driven system.

 

Haha, too late for that! That's the essence of P-Machinery: an event-driven state machine. What you call "screens" P-Machinery calls "levels," but it's the same thing. Basically, you have various game states, such as "Title Screen," "Game Play," and "Game-Over." Each main state is subdivided into sub-states, such as "Initialization," "Wait for input," "End transition," etc.

 

The entire thing is intended to be used in an event driven model. So far, P-Machinery 1.0 did not include many events--except the state transitions and the controller input decoding. However, in P-Machinery 2.0 sprite movements and other things like that would be handled this way.

 

By the way, I don't expect there to be a "Game Template," that is not the goal. It is intended to be just a development framework. It will be general enough to fit many game models, though perhaps not all. It will have enough default behaviour appropriate for most games, but not force the player into any particular style.

 

It seems that you are thinking in similar ways.

 

-dZ.