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 ctpug. Show all posts
Showing posts with label ctpug. 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, 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.
Saturday, June 21, 2008
Python Sprint Day Take 2
In terms of overall productivity, this was less successful than the first. Partly the break for the talks ate up a lot of time, so getting momentum was a lot harder, and also, with the recent beta release, the number of clear issues was much reduced. The checkin that broke floatobject for some of us didn't help either, as people got side tracked into getting working python 2.6 builds.
Still, we prodded a couple of issues from the last bug day, and a couple of new bugs were filed about odd bits in the code (mainly by Simon), so there was some positive progress.
The CTPUG meeting part of the day was a definite success. The localisation talk took some time to get going, and it would have been nice if Dwayne had been able to stay longer so that we could have explored some of the discussion avenues a bit further. Simon's PyObject talk was interesting, especially touching on some of the differences between py3k and the python 2.X series.
Still, we prodded a couple of issues from the last bug day, and a couple of new bugs were filed about odd bits in the code (mainly by Simon), so there was some positive progress.
The CTPUG meeting part of the day was a definite success. The localisation talk took some time to get going, and it would have been nice if Dwayne had been able to stay longer so that we could have explored some of the discussion avenues a bit further. Simon's PyObject talk was interesting, especially touching on some of the differences between py3k and the python 2.X series.
Sunday, May 11, 2008
CTPUG's python sprint day
Overall, I think the day went well. At one point we had 8 people in the room working on various issues, and, during the course of the day, we touched 11 issues by my count (http://groups.google.com/group/ctpug/browse_thread/thread/edff4863226806ea), and submitted patches (in some cases multiple patches) to 10 of them.
Due to the time-zone issues, there wasn't much opportunity to push for review of the patches, but they are now there.
Due to the time-zone issues, there wasn't much opportunity to push for review of the patches, but they are now there.
Sunday, October 7, 2007
CTPUG 6
So, this Saturday was the 6th CTPUG meeting. We had a reasonable turnout, and the talks seemed to go down well. The python on the S60 has me thinking that, when my current cellphone contract is up for renewal, I need to get me something that can run python (not because I really have any great use for python on a phone, being someone who still mainly uses a cellphone for talking to people, but it'll generally be a cool think to have).
The pylons talk was interesting for me from a underlying technology point of view. I'm not nearly involved enough in web stuff to be that concerned about the differences between the frameworks, but the WSGI stuff is something that looks worth getting acquainted with.
After the talk, a bunch of us eventually ended up a Pancho's for supper. Pancho's serve impressively sized potions, which is just as well, as I needed the food to balance out the margarita's I had. Pleasant enough way to spent the time, be carefully picking my way back along the N2.
CTPUG 7 is scheduled for the 17th of November, which will almost certainly be the last one for 2007.
The pylons talk was interesting for me from a underlying technology point of view. I'm not nearly involved enough in web stuff to be that concerned about the differences between the frameworks, but the WSGI stuff is something that looks worth getting acquainted with.
After the talk, a bunch of us eventually ended up a Pancho's for supper. Pancho's serve impressively sized potions, which is just as well, as I needed the food to balance out the margarita's I had. Pleasant enough way to spent the time, be carefully picking my way back along the N2.
CTPUG 7 is scheduled for the 17th of November, which will almost certainly be the last one for 2007.
Saturday, August 4, 2007
CTPUG 5
So, yet another CTPUG down. Attendance was down to the basic core group. I'm not sure why the attendance dropped as it did, as UCT should have been about as accessible as the Bandwidth Barn, but so it goes.
Since Kevin hadn't finished his talk last time, he continued with demonstrating numpy, using a fairly simple compression scheme based on Haar wavelets. While the talk ended up taking rather longer than anticipated, it overall went quite well, I thought, and was generally quite enjoyable. The interactive debugging session mid-way through, while pretty everyone there chipped in (an error caused by missing a copy in places).
After the talk, though, my usual vehicle karma kicked in. The choke cable on my bike broke, wihc, given that a cold wind was blowing, meant I run the battery down trying to get things started. Fortunately, I was able to convince jerith to give me a jump start, and get home OK, but it will make transport an issue until I get the problem resolved. unfortunately, the choke is not easily accessible on the Suzuki, so I can't really work around the problem, although a pair of long-nosed pliers may help (will have to try that during the week).
Since Kevin hadn't finished his talk last time, he continued with demonstrating numpy, using a fairly simple compression scheme based on Haar wavelets. While the talk ended up taking rather longer than anticipated, it overall went quite well, I thought, and was generally quite enjoyable. The interactive debugging session mid-way through, while pretty everyone there chipped in (an error caused by missing a copy in places).
After the talk, though, my usual vehicle karma kicked in. The choke cable on my bike broke, wihc, given that a cold wind was blowing, meant I run the battery down trying to get things started. Fortunately, I was able to convince jerith to give me a jump start, and get home OK, but it will make transport an issue until I get the problem resolved. unfortunately, the choke is not easily accessible on the Suzuki, so I can't really work around the problem, although a pair of long-nosed pliers may help (will have to try that during the week).
Saturday, June 23, 2007
CTPUG 4
So, another CTPUG meeting successfully dealt with.
My pygame talk did not go as smoothly as I had planned, it must be said, and no-one laughed at the "Seriously, who did not see that coming" subtitle, which is a great pity, as I thought that joke was quite good. My demonstration of broken threading refused to break, which was most strange, since it broke quite happily here at home. Given the two in the morning origin of parts of the talk, I think it went as well as can be expected.
Kevin's talk on numpy went over quite well, and sets him up t be roped into to talking at the next one as well. One less talk to find.
After the pygame meeting, most of the attendees migrated to a pleasant little pizza place on Long street, where we had pizza, at quite reasonable cost, it must be said. I wish I could remember the places name, because it is worth remembering.
My pygame talk did not go as smoothly as I had planned, it must be said, and no-one laughed at the "Seriously, who did not see that coming" subtitle, which is a great pity, as I thought that joke was quite good. My demonstration of broken threading refused to break, which was most strange, since it broke quite happily here at home. Given the two in the morning origin of parts of the talk, I think it went as well as can be expected.
Kevin's talk on numpy went over quite well, and sets him up t be roped into to talking at the next one as well. One less talk to find.
After the pygame meeting, most of the attendees migrated to a pleasant little pizza place on Long street, where we had pizza, at quite reasonable cost, it must be said. I wish I could remember the places name, because it is worth remembering.
Sunday, May 13, 2007
CTPUG 3
So, the third CTPUG meeting went off without undue hitches. The bandwidth barn worked quite well as a venue, and we had a larger attendance than the previous meeting, wich is good.
Getting to CTPUG was made complicated for me by the never ending mess that is the N2 at the moment, and the less said about that part of the trip, the better.
After the meeting, a group went out to dinner at a nice enough place called Greens, near Kloof street and from there Simon, Aridanna and I joined Kevin for the usual weekend games evening. This got somewhat delayed by Simon and I playing with trying to get my laptop to talk to his wireless network, which was eventually achieved.
After a game of CTB, and some rounds of Fluxx, we called it a night. The ride back was made more interesting by a very heavy misty patch on the N2, but was otherwise uneventful.
Getting to CTPUG was made complicated for me by the never ending mess that is the N2 at the moment, and the less said about that part of the trip, the better.
After the meeting, a group went out to dinner at a nice enough place called Greens, near Kloof street and from there Simon, Aridanna and I joined Kevin for the usual weekend games evening. This got somewhat delayed by Simon and I playing with trying to get my laptop to talk to his wireless network, which was eventually achieved.
After a game of CTB, and some rounds of Fluxx, we called it a night. The ride back was made more interesting by a very heavy misty patch on the N2, but was otherwise uneventful.
Subscribe to:
Posts (Atom)