Two collegue students and I participated in the eighth installement of PyWeek. This is actually a lot more fun, than it sounds, with the challenge being entirely for fun, with only some loose constraints. It's all about coding a game with python in one week.
We somewhat finished in time and delivered a playable tower defense game, named "Spawnmower Lawn Defense". It's implemented using pygame.
Need to lower my Club Mate consumption to healthy levels and get back to work ...
Sunday, May 3, 2009
Monday, March 9, 2009
Rapid Prototyping and Software Engineering?
Today, somehow, I stumbled upon 3d printing, a form of Rapid Prototyping. This reminded me of a talk, delivered by Bre Pettis at 25C3 last year. Again, I began to wonder where this might not only be cool - which it undoubtfully is - but where it also could be useful. (This is not so obvious.) So, as expected, I thought about where to use rapid prototyping at work, i.e. in software engineering. And I think I've identified a spot where it might come in handy. (There are likely to be many more, and I'll post about them, if they come to mind.)
Some time ago, I had an idea to better understand where bad code eats up manpower in terms of support. I figured, given an architecture in adequate detail, it might be useful to print it on a sheet of paper and put that on a pin board. Then, using for example colored pins, we could get an impression of where problems lie. For example, one might want to remember performance bottle necks, occurrences of bugs or black holes in the code, regions that no one understands nor wants to touch.
I've been too busy studying lately to actually put this forward, but still think its a good idea. Easy to use, trivial to evaluate. The only drawback is that it really doesn't look all that nice. (There is worse, but still ...) And here comes 3d printing and saves the day.
Take a look at the following FMC diagram, depicting an architecture of a (still) fictitious browsergame.
Now imagine this as a 3d model, as architects either show them on screen or build them in miniature. The blocks (agents) would rise, the nested ones even further above, the bubbles (storages) would actually be round. Well, the channels might just pose a problem, but anyways! Using materials like polystyrene or plaster, we would be provided with a model of our system that we could make use of as discussed before. With pins, we will be able to mark hot spots and so on. Only this time, it will look cool.
Unfortunately, the 2d solution would work just as fine. So, we're back at square one, having found ourselves a neat solution (to a problem, actually) - but is it actually useful?
If I find out, I'll do another post.
Some time ago, I had an idea to better understand where bad code eats up manpower in terms of support. I figured, given an architecture in adequate detail, it might be useful to print it on a sheet of paper and put that on a pin board. Then, using for example colored pins, we could get an impression of where problems lie. For example, one might want to remember performance bottle necks, occurrences of bugs or black holes in the code, regions that no one understands nor wants to touch.
I've been too busy studying lately to actually put this forward, but still think its a good idea. Easy to use, trivial to evaluate. The only drawback is that it really doesn't look all that nice. (There is worse, but still ...) And here comes 3d printing and saves the day.
Take a look at the following FMC diagram, depicting an architecture of a (still) fictitious browsergame.
Now imagine this as a 3d model, as architects either show them on screen or build them in miniature. The blocks (agents) would rise, the nested ones even further above, the bubbles (storages) would actually be round. Well, the channels might just pose a problem, but anyways! Using materials like polystyrene or plaster, we would be provided with a model of our system that we could make use of as discussed before. With pins, we will be able to mark hot spots and so on. Only this time, it will look cool.
Unfortunately, the 2d solution would work just as fine. So, we're back at square one, having found ourselves a neat solution (to a problem, actually) - but is it actually useful?
If I find out, I'll do another post.
Tuesday, December 2, 2008
Developing Browsergames
For a while now I've been wanting to write a browsergame. Now, a friend and I have decided to actually do some prototyping in this direction. The purpose is to evaluate technologies for their usefulness in this domain, starting with Google App Engine. The corresponding blog keeps track of our efforts, achievements and failures - hopefully a healty portion of all three.
Subscribe to:
Posts (Atom)