Author Topic: Announcing: SkeletonGame - Making PyProcGame programming a little easier  (Read 15204 times)

MOcean

  • Moderator
  • ****
  • Posts: 822
  • Michael Ocean
    • View Profile
You can download PyProcGameHD+SkeletonGame, an automated Windows installer, and find documentation on the web, here:

http://SkeletonGame.com

---

I've been working on this for a while, and it's still not totally done, but there's no reason to keep it a secret.  Plus if more people are eager for it, then maybe I have more pressure to get it done.

"SkeletonGame" is my attempt to make a proper third tier on top of BasicGame; think of it as the logical continuation of Starter.py --that is, if starter were a class that people were expected to subclass.  SkeletonGame is just a bunch of additions to  pyprocgame. It leverages everything that those of use who use PyProcGame know and love, and only intends to streamline some things for new users.

Motivation-: Most people who learn PyProcGame programming have done so by looking at existing open-source games and there are many good ones to learn from.  Unfortunately, the copy/paste/merge process is fairly error prone. I've done it a few times now and it gets dangerous with sequence dependant, asynchronous (i.e., event-driven) code that spans multiple files. Suppose 'project A' assumes that the attract mode will call start_ball(), but 'project B' assumes that start_ball() is called by the trough handler --depending on what you grab and from where, you may wind up with no balls in the trough or two balls.  Worse I've seen and encountered plenty of instances of the game appearing to be hung or crashing because some event doesn't occur due to functions being called in the wrong order as a result of copy/paste/merge-fail. Having worked on a few P-ROC projects now, I've tried to distill the common bits from each of those games so that I can avoid rewriting the same lines again and again.

Goals:If SkeletonGame works, it means you (as the programmer) should:
  • have VERY few lines of code in your game class.
  • spend most of your time coding the logic for modes.
  • be able to leverage fairly standard modes that have been written before.
  • use helpers to create DMD content (in code) much easier.
  • get started quickly.

