Tools used for pyweek

Tee on 2007/08/25 01:52 of King Tree

Inspired by simonar's post "music tools for the inept?", I'd like to make a small poll. What tools do you use for pyweek? In my case, I use mostly emacs and gimp.

I'd also like to ask, how do you make your graphics? Do you draw on paper first, then scan it? Do you draw it directly on a program? Do you use other images as base? Do you have any interesting tricks? Etc.

(log in to comment)

Comments

RB[0] on 2007/08/25 02:34:

I use IDLE(I know...), Gimp, pyglibs, musagi, wings3d, Audacity, Mozilla(very often ;)), and other various things depending on the project.

For myself, when I do art I either draw it in Gimp or wings.

skaro on 2007/08/25 02:52:

I like coding in SPE, and occasionally Eclipse+Pydev if the mood hits me. For graphics Donal and I have been using the free version of Graphics Gale (a very nifty sprite editor (and also a decent level editor for bitmapped maps) ) and paint.net for the higher color graphics.

Hectigo on 2007/08/25 13:03:

ConTEXT and a regular Logitech keyboard for editing code, PhotoShop Elements 3.0 and Wacom Graphire2 A6 for graphics, Audacity and a cheap desktop microphone for sounds. I have a scanner too, but I don't think I've used it once for game graphics, since I'm used to working directly on the computer. As for interesting tricks, I don't think I have any - it pretty much comes down to basic skills and knowledge of what I'm doing, not some secret trick.

viblo on 2007/08/25 19:51:

Last time we used Eclipse+pydev and Scite for code, incscape and paint.net for graphics, audacity for sounds (if we had any, don't remember). Darcs for version control.

Cthulhu32 on 2007/08/25 19:56:

Python IDLE, GIMP, musagi, Mozilla, Chatzilla/MIRC (depending if I'm at work or not), AIM (for chatting w/ team mates), various O'Rielly books on game developement for AI & Physics, Google for physics reminders.

I think the best tools I have honestly are my retro games. Usually after I hear the theme that's announced, I'll just start playing various titles to try to get inspiration. I always like to play the old school 8-bit NES titles that are just as fun to pick up as modern games. I always fire up my MAME machine and try out some arcade titles.

Marlow on 2007/08/25 20:08:

I use simple, low-tech tools where possible because I know that they'll be available:
  • My car, as the commute is often the only guaranteed quiet time that I get.
  • Large amounts of scrap paper and two or three pens of different colours.
  • IDLE, because its simple.

Tee on 2007/08/25 21:32:

Scrap paper, Firefox and Google, I use them a lot too. (Thanks for the replies.)

Tigga on 2007/08/25 23:21:

GIMP, and a text editor. I generally have IDLE open, but only so I can do sums/test code snippets.

eugman on 2007/08/25 23:27:

I've switched to DrPython instead of idle since idle doesn't work well with multi file games.

pekuja on 2007/08/26 00:54:

Vim mostly. Subversion for version control. I haven't done much of the final graphics in my games, but for placeholders and stuff I've used Gimp and Paint.Net. I've also drawn some doodles on scrap paper, but I haven't really transfered that to the PC, it's just another way to explore different options. For audio stuff I've used Audacity and a cheap PC microphone. For producing the sounds, mostly vox humana. :-)
A web browser (Firefox) and an IRC client (irssi) also get used of course.
I might use some different tools this time around. Different version control (Bazaar), different graphics program (GraphicsGale). Or maybe I'll try to do some 3D... we'll see. ;-)

philhassey on 2007/08/26 03:54:

- kate for text editing - subversion for source control - gimp for graphic stuff (depending on the game, i like to draw on paper, scan it in, then color it using the gimp) - audacity and n-track for sound editing (after being recorded with a mic) - modplug for music composition

richard on 2007/08/26 04:17:

  • Vim for source editing.
  • Version control: RCS for solo, SVN for team.
  • Inkscape and a smattering of Gimp for 2d graphics, Wings3d for 3d.
  • Audacity for sound sampling and editing.
  • I've never composed music, so I have no favourite tool for that ;)

alecu on 2007/08/26 05:30:

The tools every member of our team uses:
  • svn (though googlecode had troubles with large files and opensvn was often slow, so we used a custom repository)
  • trac (opensvn or custom; the wiki is always useful)
  • our googlegroup
  • pizza and empanadas
  • cocacola
  • leito's place
