So we've reached the end of another pyweek, and I've managed another game ("Bane's Befuddlement"), so it's time for my usual post-pyweek post.
Since most of the usual suspects were busy with other things, I ended up doing a solo entry for the first time. I also decided, on something of a poorly thought-out whim, to use kivy for this entry.
Based on what happened with Mad Science (pyweek 14), I expected the solo entry to be something of struggle, and it does show in the end result. Artwork was obviously limited, since it's not my strong suite and I didn't want to spend a lot of time on the issue, but fortunately I was able to offset that somewhat by using one of the existing dungeon tile collections.
Probably the most crucial failing is ambition. Several of the past pyweek entries I'm been involved in have suffered from being overly ambitious (Nine Tales (pyweek 12) being the worst offender), so I aimed to avoid that pitfall this time. As a result, I was under-ambitious. The game isn't that challenging, and is a bit bland. It's not without potential, but needed more time spent on the initial concept to really get something I would have been happy with.
There are several things I am happy with. I reaffirmed my belief in the
importance of level editors for pyweek games. Even with the very
simplistic one I wrote here, I was able to fill out the level content
very quickly on Friday and Saturday as a result, and I rather like the careful level of stupid that AI achieves.
There are a few tricks about touch interfaces I need to learn. The
most obvious one from this game is to avoid anything that goes too close
to the edge of the screen - it's too easy to accidentally trigger one of
the other buttons in that case.
As an exercise in working more with kivy, this was pretty successful. I'm still uncertain about how I feel about kivy. It's quite nice in some ways - being able to add a settings pane or a popup dialog with only a couple of lines of code - but it's also all sorts of magic in ways that really aren't helpful. The complicated import dance needed to ensure that we set the configured window size before creating the kivy window is just one example of this sort of thing. More annoyingly, the inability to hook in to the command-line argument parsing without some serious monkey patching is the sort of poorly thought out design that makes working with it painful.
Python's still a work in progress on android, and, while it's possible to use pyjnius to access the hardware, and to build apk's, both require more fiddling with building python for android than I was prepared to do during a pyweek, so, while the game runs OK on my phone, it's missing some features which would be very nice to have. There is enough work happening in this space that this should improve, though.
Windows packaging with kivy is a pain, and the recommended approach of using pyinstaller just failed horribly for me. I'm not sure if where to lay the blame for that, but debugging windows issues is not my favourite activity, and anyway not something I'm capable of doing at the end of a pyweek.
Showing posts with label pyweek. Show all posts
Showing posts with label pyweek. Show all posts
Sunday, April 21, 2013
Sunday, May 13, 2012
Pyweek 14: Mad Science
So we've reached the end of another pyweek, and managed yet another game ("Tomorrow, the World!!!"), so it's time for my usual post-pyweek post.
It's not one of the better entires I've been involved in, and I expect us to place very middle of the field this year. I think there's a decent concept here, but we didn't get enough content or game balance to have something that's really fun, and, as a result, much of the early game is a bit random and frustrating. There's nothing unfixable, but it needs a couple of days of people playing and extending the game to get to the point I'd actually be happy with it. It's got its entertaining bits, though, so I'm happy enough to throw it out there to be judged and see what happens.
Due to everyone being busy and / or being out of the country, we had a much smaller team than previous entries. I expected we would need to downscale as a result, but this proved to be more of a problem than I had actually anticipated. There just wasn't space for people to play the game much, which partly accounts for the issues, and there also much less opportunity to riff off other people's ideas to improve things. Everyone being busy in the day didn't help either. There were far fewer of the "ooh, a bunch of cool stuff has happened since I last worked on the game" moments, which also made it feel like more of a slog than past entries. The lack of people was most felt in the final Saturday finishing sprint, for which only 2 of us were available - most conversations were "I'm fixing X, can you look at Y?", and then silence for about 30 minutes while stuff happened. Given how the smaller team affected things, my respect for people doing successful solo entries has gone up even further.
I've now been involved 5 pyweek entries, and they've all been content heavy in various ways, so it's fair to call that as a definite trend. Given the games I enjoy playing, and the high value I place on being amusing, that's not surprising, but it's not a good feature for games with small teams.
On the upside, it was still fun. Coding for pyweek is always liberating, since it's much more important to have something close now than completely correct later. Having now done 3 pyweeks with mercurial, we've now also got the setup and workflow around that reasonably well sorted (which means we're almost certainly due to change to something else now), and past experience means that we're making a reasonable number correct design decisions early, so I'm quite happy with the final structure of the game.
It's not one of the better entires I've been involved in, and I expect us to place very middle of the field this year. I think there's a decent concept here, but we didn't get enough content or game balance to have something that's really fun, and, as a result, much of the early game is a bit random and frustrating. There's nothing unfixable, but it needs a couple of days of people playing and extending the game to get to the point I'd actually be happy with it. It's got its entertaining bits, though, so I'm happy enough to throw it out there to be judged and see what happens.
Due to everyone being busy and / or being out of the country, we had a much smaller team than previous entries. I expected we would need to downscale as a result, but this proved to be more of a problem than I had actually anticipated. There just wasn't space for people to play the game much, which partly accounts for the issues, and there also much less opportunity to riff off other people's ideas to improve things. Everyone being busy in the day didn't help either. There were far fewer of the "ooh, a bunch of cool stuff has happened since I last worked on the game" moments, which also made it feel like more of a slog than past entries. The lack of people was most felt in the final Saturday finishing sprint, for which only 2 of us were available - most conversations were "I'm fixing X, can you look at Y?", and then silence for about 30 minutes while stuff happened. Given how the smaller team affected things, my respect for people doing successful solo entries has gone up even further.
I've now been involved 5 pyweek entries, and they've all been content heavy in various ways, so it's fair to call that as a definite trend. Given the games I enjoy playing, and the high value I place on being amusing, that's not surprising, but it's not a good feature for games with small teams.
On the upside, it was still fun. Coding for pyweek is always liberating, since it's much more important to have something close now than completely correct later. Having now done 3 pyweeks with mercurial, we've now also got the setup and workflow around that reasonably well sorted (which means we're almost certainly due to change to something else now), and past experience means that we're making a reasonable number correct design decisions early, so I'm quite happy with the final structure of the game.
Sunday, September 18, 2011
Pyweek 13: Mutable Mamba
First, play our latest pyweek entry: http://www.pyweek.org/e/mamba/
The game went a lot smoother than pyweek 12's Nine Tales. I think we hit on a much better scale for this effort, given the time available, and, as a puzzle game, we were able to get the basic mechanics reasonably set early enough that we were never under pressure to have a game to submit, and so could do a fair amount of polishing. This also meant we actually spent a lot of time actually playing the game, so we could work off a few rough edges, which was good for the game.
We also spread things out a bit better than in pyweek 12. We avoided the major stumbling block of lots of central state people had to touch which we had in Nine Tales (the infamous game.json), which meant we had fewer merge issues than previously, and, by not using yet another version control system, benefited from the lessons learnt about mercurial last pyweek.
Unlike pyweek 11, where I ended up accidentally writing a level building tool, I more deliberately decided to write a level editor this time. While it's not perfect, and only learnt a few important tricks on the Saturday, the effort was, I think, well spent, as it allowed us to rope in spare people for extra level design effort, and made the addition of uploadable network levels a lot more feasible.
There are several issues. Most notable, our within a week widget stack, although inspired and influenced by past experience, is kludgy and lacks proper support for several important features. We should probably have a good look at the our last couple of pyweek entries and cut out a basic widget library from them, which can save us time in the future.
While not the best of our pyweek entries, I think we ended up with a fairly solid game, and it can fairly easily be extended by adding new levels, and, if we polish up the multiple tileset support, it would be quite easy to reskin levels.
The game went a lot smoother than pyweek 12's Nine Tales. I think we hit on a much better scale for this effort, given the time available, and, as a puzzle game, we were able to get the basic mechanics reasonably set early enough that we were never under pressure to have a game to submit, and so could do a fair amount of polishing. This also meant we actually spent a lot of time actually playing the game, so we could work off a few rough edges, which was good for the game.
We also spread things out a bit better than in pyweek 12. We avoided the major stumbling block of lots of central state people had to touch which we had in Nine Tales (the infamous game.json), which meant we had fewer merge issues than previously, and, by not using yet another version control system, benefited from the lessons learnt about mercurial last pyweek.
Unlike pyweek 11, where I ended up accidentally writing a level building tool, I more deliberately decided to write a level editor this time. While it's not perfect, and only learnt a few important tricks on the Saturday, the effort was, I think, well spent, as it allowed us to rope in spare people for extra level design effort, and made the addition of uploadable network levels a lot more feasible.
There are several issues. Most notable, our within a week widget stack, although inspired and influenced by past experience, is kludgy and lacks proper support for several important features. We should probably have a good look at the our last couple of pyweek entries and cut out a basic widget library from them, which can save us time in the future.
While not the best of our pyweek entries, I think we ended up with a fairly solid game, and it can fairly easily be extended by adding new levels, and, if we polish up the multiple tileset support, it would be quite easy to reskin levels.
Sunday, April 10, 2011
Pyweek 12: Nine Times
So a bunch of us took part in pyweek 12. While we had a lot of fun, and the ended up with something that looked very good, we didn't quite manage to get the game completely playable inside the 1 week time limit.
Failures are generally more educational than successes, so some thoughts on what went wrong.
a) We were arguably over ambitious, although I'm not sure where we needed to scale down. This is probably the most important factor as it meant we took too long to get enough of the game playable that we could start getting stuff hooked up, and it also meant that we didn't have as much overlap on knowledge of the code base as we had on Suspended Sentence, which slowed us down at critical points, and made fixing various bugs quite hard.
b) We took too long to converge on what game we were writing. Various bits grew in different directions and got fixed in the wrong place, and there were a couple of dead ends we pursued. We also didn't have the time to refactor code to fix things as we've had previously, so the game is more than just somewhat buggy.
c) We didn't know mercurial nearly as well as we thought we did. Most of us had used it for the Genshi sprint, which was quite intense, as well as using it on other projects, so we thought we going for a safe option At the pace of pyweek development, however, we tripped over mercurial not behaving as we expected quite often, and the slow downs fixing the issues this caused all added up to quite a lot of lost time.
Still, the game has a number of promising bits, and, with some concerted work on the engine, and some work on the other bugs and the game balance, it can turn into something really quite cool. This should be a good candidate for pyggy, if we can summon the energy to tackle again.
Failures are generally more educational than successes, so some thoughts on what went wrong.
a) We were arguably over ambitious, although I'm not sure where we needed to scale down. This is probably the most important factor as it meant we took too long to get enough of the game playable that we could start getting stuff hooked up, and it also meant that we didn't have as much overlap on knowledge of the code base as we had on Suspended Sentence, which slowed us down at critical points, and made fixing various bugs quite hard.
b) We took too long to converge on what game we were writing. Various bits grew in different directions and got fixed in the wrong place, and there were a couple of dead ends we pursued. We also didn't have the time to refactor code to fix things as we've had previously, so the game is more than just somewhat buggy.
c) We didn't know mercurial nearly as well as we thought we did. Most of us had used it for the Genshi sprint, which was quite intense, as well as using it on other projects, so we thought we going for a safe option At the pace of pyweek development, however, we tripped over mercurial not behaving as we expected quite often, and the slow downs fixing the issues this caused all added up to quite a lot of lost time.
Still, the game has a number of promising bits, and, with some concerted work on the engine, and some work on the other bugs and the game balance, it can turn into something really quite cool. This should be a good candidate for pyggy, if we can summon the energy to tackle again.
Sunday, August 29, 2010
Pyweek 11: Caught
After the success of last year's entry, we decided to do another one this year (we skipped pyweek 10, as none of us had time available then), with a slightly tweaked team.
This years entry ran rather differently. We met on Sunday to discuss things, and,. although we settled on a point and click adventure game fairly early, we spent a lot of time converging to a basic premise and initial plot, although we did manage to get this largely settled by Sunday evening.
Another serious issue was the colds several members of the team (including me) were battling with. This added a layer of fuzzy thinking in several places, and was just generally not helpful.
The development ran rather differently to the last pyweek. I think because of the previous experience, the pace of development, while equally fast, wasn't nearly as startling. We also used a different toolkit, albow, which, while not perfect, was easier to get on top of than pgu had been. The game, being point and click, is also less busy than fox assault was, so from that point of view the code base was easier to manage. As a result, the basic engine part of the game actually shaped up fairly quickly, and we were generally able to extend it as needed with little trouble.
On the other hand, as an adventure game, we needed to generate a lot of content before we could hook up parts of the game. This was the largest stumbling block for the game. By Thursday, it looked like we would have something workable, but we only got rid of the last of the text placeholders quite late on Saturday. This meant we didn't have a reasonably playable version of the game until quite late, and thus never got much feedback as a result of other people playing the game. This helped contribute to the annoying bugs in the final submission, as, by that stage, we weren't testing unexpected interactions enough.
Notes on things that happened along the way:
While not as fun for me as the first pyweek, largely due to the cold, this was still enjoyable, and the game, while quite a simple little adventure game, is amusing, and has promise as a more general adventure game engine.
This years entry ran rather differently. We met on Sunday to discuss things, and,. although we settled on a point and click adventure game fairly early, we spent a lot of time converging to a basic premise and initial plot, although we did manage to get this largely settled by Sunday evening.
Another serious issue was the colds several members of the team (including me) were battling with. This added a layer of fuzzy thinking in several places, and was just generally not helpful.
The development ran rather differently to the last pyweek. I think because of the previous experience, the pace of development, while equally fast, wasn't nearly as startling. We also used a different toolkit, albow, which, while not perfect, was easier to get on top of than pgu had been. The game, being point and click, is also less busy than fox assault was, so from that point of view the code base was easier to manage. As a result, the basic engine part of the game actually shaped up fairly quickly, and we were generally able to extend it as needed with little trouble.
On the other hand, as an adventure game, we needed to generate a lot of content before we could hook up parts of the game. This was the largest stumbling block for the game. By Thursday, it looked like we would have something workable, but we only got rid of the last of the text placeholders quite late on Saturday. This meant we didn't have a reasonably playable version of the game until quite late, and thus never got much feedback as a result of other people playing the game. This helped contribute to the annoying bugs in the final submission, as, by that stage, we weren't testing unexpected interactions enough.
Notes on things that happened along the way:
- My quick 20 minute hack to help layout rectangles grew rather more features than I expected.
- Finding sounds with decent licenses is a painful and tedious exercise.
- The same is true for fonts
- But writing a little sine wave tone generator using just sys, math and struct was amusing
- Hooking up humorous descriptions and interactions is why to kill compiling time
While not as fun for me as the first pyweek, largely due to the cold, this was still enjoyable, and the game, while quite a simple little adventure game, is amusing, and has promise as a more general adventure game engine.
Sunday, September 6, 2009
Pyweek 9: Feather
Pyweek has, since I first heard about it, been one of things I've always wanted to have a stab at, but never got around to. For pweek 9, with the benefit of enthusiasm from fellow members of CTPUG, we managed to get an entry together. We ended up with a rather fun little strategy game (in my completely neutral and unbiased opinion, of course), called "Fox Assault".
The whole development experience was quite interesting - I'm still somewhat amazed on how quickly we seemed to hit a concept in the initial discussion and were able to just run with it. Based on this experience, and the momentum the initial concept discussions gave us, for any future team entries, having an initial in person discussion & planning session is will be most useful.
The pace of development was more than a bit breathless, and, on a couple of occasions, I watched a throw-away comment in the code suddenly arrive in the codebase turned into something awesome, which was quite gratifying.
The way the game took over my week was a little unexpected, and contributed to rather less sleep than was probably healthy (the VTES social and a C. J. Cherryh novel didn't help this either). Some of other events of the week really quite surprised me, such as #ctpug suddenly becoming our personal source of additional testers.
Our one major error was not looking taking more time to familiarise ourselves with pygame and the available support libraries more beforehand. We chose to use Phil's pyGame Utilities almost on a whim, and, while it helped a great deal in providing several useful framework tools, and did save us quite a lot of time initially, it also forced several compromises and hacks onto us, partly due to design decisions taken by pgu, and partly due the time pressure favouring "It works, that's good enough" over pretty much anything else.
Overall, the whole experience was simply gosh-darn FUN, and while I would like to see our game score well, I'm overall really not bothered about that, since I know it's quite cool. I'd certainly like to do this again, although I'll probably try and plan to have a day's leave towards the end of the week for the next one.
The whole development experience was quite interesting - I'm still somewhat amazed on how quickly we seemed to hit a concept in the initial discussion and were able to just run with it. Based on this experience, and the momentum the initial concept discussions gave us, for any future team entries, having an initial in person discussion & planning session is will be most useful.
The pace of development was more than a bit breathless, and, on a couple of occasions, I watched a throw-away comment in the code suddenly arrive in the codebase turned into something awesome, which was quite gratifying.
The way the game took over my week was a little unexpected, and contributed to rather less sleep than was probably healthy (the VTES social and a C. J. Cherryh novel didn't help this either). Some of other events of the week really quite surprised me, such as #ctpug suddenly becoming our personal source of additional testers.
Our one major error was not looking taking more time to familiarise ourselves with pygame and the available support libraries more beforehand. We chose to use Phil's pyGame Utilities almost on a whim, and, while it helped a great deal in providing several useful framework tools, and did save us quite a lot of time initially, it also forced several compromises and hacks onto us, partly due to design decisions taken by pgu, and partly due the time pressure favouring "It works, that's good enough" over pretty much anything else.
Overall, the whole experience was simply gosh-darn FUN, and while I would like to see our game score well, I'm overall really not bothered about that, since I know it's quite cool. I'd certainly like to do this again, although I'll probably try and plan to have a day's leave towards the end of the week for the next one.
Subscribe to:
Posts (Atom)