SkeletonGame includes:
The following things are included by default, so you don't have to code them or include any code to activate them:
  • new BasicGame subclass: 'SkeletonGame' that tracks ball counts, ball time, game counts, game time, loads/saves settings and data, propagates game-level events (ball_starting, _ending, game_starting, _ending) to any mode in the queue that has a handler for those events. This class will serve as the new superclass for people's games.  This class automatically includes
  • assetManager (all your images, sounds, music, fonts are pre-loaded by defining a yaml file)
  • better Player class: supports player state tracking built in with appropriate methods for access.
  • soundController mode auto created and loaded
  • OSC mode auto loaded (though apparently based on an old version)
  • trough management (based on Adam's)
  • service mode (basically Adam's) that senses dmd size
  • high score entry (based on Adam's but in color) that senses dmd size
  • high score frame generation for display in attract mode
  • score display essentially based on Adam's but updated to use color fonts, background animations, etc.
  • dmdHelper "mode" that generates a message on screen shown over a single image/animation, or a stack of them. It works like:
Code: [Select]
displayText(text, key)
If key is a list, it builds a grouped layer for all the keys. If text is a list instead of single string, all the text is shown on the frame. A single line is centered vertically, two lines are shown at 1/3, and 2/3, three lines at 1/4,2/4, and 3/4... You get the idea.
  • bonus support (just like score: bonus(tag, quantity) with a bonusTally mode that reads a yaml file to learn about valid tags, score per award, Max numbers to allow of said award, etc. the tally is still in progress --this is not totally done.
  • Other modes such as tilt, and chasing skillshot are coming

AdvancedMode (a new optional subclass of Mode)
AdvancedMode has two features to (try to) keep the programmer from needing to change the Game (class) code:
1- a "lifecycle type" (ball, game, system, or custom) --modes are auto added/removed based on that type. They only need to be created by importing them in the game code and creating them in init. Skeleton game adds/removed them as per their type.
2- a refined set of game progress events that get sent to Modes, in priority order, if they have an appropriate listener. Now modes themselves can respond directly  of game_starting, ball_starting, ball_ending, game_ending events. Modes can also request to postpone the event, though every time I come up with a reason to actually use the postpone, I have just added a new mode to bundle (the last was bonusTallyMode).

If AdvancedMode sounds stupid, and you hate it?  Fine, don't use it.  You don't need to.  You can use normal modes just fine, but you can still take advantage of 'game-level'- events and the other stuff too.

What else?
Documentation: There will be some, and I'll also provide a simple sample to get started from.  Also existing PyProcGame code will still work, of course.  This isn't meant to be a major change.  Just a major convenience.

There's probably a lot more to say, but the more I say, the less time I spend working on this and other things, so... back to it!

Have questions/comments?  Ask!

Thanks!
- Michael
« Last Edit: March 29, 2017, 04:28:01 PM by MOcean »

Mark Jarzewiak

  • Wizard
  • *****
  • Posts: 244
  • Mark Jarzewiak
    • View Profile
Been anxiously awaiting this since its mention.  I plan on doing at least two games so I'm going to do one in python and one with MPF.  Thanks for doing this!

Spinape

  • Wizard
  • *****
  • Posts: 214
    • View Profile
Sounds useful to me! I will be getting it too, thanks for your work Michael

Curbfeeler

  • Wizard
  • *****
  • Posts: 239
  • Dan - Des Moines, IA
    • View Profile
First of all, thanks Michael for making this.  So I've been using an early version of this for about a week now with my Pinbot, and I'd like to report back and let you all know that it's very awesome! (did you have any doubt?)  The reasons that it's awesome are exactly as Michael states.  I've done the copy/paste/hack method a few times now as well.  I've had decent success, but it's not the best way to code a pinball machine.  It takes way too many hours to do way too little, for one.  And... Two balls in the shooter lane?  I've been there as recently as a month ago for the exact reasons he states.  But the biggest problem in my experience is that when your "donors" upgrade their projects, good luck trying to merge those changes back into the mess that you've made by combining multiple projects.  And that's IF you can actually get your code to work in the first place.

Just a bit of backstory on my Pinbot project.  I've decided my Pinbot will continue to use its native AlphaNumeric displays, but those displays will be used only for displaying the score, similar to classic Bally/Stern.  In addition, it will have a virtual DMD in the apron for interacting with the player and providing animations and instructions during gameplay.  I'd previously hacked my way through Scott's Earthshaker code and Jim's Whirlwind code and made pretty good progress, but I decided to start over once I heard Michael describe SkeletonGame.  It really sounded ideal, plus it uses HD_DMD, which for me is a must.  I have not attempted to interact with the native displays yet, but that day will come, and I don't expect issues.

So the good news is that all the modes I wrote previously are being converted over to SkeletonGame with no issues.  I plan to do a video tomorrow evening and show my progress, but so far so good on this thing.  It was worth the wait, to be sure.  Thanks again to Michael for giving this to the community.  It's a powerful template and set of tools!

Dan

bonnevil69

  • P3 Developers
  • *
  • Posts: 698
  • Matthew Bonnema
    • View Profile
  Very cool Michael   I look forward to checking it out when im writing code for the next game   Thanks for doing it
 
-Matt
DeadPin and Doom

Mark Jarzewiak

  • Wizard
  • *****
  • Posts: 244
  • Mark Jarzewiak
    • View Profile

So the good news is that all the modes I wrote previously are being converted over to SkeletonGame with no issues.  I plan to do a video tomorrow evening and show my progress, but so far so good on this thing.  It was worth the wait, to be sure.  Thanks again to Michael for giving this to the community.  It's a powerful template and set of tools!

Dan

Looking forward to the release and to your video. 

uncivil engineer

  • Wizard
  • *****
  • Posts: 118
  • Alan
    • View Profile
Being that I am in the midst of a 'paste-and-hack-and-learn-python' coding spree, this would be very helpful.  Do you have the code up on Github anywhere?

MOcean

  • Moderator
  • ****
  • Posts: 822
  • Michael Ocean
    • View Profile
Not yet, but hopefully soon. I just had a good exchange of emails with Dan that pointed out some things that I missed; chief amongst which is good documentation. There were some features he didn't know were there (coincidentally related to player state management) that I forgot to tell him about... There are a few things like this that will get banged out quickly now that I have a user

If you really want to jump in the fray now, I can send you a link? but honestly I'd wait like a week. Maybe less.


Being that I am in the midst of a 'paste-and-hack-and-learn-python' coding spree, this would be very helpful.  Do you have the code up on Github anywhere?

uncivil engineer

  • Wizard
  • *****
  • Posts: 118
  • Alan
    • View Profile
I'm not that deep into my code yet.  Plus, using the old code is forcing me to examine the procgame code.  Doing that has taught me a lot about how python and proc game works.  So I can wait for the polished code.

I think good documentation is underrated.  So take your time on getting it right. 

Curbfeeler

  • Wizard
  • *****
  • Posts: 239
  • Dan - Des Moines, IA
    • View Profile
I plan to do a video tomorrow evening and show my progress, but so far so good on this thing.


Quick update.  The video I made today was horrible!  Going to delete it and post a proper video tomorrow, sorry.  I have the day off and want to take some time to do the thing justice.

Dan

EDIT:  Video posted in my Project.  Sorry man, I'm really not trying to pimp my own project here.
http://www.pinballcontrollers.com/forum/index.php?topic=1504.msg13720#new
« Last Edit: March 14, 2015, 12:46:16 AM by Curbfeeler »

Mark Jarzewiak

  • Wizard
  • *****
  • Posts: 244
  • Mark Jarzewiak
    • View Profile
Really getting anxious for this.  I've got the P-ROC back in DW and while I can't get pinmame going just yet, I've tested jd.py with my yaml just to make sure it would start up and work properly and all seems good.  I think this will be my path forward for DW, at least for starters. 

MOcean

  • Moderator
  • ****
  • Posts: 822
  • Michael Ocean
    • View Profile
Sorry. I was actually just getting back to this today. Less about new features and more about documentation.

There are a few moving pieces that are slowing this down. In increasing order those factors are:

I need to push out the latest hd dmd code. Since SkeletonGame depends on that, it's hard to release this first.

Also I also have a pretty central feature that I really want to keep in the SkeletonGame framework, but I can't come up with a way to make it easy enough to use, so I might just scrap it.

And finally, this hotel nonsense/ongoing construction at my house is finally wrapping up, and I should be back in my house early next week. That might help my productivity, too.

Sorry to make you wait!!

Mark Jarzewiak

  • Wizard
  • *****
  • Posts: 244
  • Mark Jarzewiak
    • View Profile
Sorry. I was actually just getting back to this today. Less about new features and more about documentation.

There are a few moving pieces that are slowing this down. In increasing order those factors are:

I need to push out the latest hd dmd code. Since SkeletonGame depends on that, it's hard to release this first.

Also I also have a pretty central feature that I really want to keep in the SkeletonGame framework, but I can't come up with a way to make it easy enough to use, so I might just scrap it.

And finally, this hotel nonsense/ongoing construction at my house is finally wrapping up, and I should be back in my house early next week. That might help my productivity, too.

Sorry to make you wait!!

Well, not everything has to be easy to use.  Guess I can wait  ;)

Take your time, I'll survive.  I'm still going to be poking around and seeing what kinds of things I can get figured out.

Mark Jarzewiak

  • Wizard
  • *****
  • Posts: 244
  • Mark Jarzewiak
    • View Profile
Bump for motivation, and because I want to start using this for a rewrite!

MOcean

  • Moderator
  • ****
  • Posts: 822
  • Michael Ocean
    • View Profile
Bump for motivation, and because I want to start using this for a rewrite!

I'm working on it right now.  Literally.  I changed some details of the event system last night and now I'm getting some strange behavior that I'm trying to track down.  I guess I could have left well enough alone, but good is the enemy of great!

Anyway, before I broke that part, I wrote a new attract mode that uses a yaml driven config to generate the frames for you.  This is what my attract.yaml file looks like.

Code: [Select]
Sequence:
    - Combo:
        Text:
            - "MOcean"
            - ""
            - "Presents"
        Font: large
        lampshow: attract_show_1
        duration: 2.0
    - Animation:
        Name: t800-war
    - Combo:
        Text:
            - "Terminator"
            - ""
            - "2.0"
        Font: large
        Animation: chrome
        FontStyle: blueish
        lampshow: attract_show_2
        duration: 2.0
    - HighScores:
        Font: large
        Background: chrome
        Order:
            - player
            - category
            - score
        duration: 1.0

Oh, and I added font styles and lampshows to the assetManager so they are parsed from the asset_list.yaml.  I also try to fully validate lampshows on load (by loading them and resolving all their drivers) because I'm sick and tired of having a game blow up 4 minutes into testing because a lamp name was renamed from an older version of the code, but I never updated the lampshow.