The tools I mostly use:
  • ubuntu
  • vim
  • gimp
  • firefox
  • gmail
This time we have a few members away from Buenos Aires, so we really should try some remote collaboration tools. Maybe skype or teamspeak, or something like that.

zombie1 on 2007/08/26 18:33:

I've been using:

  • Idle for coding.
  • Blender for 3d modeling.
  • Gimpshop for textures and 2d.
  • Firefox and Thunderbird for communicating with others
  • Anvil Studio and Cakewalk Pro audio for music and soundFX
  • and finally,Red Bull and Dr. Pepper to stay awake!!

john on 2007/08/26 20:23:

Gimp
DrPython

Thats all really. Although I may use Gogh bitmap editor and a graphics tablet.
Rhodri uses:
Rosegarden
Gimp

Dafydd uses:
Inkskape

Deathworks on 2007/08/28 14:46:

Hi!

Well, graphics will definitely done using GIMP (seriously, what else?), for coding, there is that editor that comes with Python, IDLE, right? I guess the readme.txt can be written using the MS note pad editor. Sound has a low priority for me, so no plans there yet.

Eugmann: Could you please say what you mean by saying IDLE doesn't work well for multi-file games? Having several edit windows/files open simultaneously has been no problem for me thus far (running Python 2.5.1 on Windows XP SP2). I am just a newbie to Python, so I am curious about any information of that sort.(Shudders when remembering that assembler that made mistakes during computation of relative addresses making assembly programming impossible)

Deathworks

RB[0] on 2007/08/28 15:45:

Well, if you have multiple windows open, and you change anything in one of them, it doesn't change that in the rest of the files, what happens is all the files are imported the first time you run, if you change any of the modules, you will either have to have a call to reload(module) or you will have to restart any windows you wish to run with the new modules.

Personally this has been annoying in some cases, but never that big of a problem really :)

john on 2007/08/28 16:19:

IDLE scary...

ceronman on 2007/08/28 16:27:

I use JEdit for text editing. Gimp for image editing. Blender for 3D modelling. Firefox. Gaim for IRC. Ubuntu. Google. I have no experience with sound but probably I will use Audacity or Jokosher if I have time.

Deathworks on 2007/08/28 16:37:

Hi!

Ah! I see. It is a problem with module administration.

That would explain why I never came across it thus far. Except for the library imports (sys, os,...), I am always using execfile() because I want to be able to use simple global variables. (I always start with using execfile on a file only containing variable declarations for 'constants', then I have a file creating 'global variables', some of which are derived from the constants initially. Import doesn't seem to support that, so I changed to execfile - or maybe that was that bug? Ah, but anyhow, execfile seems just what I was looking for.)

Thanks for the information.

Deathworks

Tee on 2007/08/28 21:34:

Just a tally, for curiosity's sake. If someone mentioned more than one, I counted them all, so it might not be very accurate. (Ordered by usage, then in no particular order. And I'm too lazy to format it better. :))

Coding:
6 IDLE
3 Vim
2 DrPython
2 Eclipse
1 Emacs
1 SPE
1 ConTEXT
1 Scite
1 Kate
1 JEdit
 Graphics:
12 Gimp
3 Inkscape
3 Paint.net
1 Graphics Gale
1 Photoshop
 3D Graphics:
2 Wings
2 Blender
 Music/sounds:
6 Audacity
2 Musagi
1 N-Track
1 Modplug
1 Rosegarden
1 Anvil Studio
1 Cakewalk Pro

richard on 2007/08/29 00:05:

Deathworks: you can use the construct "from constants import *" to import the variables from a module into your namespace.

Deathworks on 2007/08/29 07:37:

Hi!

