You'll want to start with the Pyglet examples because they'll show you how Pyglet itself works.  The logic is not something I can comment on because that's kind of specific to whatever you're doing.  You might try something like tic-tac-toe between two human players on the same machine, as this will give you a good handle on how Pyglet wants you to do things.
Unfortunately, the only other person I know who is using Pyglet in "real" stuff is Frastlin.  I'm not sure if Frastlin has done anything, but the only "example" I have is the beginnings of a full-blown Shades of Doom-style FPS that also contains something that I hope will end up being close to the Audiogame Unity.  And it uses Libaudioverse, so it won't run without you having Libaudioverse.  Consequently, well, it'd not help much.
If you haven't seen my other thread about Pyglet, go there now. You need these two lines.
While Pyglet is harder than BGT, it's worth noting that a marginally complex game will probably recreate everything in Pyglet's event handling modules.  I know because I did; that code is actually still up on GitHub, but I don't suggest anyone use it because Pyglet's is better.
I think I can guess what the stumbling block is, at least if you're coming from BGT.  Suddenly, time.sleep or any other "wait x seconds" function is not allowed.  I can't say anything that really makes transitioning from the style of programming where you can explicitly wait and nothing is happening to this one, but if you've been watching the development room for a while you're probably aware that "you need to transition your game to use tick methods" comes up over and over.  One of the core ideas here is to decrement counters and use an if(counter <=0) if statement for waiting, and another is to have a variable that remembers what state the enemy is in.  The latter is called a finite state machine.
As for menus and stuff, read up on Pyglet's event handling.  You can have multiple "screens", or at least that's what I call them, and the topmost gets all the key presses and events first.  This lets you have fully blocking menus like a pause or inventory screen but, more interestingly especially for online stuff, it lets you have menus that take over a couple keys on the keyboard but still let you walk around and fight.
For my current project, I'm using a custom Pyglet event to drive ticking.  This lets the topmost thing on the event stack block ticking if it wants, simply by handling the event.  The Pyglet manual is really good on this subject, so I'd  go there.
And finally, there's a Python package called blinker.  You may or may not want it right now, but keep it in mind and maybe read about it.  Some people like what it provides for things like games, myself included.  Some games and ways of arranging your logic can benefit a lot, others will benefit not at all.

Pyglet is working fine on 2.7.  Pip install pyglet, that is all.

Erm. You want pip instal pyglet at a terminal.
If you don't have pip and you're using Python 2.7.9, I believe you want python -m ensurepip at a terminal.  But I haven't upgraded because that's kinda painful.
Edit: Wheels are a thing pip processes.  Once you have pip, you may run pip install mywheel.whl, if I remember the command correctly.  But, 99% of the time, if a wheel for foo is available, pip install foo will also automatically get it for you.

Hello,
I did some stuff with piglet, but didn't like their documentation or the way they handle scripts. I didn't get past the first part.
I am in the process of writing a python library
pyaudiogame
that is much more simple to use than piglet (but so far, without the graphics) and all the examples (there are a lot) just deal with getting speech and sounds.
I would love someone who knows python a little to take a look and start using it.
I am still writing documentation (That is a lot of work!) and writing examples, but I would love it if someone else could tell me what they would like.
Currently there is:
grid support for maps and objects
menu support
speech support for just about all screen readers
a lovely way to save your game
Basic sound support

