[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] learning pygame: what to focus for a board game?


On Jun 15, 2007, at 3:45 PM, massimo s. wrote:


Casey Duncan ha scritto:

On Jun 15, 2007, at 3:22 AM, massimo s. wrote:


The nice thing is that doing things this way will probably get
you Model-View-Controller for free.  If you don't know what
that is, read http://sjbrown.ezide.com/games/writing-games.html
and then google around for some more until you understand why
this is a good idea.
Ah, design patterns! Being not a professional programmer (I'm actually a biophysics ph.d. student) they always escaped me -I tried to have a look at them but I didn't understand a lot of them. Not that I looked very 
thoroughly. I'll surely dig it. Thanks a lot.
One caution I would make: Don't let a pursuit of design pattern ideals get in the way of your real goals of creating a fun game (and having fun 
creating it). I find that I lose interest in hobby projects real fast
when I'm not having fun creating it anymore. To me having something that works is more fun then not, even if the thing that works is not a marvel 
of software engineering "best practices".


Well, I like to code, but I'd like even more to code *well*. I hate to
start programming, seeming to have clear ideas, then realizing that the 
code is actually a mess. To me coding is an act of elegance. Too bad I
don't have the skills to follow completely this pursuit - nor the time
to get these skills. So my code is always messy -or at least, messier
than I'd like it to be. However, I like to try to get better and have
fun in the process. I can't learn without having fun and without doing
something that works, and the carcassonne project looks like a fun
project to learn.
Don't get me wrong, I strive for elegance as much as anything. To me elegance is often simplicity both in concept and execution. Design patterns are helpful but if used for their own sake they can be anything but simple. IOW don't search for ways to apply design patterns, identify the problems first and then solve them, using whatever solution works. Often I identify the problems by writing some code. Other times you can learn from other's experience (such as MVC, etc), but remember that MVC might not be necessary or even helpful until your program reaches a certain level of complexity itself, one it may never actually reach anyway.
As for messy code, it is my experience that the real world is messy. In fact Python embraces messiness to a large degree, it's own design and implementation is rooted in the pragmatic. If it is your desire to reach some sort of programming nirvana, I might suggest using a Lisp variant instead of Python ;^)
Now that said, there is nothing more satisfying for me than to solve what appears to be a messy problem with elegant code. But again, for me, that means simple, obvious code.
Also, I usually write code under the assumption that it will need to be 
refactored, if not rewritten at some point. Once a project gets going
most of the code I write is refactoring and extending existing code as 
opposed to writing new code from scratch. This allows you to make
progress in small steps all the while having a working system.


Well, refactoring doesn't allow that... Refactoring means you have to
reorganize your actual code, that is, rewriting things that you know
that function to accomodate new functions in a non-completely hellish
way. This often increases program quality but introduces regressions,
and it's not so funny.
Combining iterative development with refactoring allows exactly that in my experience. Fighting regressions is all about testing. I have a hard time being religious about automated testing in my game programming, however. Which just means I play my own game...a lot. 


Of course, sooner or later, *everyone* must refactor. But I'd like to
strive to have a good architecture from the beginning...at least, as
good as my poor skills allow me to.


I say as long as you are having fun, you are doing it right 8^)

-Casey