Actually, from ... import * was the one I tried to use (^_^;; . Sure, it works for the main program, but once I get to the globals module and need to the variables defined in the constants module, I am left high dry. The way I understand it, imported modules, during their initialization run, have their own namespace - so they can't access the global variables of the calling file directly because the imported modules don't share the importing module's namespace during that first run. For libraries that are closed in themselves, that may be fine, but in my case, I basically use the file splitting in order to cut the main file into small, manageable pieces.

Besides, as far as I can tell, there is no real advantage in using import rather than execfile (unless you re-use names in different modules).

But thanks for the suggestion anyway.

Deathworks

richard on 2007/08/30 02:43:

Modules shouldn't need to access the namespace of programs or modules they're being imported from.

I'll take a guess and say that your main file which is doing the importing perhaps has some configuration variables in it that the imported modules need to see? In that case, move those variables off to a separate module (called "config"?) which is then imported by the modules that need to access those variables.

To say that a different way: if there's code or data that needs to be accessed from multiple programs or modules then it needs to be in a module of its own.

Deathworks on 2007/08/30 09:00:

Hi!

Actually, the main file should usually be just a long list of import and execfile commands, ending with the two lines of code required by wxPython: Creation of an application instance and then calling that application instant's main loop.

However, the basic initialization is not done in a function/procedure but rather in immediately executed code in the files constants.py, globals.py, and core.py (the last is specific to the big engine I want to work on and effectively loads constants from a .cfg file). This is because the code is executed only once at program start. All constants and globals need to be at the top level of the main namespace as they will be used by many of the routines (for calculating tile sizes, placing graphics, handling game states, using file tables).

Constants.py has the variables default to certain dummy values and some of the variables defined there are automatically over-written by core.py, provided they are defined in the .cfg file. So, core.py needs to write to the top level variables of the main module that are already in place. In addition, some of the globals defined in globals.py may be best of defaulting to the constants as well.

Basically, I got this habit from C++ and similar languages where you have variable declarations. Constants.py and global.py effectively contain just a list of global variable declarations so all other routines can refer to things like screen size, tile size ... . Because of the lack of variable declarations in Python, thus requiring to explicitly mark globals when accessing them in a function, it seemed reasonable to have the initialization routine of core.py also run on the top level instead of using a function, half of it consisting of '__main__.'. (Personally, I think that requiring variable declarations would actually quite useful since it prevents undetectable left-hand-side typos.)

Anyhow, at the moment, I really don't see any advantage for using import rather than execfile since I prefer using long and explicit variable names, making name interfering rather unlikely (except for our all-time favorite 'i', but that's a disposable anyway :) :) :) :) ).

Deathworks

richard on 2007/08/30 10:52:

I refer you to the final line of The Zen of Python:

"Namespaces are one honking great idea -- let's do more of those!"

:)

nihilocrat on 2007/08/30 17:37:

"(Personally, I think that requiring variable declarations would actually quite useful since it prevents undetectable left-hand-side typos.)"

Wow, so someone else shares my opinion. Ultimately, I wish Python were statically typed(!) so that 90% of the bugs I experience will occur at compile-time, since functions will actually care about what is being fed in their args and I'll be relieved of all sorts of headaches when using Python to code a large, complicated system.

I think I will dig around in the python dev mailing list, since I bet some perl programmer said "why doesn't python have something like 'use strict'?" already.

RB[0] on 2007/08/30 18:11:

You can set up your functions to only allow certain kinds of args, just use if->else, or I think assert does the same approximate thing, on all the args, so:
    def dothis(arg1_tuple, arg2_string):
      assert type(arg1_tuple) is type(tuple())
      assert type(arg2_string) is type(str())
I have found dynamic typing both useful and bothersome, depending on the situation, but most generally I prefer dynamic typing.

I'm not sure what you mean by compile-time though. Do you mean when you execute the program and it gets turned into byte-code that is sent to the C interpreter? O or something else?

I've never had problems debugging code, because, for all its faults, that is one thing that is really straight-forward in IDLE.
Just run the program, and if there is an error, it will display it and where/when it happened.

Something where use strict were available could be nice, but for the most part it would go unused in Python(probably why it was never added ;) )

richard on 2007/08/31 00:27:

Python will never have static typing. Python 3 will have optional interface declarations, but they're not enforced by the interpreter, they're only for 3rd-party tools and documentation.

This little article might help explain why.

alex on 2007/08/31 01:48:

richard: perhaps a "tools" poll is in order, using Tee's data as seed questions? Maybe after (or during) the comp, so it's not optimistic..

richard on 2007/08/31 02:16:

Yeah, that sounds like a good idea. I might even fire it up during the challenge, since it won't be too distracting.

That reminds me, the system poll should've been closed by now. Just did so.

Deathworks on 2007/08/31 09:17:

Hi!

