So, is it Pygame too much hassle for a single developer? Or perhaps it doesn't have enough features for anything beyond a bare-bones game?
Technically, it's none of that. It's just that why should one pass time to redo everything that is already done by Ren'py ?
Ren'py is a multi-OS interface between PyGame and the world, in perpetual development since now 15 years. Using it make you have both the potential power of PyGame, while not having to pass month to write the base of the interface. And it come with a bonus, the base features come with years of testing and improvements.
By using Ren'py, you know that your game will save and load correctly, whatever the supported OS is used by the player. By using your own save/load system on top of PyGame, you'll cross your finger that it will works, that you'll not encounter a rare case that will break it or, worse, silently corrupt it.
It possible to do this, but for the first year, you'll pass 90% of your time working on the interface, not on the game itself.
I might give it a try, since I want to brush up my Python skills and I dislike visual novels, but perhaps it's not worth it?
You can totally give it a try... by using Ren'Py.
It's a myth to believe that it's limited to visual novels, especially if you're ready to deal directly with PyGame. Ren'py come with features letting you create your own statements, so you can benefit from its lexer will still using your own addition.
Lets say that you want to make vertical scroller, you can add statements like :
defSprite that will define... the sprites used,
posSprite that will place if on the screen,
spritePattern that will define the patern you can assign to a sprite,
startLevel that will start the level, taking care of collision, movement and all.
Then have your code like :
Code:
defSprite minion1:
img "this file"
resistance 1
power 1
defSprite minion2:
img "that file"
resistance 3
power 2
defSprite boss:
img "another file"
resistance 50
power 10
[...]
spritePattern spiral:
angle 90 for 5
angle -180 for 3
angle 0 for 5
[...]
label level1:
posStrp:
minion1
x 1
y 1
start 1
pattern spiral
posStrp:
minion1
x 2
y 1
start 1
pattern spiral
posStrp:
minion1
start 1
pattern spiral
posStrp:
minion1
start 1
pattern spiral
[...]
startLevel
You can use, or not, part of Ren'py's internal behind each statement, address directly PyGame when needed, while still have the benefit of all the strongest points of Ren'py.
startLevel can be, by example, a variation of the
call screen statement, including a collision test before each refresh of the screen, and having a better handling of the keyboard interception.
It's probably even possible to directly use the screens. You just need to add two screens statements, one that will deal with the collision, and one that will move the sprites. Which would lead to something like :
Code:
screen allLevel:
default x = 10
default y = 150
default bgOffset = 0
timer 0.5 repeat True action If( bgOffset >= bgSize, SetScreenVariable( "bgOffset", bgOffset - 1 ), Return() )
key "UP" action If( y > 10, SetScreenVariable( "y", y + 1 ), NullAction() )
key "DOWN" action If( y < height, SetScreenVariable( "y", y - 1 ), NullAction() )
key "LEFT" action If( x > 10, SetScreenVariable( "x", x - 1 ), NullAction() )
key "RIGHT" action If( x < width, SetScreenVariable( "x", x - 1 ), NullAction() )
add background offset bgOffset
add collisionLoop
add movingLoop
for s in sprites:
add s.img pos s.pos
add MCsprite xpos x ypos y
To be really efficient, it's probably better to rewrite
If or have a dedicated statement replacing
key, but that's all. You can definitively use the base that Ren'py already provide as interface between PyGame and the system, and add you own features on top of it.
