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

["massimo s." <devicerandom@xxxxxxxxx>]

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.

> 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.

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.

m.