Christopher Night | 1 Apr 09:48 2012
Picon

Anyone want to critique my platform game prototype?

I made a pygame prototype for a platforming game I'm planning. As we all know, platform games require meticulously tuned mechanics. I finally got it to where I like it, but that probably means it's still pretty terrible. If anyone wants to try it out and offer suggestions, I'd be very interested.



You control with the arrow keys (up to jump). You have four special abilities:
  • sprint (tap forward and then hold forward)
  • flip (jump immediately after turning, lets you reach higher platforms)
  • wall jump (can't do it off most platforms, only the semi-transparent blocks with vertical walls)
  • hang off ledges (can only do it on red and green platforms with balls on the ends)
You can also go into slow-motion by holding Shift, or toggle slow-mo with Caps Lock. Ctrl is fast-forward, but I don't recommend it. Esc to quit.

If you try it, let me know if you have trouble executing these abilities, or if you accidentally execute them when you don't mean to. The placement of the platforms in the demo is totally procedural, so you may find yourself stuck, but you should be able to get pretty high.

I'd also be interested in any recommendations for well-made platform games written in pygame with really tight controls, if you have any.

Thanks!
-Christopher
Ian Mallett | 1 Apr 18:32 2012
Picon

Re: Anyone want to critique my platform game prototype?

On Sun, Apr 1, 2012 at 1:48 AM, Christopher Night <cosmologicon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

I made a pygame prototype for a platforming game I'm planning. As we all know, platform games require meticulously tuned mechanics. I finally got it to where I like it, but that probably means it's still pretty terrible. If anyone wants to try it out and offer suggestions, I'd be very interested.


You control with the arrow keys (up to jump). You have four special abilities:
  • sprint (tap forward and then hold forward)
  • flip (jump immediately after turning, lets you reach higher platforms)
  • wall jump (can't do it off most platforms, only the semi-transparent blocks with vertical walls)
  • hang off ledges (can only do it on red and green platforms with balls on the ends)
You can also go into slow-motion by holding Shift, or toggle slow-mo with Caps Lock. Ctrl is fast-forward, but I don't recommend it. Esc to quit.

If you try it, let me know if you have trouble executing these abilities,
Flipping is a little too hard. 
or if you accidentally execute them when you don't mean to.
Sprinting.  I ended up running off the edge and falling all the way back to the ground. 
The placement of the platforms in the demo is totally procedural, so you may find yourself stuck, but you should be able to get pretty high.

I'd also be interested in any recommendations for well-made platform games written in pygame with really tight controls, if you have any.

Thanks!
-Christopher

Christopher Night | 1 Apr 18:46 2012
Picon

Re: Anyone want to critique my platform game prototype?

On Sun, Apr 1, 2012 at 12:32 PM, Ian Mallett <geometrian <at> gmail.com> wrote:
On Sun, Apr 1, 2012 at 1:48 AM, Christopher Night <cosmologicon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
I made a pygame prototype for a platforming game I'm planning. As we all know, platform games require meticulously tuned mechanics. I finally got it to where I like it, but that probably means it's still pretty terrible. If anyone wants to try it out and offer suggestions, I'd be very interested.


You control with the arrow keys (up to jump). You have four special abilities:
  • sprint (tap forward and then hold forward)
  • flip (jump immediately after turning, lets you reach higher platforms)
  • wall jump (can't do it off most platforms, only the semi-transparent blocks with vertical walls)
  • hang off ledges (can only do it on red and green platforms with balls on the ends)
You can also go into slow-motion by holding Shift, or toggle slow-mo with Caps Lock. Ctrl is fast-forward, but I don't recommend it. Esc to quit.

If you try it, let me know if you have trouble executing these abilities,
Flipping is a little too hard. 
or if you accidentally execute them when you don't mean to.
Sprinting.  I ended up running off the edge and falling all the way back to the ground. 


Thanks very much for trying it! If you get a chance, I'd be very interested in how it feels to you after tweaking the keypress time intervals. The time to execute the flip is 0.25, on lines 159 and 161. Maybe increase it 0.35. The time to execute the sprite is 0.4, on lines 166 and 169. Maybe reduce it to 0.3.

-Christopher 
Ian Mallett | 2 Apr 01:47 2012
Picon

Re: Anyone want to critique my platform game prototype?

On Sun, Apr 1, 2012 at 10:46 AM, Christopher Night <cosmologicon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

Thanks very much for trying it! If you get a chance, I'd be very interested in how it feels to you after tweaking the keypress time intervals. The time to execute the flip is 0.25, on lines 159 and 161. Maybe increase it 0.35. The time to execute the sprite is 0.4, on lines 166 and 169. Maybe reduce it to 0.3.
Yeah.  That makes it easier.  Got to around 19. 
Christopher Night | 2 Apr 01:59 2012
Picon

Re: Anyone want to critique my platform game prototype?

On Sun, Apr 1, 2012 at 7:47 PM, Ian Mallett <geometrian <at> gmail.com> wrote:
On Sun, Apr 1, 2012 at 10:46 AM, Christopher Night <cosmologicon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Thanks very much for trying it! If you get a chance, I'd be very interested in how it feels to you after tweaking the keypress time intervals. The time to execute the flip is 0.25, on lines 159 and 161. Maybe increase it 0.35. The time to execute the sprite is 0.4, on lines 166 and 169. Maybe reduce it to 0.3.
Yeah.  That makes it easier.  Got to around 19. 

Wow, you must have really got the hang of it, the farthest I ever got was 15. If you still have it, I would be very interested in getting the playback file that should have been made when you played through that long.

Thanks again for trying!

-Christopher
Sam Bull | 2 Apr 20:08 2012

Re: Student summer(or winter) of code projects, $5000 from google.

On Fri, 2012-03-30 at 22:51 +0200, René Dudfield wrote:
> If anyone needs help with a proposal, let us know.

I'd like to do some more work on my GUI toolkit. I know it's not
directly working on Pygame, but I think it will greatly benefit the
community.

I'm going to write a proposal with a brief overview of the project, and
then link to my project specification. If anybody would like to review
the specification, you can find it at
http://sambull.org/downloads/spec.odt

The spec was initially written a couple of years ago, and much of the
stuff on there has already been implemented. I've added an expansion
point to the end to list additional things for GSoC 2012.

As soon as I send this email, I'll be making another beta release of the
project. So, if you would like to see the current state of the project,
then please wait for my next email.
Kaspar Bumke | 2 Apr 20:54 2012
Picon

get real midi device or program name

Hi all,

I was playing around with pygame.midi and I was wondering whether there is a way to get the actual device name rather than just the "input/output" name. What I mean is, I have a program, say gmidimonitor, which has a midi input which it calls "midi in". Now if I do a pygame.midi.get_device_info I can get the name "midi in" but not the name of the program. If I look at the qjackctl midi router for alsa midi devices I can see gmidimonitor listed as "Midi Monitor" and it has one midi port "midi in" so it must be another name parameter when it registers itself besides the actual port names.

Most programs and physical midi devices seem to put their name into the port name but I would like to make extra sure that my program can list the midi devices with a sensible name. Currently if I list the midi ports (what pygame.midi calls devices) the gmidimonitor port is just listed as "midi_in" and this could be confusing for the user (which program's "midi_in" ?).

Regards,

Kaspar


Sam Bull | 2 Apr 21:07 2012

SGC 0.1.3 Released (with documentation)

At long last, I'm announcing the next release of my GUI toolkit.

This release has seen a lot of refactoring and redesigning, making the
project a lot more consistent and easier to use. A few new widgets have
also been added. A couple of the new widgets have been submitted by
Micheal Rochester.

This is also the first release to see some actual documentation. You can
check out the documentation at http://program.sambull.org/sgc/
If you'd prefer an offline devhelp version, there is a separate download
on Launchpad.

If you'd like to try it out, download the release code. As long as you
have Python 2 and Pygame installed, you should be able to run the
example file immediately.

To use it in your own projects, simply copy the 'sgc' sub-folder into
the top-level of your project or add it's parent folder to your
PYTHONPATH so that Python can import it in the normal way.

So, if you're interested, please check it out at:
https://launchpad.net/simplegc

Finally, the limitations of this beta release, that I would advise you
stay away from:
	No Python 3 support yet.
	Using custom images is not documented or properly tested.
	OpenGL support is not working in this release (it's just barely working
on my machine, with some extra code).
	There's an issue with transparency, so (0,0,0) means transparency in
this release, if you find things are invisible try changing the colour
(perhaps (0,0,1)).
	There's no developer documentation to help write your own widgets.
René Dudfield | 2 Apr 22:34 2012
Picon

Re: Student summer(or winter) of code projects, $5000 from google.

Great.  If you want to send through a draft proposal, we can give you feedback.  Or just submit it, then we can give you feedback through the online system.

There has not been any other pygame or pyopengl proposals yet.

One other interesting thing is that Google will write you a letter to your university for course credit.  So if you talk to someone at your uni/college, you might be able to arrange to have the project go towards your course.

Cheers,


On Mon, Apr 2, 2012 at 8:08 PM, Sam Bull <sam.hacking-vRdzynncJC4@public.gmane.org> wrote:
On Fri, 2012-03-30 at 22:51 +0200, René Dudfield wrote:
> If anyone needs help with a proposal, let us know.

I'd like to do some more work on my GUI toolkit. I know it's not
directly working on Pygame, but I think it will greatly benefit the
community.

I'm going to write a proposal with a brief overview of the project, and
then link to my project specification. If anybody would like to review
the specification, you can find it at
http://sambull.org/downloads/spec.odt

The spec was initially written a couple of years ago, and much of the
stuff on there has already been implemented. I've added an expansion
point to the end to list additional things for GSoC 2012.

As soon as I send this email, I'll be making another beta release of the
project. So, if you would like to see the current state of the project,
then please wait for my next email.

Mike C. Fletcher | 3 Apr 15:26 2012

Re: Student summer(or winter) of code projects, $5000 from google.

On 12-04-02 02:08 PM, Sam Bull wrote:
> On Fri, 2012-03-30 at 22:51 +0200, René Dudfield wrote:
>> If anyone needs help with a proposal, let us know.
> I'd like to do some more work on my GUI toolkit. I know it's not
> directly working on Pygame, but I think it will greatly benefit the
> community.
>
> I'm going to write a proposal with a brief overview of the project, and
> then link to my project specification. If anybody would like to review
> the specification, you can find it at
> http://sambull.org/downloads/spec.odt
>
> The spec was initially written a couple of years ago, and much of the
> stuff on there has already been implemented. I've added an expansion
> point to the end to list additional things for GSoC 2012.
>
> As soon as I send this email, I'll be making another beta release of the
> project. So, if you would like to see the current state of the project,
> then please wait for my next email.
We need more concrete details for the proposal.  Looking through the 
code on Launchpad:

  * you don't seem to have a setup.py or similar "traditional"
    installer; that would be a requirement for broad acceptance
      o even those who are going to copy your code into their trees
        likely want to experiment with it first
  * the selection of widgets is fairly sparse
      o I don't know that that is really a *bad* thing, games do tend to
        use a fairly sparse set of widgets
  * there doesn't *seem* to be a theme/skinning mechanism
      o that is, how would I go about making my buttons look like
        flaming ovals instead of rectangles in order to match my
        flaming-eggs game?
      o how would I control menu layouts (position, adding preview
        windows to the right side, etc)
  * menus don't *seem* to have any keyboard control (at least, none I
    was able to trigger in the test app)

Issues to address in the proposal (note: these are at least things you 
need to address, I'm not saying "do or do not", but "provide your 
rationale"):

  * Reaching a 1.0 release is not a sufficiently well specified goal
    (after all, you could increment the version number and upload to
    complete)
      o What will be accomplished (specifics, what $5000 worth of work
        needs to be accomplished, on what approximate time schedule)?
          + What metrics will be used to judge the attainment of the goals?
          + What level of documentation is required?
          + Are you going to produce tutorials or just references?
          + What level of testing is required?
      o Are you going to speculatively convert some open source games to
        use the library to test it's ability to integrate into other
        projects?
  * I would like to see some real adoption/interest numbers.  GSOC
    implies creating something that a significant collection of people
    are going to want to be using the project's results.
      o Is there a strong interest from third-party developers in the
        project  [You say the library is ready to replace the other
        toolkits, but don't mention how many people are planning to
        switch from other libraries to yours as soon as it is stable]
      o Are other people using the widgets already, if not, what is
        stopping them?  Do you have user feedback on this?  If not, it
        might be useful to ask the Pygame community to weigh in on it
        over the next day or two.
  * What is the rationale for a new library over refining an
    existing/in-production library?  That likely needs to be addressed
    explicitly and in detail.
      o Why not enhance PGU or the like with better keyboard support? 
        What are the *specific* failings that make it's approach
        unworkable?  Adding tab support or selection-in-text-boxes to an
        existing library sounds fairly workable, if that is their only
        failing.
      o Why not branch/fork an existing library to bootstrap development?
      o Why not borrow code from appropriately-licensed libraries?
  * If I understand correctly there have been at least half a dozen
    Pygame GUI libraries over the years.  Devil's advocate says the
    problem isn't so much getting a GUI library written as keeping it
    maintained.
      o How does this project avoid "tossing it over the wall" (that is,
        finishing and abandoning the project)?
      o GSOC AFAIK prioritizes getting new developers into *existing*
        projects, building the community of developers.  How does this
        project integrate into the larger community of Pygame developers?

HTH,
Mike

--

-- 
________________________________________________
   Mike C. Fletcher
   Designer, VR Plumber, Coder
   http://www.vrplumber.com
   http://blog.vrplumber.com


Gmane