all the stuff like window creation and whatnot is already taken care of for you. You just need to overwrite pyaudiogame.App.logic.
It's super clear (I hope) and there is a template in the download I always use.
You can subscribe to the new email list from the website (if it doesn't work, check back in 10-15 minutes, it's super new and I'm still working the bugs out)
and ask me questions there.

The App
section of pyglet is too confusing. The docks are horrible and if I wish to know how to do something, I have not yet figured out how to find what I am looking for.

But pyaudiogame is much, much, much higher level than pyglet. It has, for example, a UI secton with a grid where you plug in the coords for your walls, make sounds and you have something like Entombed or a side-scroller in less than 50 lines of code.

If that is too much, it is really a thin wrapper around pygame, so you can just import pygame and draw or use the clock functions directly within your logic loop.

But something that is the bane of many young programmers is the lack of relevant documentation or tutorials with your selected platform.
So I am writing something for someone that says:
I have an idea for a game. I don't know any programming, what do I do?
Pyaudiogame gets them writing audio games as fast as possible.
If they then wish to apply their python knowledge to more tutorials, or something else out side of pyaudiogame, they totally can.
But at this point, I am not totally dependent on pygame, so if you replace app.py, event.py and mixer.py, you could use pyglet, Kivy or what ever.

I also have made it super easy (and I hope to make it even easier) for people to include something like libaudioverse into their projects.
I have done a little with the mixer module, but it is pretty much the same as pygame's module currently.

But my idea is if more people start programming games, we will get more games put out and if we have more games put out, there is bound to be some really good games...

And always the hope of an open-source project is that more people who use it, the better it becomes.

So pyaudiogame is not like pyglet in that it wraps around a C library, but it wraps around a wrapper around a C library. I am also writing as many examples and making the API as clear as I possibly can be.
I just need feedback at this early stage from not-so newbie folks just in case something they say will change the basic features of pyaudiogame.
I already, for example, have gotten suggestions to run a function directly from a menu choice, rather than returning a string so you can figure out what to do. (You can do both once I update the next push).
But so far I have not gotten any feedback on the basic infrastructure, so that is what I would like people to take a look at.

I already use pyaudiogame in my other projects if I need to save something to a pickle file, I just load everything into pygame.storage and then call
storage.save("My_save.sav")
and it pickles it.
Then
stuff = storage.load("My_save.sav")
returns the variables I loaded into storage as a dict as well as putting the variables back into storage, exactly as they were before I left.

I'm not 100% sure what you mean by event layering. Do you mean widget trees?
Where you populate a list with events and if one returns True on a key press the iteration through the event list stops and that event is processed?

I personally use something a little different, because I haven't been convinced of the awesomeness of a widget tree. I think they are somewhat restrictive and are kind of complex. I don't think I understand them totally which is probably why I don't use them.

Currently I am just having people deal with the event handler pygame has with the super easy dict of actions being returned each loop. You don't need to understand anything but if statements to get a basic game running.

I then have different screens that each have their own functions.
So for example:
if screen == "start":
start(key)
elif screen == "start2":
start2(key)
elif screen == "choose" and key == "return":
choose()

You can make it into a dict too, but you get the picture.
I think this is much easier to understand than registering events. I'm also not quite sure what advantage the widget tree has over this, other than you don't need to have a list of screens and their functions, you just have functions that change the widgets in the event list.

yes.  Though I have never heard them called widget trees.  If you are thinking WX event handling, that's similar but not the same.  In audiogame_engine, the topmost screen always gets the event first; if it doesn't handle it or wants to pass it through, the next screen down gets it and etc. until one of them stops it, or there are none left.
In most frameworks for this kind of thing, you only get a stack.  A screen or the equivalent will do whatever it needs to to get the world ready for the next one, say stopping all  sounds, and then push it on top.  When the new one is done, it pops itself back off and has either modified the world or called a function somewhere to indicate your choice.  Or whatever, really.
if you need to pop multiple screens off, that needs to be coded in the screens themselves.  I.e. if escape is supposed to get rid of all the menus, then each menu needs to detect the closure of whatever submenu screens it has open in that manner somehow.  It is probably easier to make a generic menu/submenu screen that you populate with stuff, say menu items and callbacks for if they're selected.  I'm not sure if you're saying that audiogame_engine doesn't let you pop multiple screens at once and you want to or something completely different.
Pyglet does basically this, but better.  in Pyglet, you don't have to inherit from a magical base class that magically does stuff and you can define new events, say incoming network message.  The Pyglet programming guide does a pretty good job explaining the how, but the why is basically not there.
What you end up with is something that's a little more complicated individually, in that you have to type some boilerplate framework code around it.  But it's better than the one taken together: you won't have 20 if statements that do different things depending on some sort of state variable and a function that goes on for a very long time dealing with it.
As for when you really, really need it though?
Items that add one-off keystrokes.  Just push some event handlers that intercept keystrokes that item is interested in.  A flute, for example.  That you play with the number keys.  There are other ways of doing this, but the general system here is sufficient to do it.
Modaless menus and dialogs.  A modal dialog is something like a pause screen or inventory screen in an offline, single-player game: while you are in it, nothing else happens.  A modaless menu, supposing that I am spelling that term right, is the opposite.  So, say, a spellcasting menu that doesn't stop gameplay and takes over a couple keys somewhere.  Or a combat system like Final Fantasy XII where you select all your attacks and stuff but can walk around the whole time.  Or basically every menu ever in an online game.
You can do games without it.  It's just something you're eventually going to end up using.  Other types of apps like WX use it; it's pretty common to have a setup like this.  The point is mostly separating logic for reasoning purposes.

Yeah. I think so.  You seem to get the gist anyway.
But:
First, you can use Pyglet for everything and Pygame for sound, I believe.  I'm pretty sure that Pygame doesn't specifically take over the main thread like Pyglet does, and coding this stuff yourself is a waste of time if you can help it.  I'm also pretty sure that Pygame isn't going to go much further with loading audio types; ogg only, as I recall.
Second, just copy avbin.dll to the directory with python in it.  Alternatively, copy avbin.dll to the directory with your stuff in it, but you'll need to launch from a terminal with the current directory set there.  Or use this bit of hackery that works only on Windows:

import ctypes
avbin= ctypes.cdll.LoadLibrary(path_to_avbin)

And then make your engine find an avbin.dll that's distributed with it and run those lines before the first Pyglet import.
Dhruv (sorry about spelling) just figured this out and can probably tell you what you have to do more specifically.  I have Libaudioverse, as always.
Edit:
you should probably also encourage subclassing and not actually lay out the actual code like that.  Also, split up the functions, say tick and key_down and key_up, for example.  I'm not sure if this is a rough prototype or how you intend to actually lay it out, but that's awful imho if that's how you're actually going to do it for all games.  Shows good mastery of first-class functions, though.

Everything that's actually worth using does the WXPython main loop.  It's called the event loop, and you'll probably end up just duplicating it yourself.  Twisted, Pyglet, lots of stuff.  The fact that Pygame doesn't has always baffled me as getting that right is actually not as simple as it looks.  You can get a basic one working, but you can't get it doing all the power saving stuff and with precise timing and all that like they do so easily.  WX doesn't have a choice though.  Their main loop is so complicated (and has to be) that you'd never really be able to duplicate it.
As for cross-platform accessibility, you can't.  It can't be done.  This has to be done on a per-platform basis.  There is no choice.  I wouldn't hold your breath on Kivy, and Kivy is, as you said, decidedly not simple.  I'm going to probably have to go over there now.
As for Libaudioverse?  Well, yeah, I do want to make money.  But I still maintain: Pygame for sound, something else for, well, everything else.  Or just use the avbin hack.
Do note: you can almost certainly get the Pyglet and WX event loops going in the same app.  I'm about to try this; it doesn't look overly hard.  The Pyglet guide tells you how to make your own Pyglet event loop function, and the WX event loop does have support to call stuff every so often.  This lets you have the game-oriented Pyglet event handling for game stuff and the WX widget-oriented event handling for the WX stuff.
Don't use decorators.  Make people subclass your screens.  This is simple, programming language agnostic, and pretty standard.  Also, yes, you do want to break it into functions.  Your idea of actions as things that happen every tick is kind of off: a key may be pressed at any time, for example.  Whether the engine makes it part of the tick is beside the point; it shouldn't be conceptually exposed that way.  Make a base class, give it empty event handlers: on_key_down, on_key_up, on_mouse_move, on_tick.  Those should be sufficient and should take different arguments depending on what they're for.  The action fo jumping should happen through setting the is_jumping flag or the jump_next_tick flag, not through having tick read controls directly.  The latter does not allow for control remapping or platform-neutral anything, really.
You probably won't win me to your engine, but you probably aren't expecting to.  My personal effort is already at the point where I'm putting in generic object editors which allow one to, well, edit objects.  It's decidedly not basic, but it's looking like it's going to end up being more powerful than I expected going in, which is actually really nice if true.  I suppose that part of this is that I don't care so much about making it super friendly to new programmers, I care about making it powerful enough you could write online games and Shades of Doom clones with it pretty easily.  This does mean adding complexity at the beginning; there's no really good trade-off here, and I'm far enough along that it's not worth cutting out complexity if that means cutting out capabilities or making the code ultimately harder to deal with for gains at the beginning.

No, you're not.

class BaseScreen(object):
 def on_key_down(self, key, modifiers):
  pass

 def on_key_up(self, key, modifiers):
  pass

 def on_mouse_move(self, x, y):
  pass

 def on_tick(self, dt):
  pass

And then make everyone subclass that.  Or use Pyglet.  There is nothing wrong with two systems in the same game if they play nice.  There's nothing wrong with 5 if they play nice.  if it has code you now don't have to write in it, add it.
You can make subclasses that bind functions to keys based off a dict.  You can make subclasses that maintain a map of what's currently down and what's not.  But that's the basic one you should start with.  The point is that your engine can pass all events to any screen without caring because the one at the bottom of the inheritance hierarchy has methods for them that do nothing.
There is no basic Libaudioverse.  There is no point to split it.  it's already basically as simple as it can get.  Anything simpler needs to be built on top of it, which means I'm giving you the full library.  My plan for this summer is to look into the legal aspects of selling it.  Your only chance of seeing a BSD version is if this falls through or turns out to be too complicated for me to manage without infrastructure I don't have.

Rob, a guy on the pyglet list is doing something with AVbin to make it more friendly.
But I need something I can hand out to everyone on every platform that doesn't need them to do anything but run my game. AVbin currently requires them to install a 3rd party piece of software. Unacceptable in my standard. Because something will happen (like it did with my computer) where even after installing each binary for windows, I still got no sound from pyglet.

So that is your base screen. In the main loop it will pass each event to each method in the class.
So if I have:
class Jump(BaseScreen):
def on_key_down(self, key, modifiers):
  if key == "space":
   spk("Hello world")

stack.append(Jump())

Then in the main loop it runs a function to call the screens in the stack's functions if needed. For example:
for screen in stack:
if KEYDOWN:
  screen.on_key_down(key, mods)
elif KEYUP:
  screen.on_key_up(key, mods)
...

Put that in pygame's event for loop.
Is this correct?

I am going to experiment with both, but I am basically doing that, but in half the lines of code. I guess it may be a little more resource intensive as I am refreshing the dict each iteration of the loop, but not enough to matter...
I agree that the clarity of grouping all key_up code, all the tick code and all the key_down code is very easy to read, but there is no overlap or conflict in doing:
if actions['key'] == "space":
spk("Hello, I'm up")
elif actions['keyUp'] == "space":
spk("I am now up")
x += 1

There is conflict in screens, but when you group into screens like you said to do above, that removes having major screen conflict like:
if actions['key'] == "space" and screen == "start":
spk("Hello world")
elif actions['key'] == "space":
spk("This is space without anything")

But I don't know the advantage of having a class over a dict in this circumstance. You could group your code like:
def stuff(self, actions):
if actions['key']:
  self.key_down(actions['key'])
elif actions['keyUp']:
  self.key_up(actions['keyUp'])
self.tick()

I can easily create a format like this to test this style in pyaudiogame, so I'll do that and see what I think. But dicts are a lot more manageable in this circumstance than classes.

BTW, the developer of pyglet is looking for someone to take over development of pyglet...
And he is really
fed up with AVbin
He posted:
"""
Now that Pyglet seems to have been resurrected, perhaps someone would like to take the reins for Pyglet from me (see above link for more details).
I would be happy to add committers.  I would be even happier to transfer control of the entire project.  I'm really no longer involved except for as a distant observer wishing you guys well and cheering you on.
"""