Actually, I wasn't so much about the static types, but about the variable names. I don't mind dynamic(?) types at all, a lot of the script engines I have encountered use it, and while you can indeed mess things up, you usually have not that much trouble debugging (after all, most type errors either end in error messages or very obvious value defaulting).

However, variable declarations on the run are extremely dangerous:

Horse = Legs * 4 + Hunk
.
.
.
If (blablabla) : House = Horse - Leg
.

This is a simplified example, but that is basically what I am worried about: You won't get any error message, but because of the typo ('House' instead of 'Horse'), the program will have an incorrect Value for Horse, and if this happens to a variable you are using in several complex computations, you can be in for hours of searching through the code, trying to find why you don't get the correct result.

Therefore, I really like it when a language requires to know what variable names may appear on each level (which could also be used to remove the __main__. for most global variable accessing, which would in turn also make things easier on the eyes).

I just wanted to clear this up.

Deathworks

Deathworks on 2007/08/31 10:44:

Hi!

I just noticed that the example given should have

Horse = Leg * 4 + Hunk

In its first line, not 'Legs' (^_^;;

Deathworks

dmoisset on 2007/08/31 12:42:

More tools for the poll:
  • Coding: We are a large team and have used several editors (depending who you ask ;-) ): mcedit, gedit, kate, vim, emacs
  • Graphics: Some done directly on gimp, other in inkscape and postprocessed with gimp. Graphics mostly ours. For last pyweek we did pen+paper drawings, scanned them, and postprocessed with gimp. No 3D
  • Sound: Some MOD tracker for linux, can't remember its name (should ask the musician... it was some ugly gtk1.2 based thingie, but it seems to work). Audacity, a microphone, and assorted kitchen items for sound effects. vorbis-tools for format conversion.
  • Infrastructure: SVN for source control, Trac for team collaboration, a mailing list for communication. OS: most of us on ubuntu (there was some Gentoo and Fedora here and there), and tested on XP
  • Assorted browsers (firefox or konqueror or other firefox based) for pyweek.org, python.org/doc, and assorted stuff; assorted IM clients (gaim, kopete, others) to chat on #pyweek
  • Coffee
  • A place full of computers and mattresses

ServalKatze on 2007/08/31 13:52:

Well... My team will use:
  • Coding: I manly use Geany (sometimes IDLE when testing under XP)
  • Libraries: Pygame and Pygsear
  • Graphics: That would be MS Paint (yes, just PAINT, no Shop or .Net ;)) and sometimes TheGimp
  • Sound: Audacity.
  • Music: ModPlug or Chibitracker..
  • 2 laptops. A couch.
  • Crackers, chips, chocolate, junk food and...
  • Tea.
Actually we wanted to spend the time between Pyweek4 and 5 to finish our game and get into some other tools and libraries (mtPaint seems very nice for pixel artists) but suddenly there were sooo many other, very important things to do.. ;)

atiaxi on 2007/08/31 17:56:

Something nobody's mentioned yet is PyChecker. A number of people have complained about bugs that this catches (i.e. it'll warn you if you're not using a variable you assign something to; this is a sign you've made a typo). While it can't catch aeverything, I've found it enormously helpful in weeding out the more common mistakes I make :)

Tigga on 2007/08/31 18:18:

Horse = Legs * 4 + Hunk . . . If (blablabla) : House = Horse - Leg .

Is easily fixed by:

House -= Leg

Which will throw an error. I can't think off the top of my head why you would ever want to initialise a varibale more than once.

Deathworks on 2007/08/31 18:35:

Hi!

Tigga: Well, the example was extremely simple because it should only illustrate that I didn't mean variable type but variable name typos, resulting in declaration of unused variables. In the real situation, the things that would really annoy you would be typos related to a variable that is used for something which is referred to by several routines with a more indirect result (for instance if you had a multi-dimensional table using a global variable as a cursor in it).

And not all equations can use '-=' and similar notations.

Atiaxi: Thank you for that tip. That program looks very useful and would probably help tremendously finding such problems the dynamic variable declaration brings about. I will definitely download and install it to help in the debugging phase.

Deathworks

Neppord on 2007/08/31 18:44:

Or if you realize the problem but don't know the name of the wrong named variable you could make a halt somewhere in the program and use dir() or .__dict__ to list its variables. and later do a find and replace :P.

Neppord on 2007/08/31 18:46:

dir(object) or object.__dict__ dir(object) or object.__dict__