First post
stabbin...@gmail.com
sincerely hope I robbed some lowlife the pleasure. :)
Welcome, even though I don't know who you are yet. Let's kick this
off.
I would like at minimum:
* Complete separation of game logic from presentation; a project of
this size needs to retain the option to change its presentation layer
later
* Smooth gameplay, a la Diablo, Dungeon Siege, Torchlight
* Story with some depth, consequences, and alternate outcomes, a la
Star Wars: KotoR, The Witcher
* Party play, either with AI or network co-op
* If network co-op, I love team tactics, a la Guild Wars, World of
Warcraft; would be hard to pull off with AI
* I like character building with loot, armor, weapons, skills/spells,
and fundamental stats (but not overboard)
* Effects, but who doesn't?
* Effective mood control through graphics and sound: judicious use of
dark and light scenery, and music
* I prefer caricatures versus realism in graphics
Please, no:
* Anime; hentai
* Turn-based, except for mini-games if any
Gumm
Jon
I'm interested in seeing where this could go, though it may take some
effort to get many people working together on something as fairly
obscure as a PyGame rpg.
In terms of what i'd like to see... I've been thinking about a sci-fi
multiplayer rpg thing for a while. Are you fixed on the idea of a
swords and arrows style rpg or open to bringing in some space shooters
+ light saberish things?
In terms of game play i envisage it as a cross between Torchlight and
the old UFO games (minus the base building). I.e. real time missions
(single or multi player) with loot divided at the end and time to
equip / level-up your guys before the next mission. Did you ever play
Syndicate? Incorporating some of its Blader Runner style and the whole
upgradeable body parts would be cool.
As for multiplayer, on a technical note i'm looking for some remote
object experience and i'd like to investigate the possibility of using
PyRO with PyGame.
I'd describe my experience as:
Python: Intermediate
PyGame: Beginner
Artistic Talent: Very little
Let me know what you think. Maybe if we can get some ideas bouncing
around we can hook a few more from the PyGame list!
Cheers, J.
stabbin...@gmail.com
flop. :)
On Feb 23, 6:20 am, Jon <jholloco...@googlemail.com> wrote:
> Greetings,
>
> I'm interested in seeing where this could go, though it may take some
> effort to get many people working together on something as fairly
> obscure as a PyGame rpg.
With py2exe, and optionally a Windows installer, we can target any
average PC user we want.
> In terms of what i'd like to see... I've been thinking about a sci-fi
> multiplayer rpg thing for a while. Are you fixed on the idea of a
> swords and arrows style rpg or open to bringing in some space shooters
> + light saberish things?
I wouldn't say I'm dead set on sword 'n' sorcery, but I do like the
genre immensely. Diablo came along and I've been trying to recapture
the moment ever since. :) I confess I would be at somewhat of a
disadvantage in the SF genre. Though I'm an avid reader of SF, I
haven't really found any SF games that I felt did it justice. Sort of
gave up on them a while ago. Consequently I don't have any good
experiences, and nothing I've wanted to emulate. In other words, I
might be a creative dead weight.
> In terms of game play i envisage it as a cross between Torchlight and
> the old UFO games (minus the base building). I.e. real time missions
> (single or multi player) with loot divided at the end and time to
> equip / level-up your guys before the next mission. Did you ever play
> Syndicate? Incorporating some of its Blader Runner style and the whole
> upgradeable body parts would be cool.
Now Torchlight I love. =) Best thing to arrive in a long time.
Missions are a great structure by which to impose strategy. It is
definitely an aspect I'd like to incorporate. I guess we would have to
try it and see how it fares as a vehicle for an entire game, in which
case it puts the game entirely on rails; or perhaps it's best as an
element, in which case missions provide the rails at key progress
points and everything else in between is not so rigid.
> As for multiplayer, on a technical note i'm looking for some remote
> object experience and i'd like to investigate the possibility of using
> PyRO with PyGame.
PyRO is interesting at first glance. RPC and RMI are hot security
topics. We'll want to take a deep look, because people will certainly
cry "PyRO will let anyone run stuff on my PC!" :)
> I'd describe my experience as:
> Python: Intermediate
> PyGame: Beginner
> Artistic Talent: Very little
>
> Let me know what you think. Maybe if we can get some ideas bouncing
> around we can hook a few more from the PyGame list!
I'm thinking a small prototype would be a good advertisement. Ideas
and pep talks aren't as good as a demo.
If SF is the way you really want to go, perhaps you could OpenOffice a
very high level flowchart and storyboard for a chapter or level or
whatever you'd call it. That way I can get a feel for what kind of
game-play experience you're trying to create. By storyboard I don't
mean a novelette; I mean just an "in the thick of it" description of
what the player would see and do as s/he plays through a chapter. Or
we can keep talking possibilities if it's still too early for that.
Gumm
Jonathan Hollocombe
> > I'm interested in seeing where this could go, though it may take some
> > effort to get many people working together on something as fairly
> > obscure as a PyGame rpg.
>
> With py2exe, and optionally a Windows installer, we can target any
> average PC user we want.
I was more referring to the fact that the pygame dev community seems
quite small so it would be a challenge to get together a large group
for any one project. However, it's still a good goal to aim for and if
we end up building something good enough more devs will come.
>
> > In terms of what i'd like to see... I've been thinking about a sci-fi
> > multiplayer rpg thing for a while. Are you fixed on the idea of a
> > swords and arrows style rpg or open to bringing in some space shooters
> > + light saberish things?
>
> I wouldn't say I'm dead set on sword 'n' sorcery, but I do like the
> genre immensely. Diablo came along and I've been trying to recapture
> the moment ever since. :) I confess I would be at somewhat of a
> disadvantage in the SF genre. Though I'm an avid reader of SF, I
> haven't really found any SF games that I felt did it justice. Sort of
> gave up on them a while ago. Consequently I don't have any good
> experiences, and nothing I've wanted to emulate. In other words, I
> might be a creative dead weight.
I don't really mind if it's SciFi or Swords 'n Sorcery but my feeling
is that the fantasy dungeon game has been done very well already and
it would be good to take that style of game into new territory. In
terms of game play, there is very little difference between the two,
we could even develop it as one and re-skin it to the other at a later
stage:
bows + arrows <--> lasers
swords <--> energy swords
magic <--> psychic powers
portals <--> teleport
etc.
>
> > In terms of game play i envisage it as a cross between Torchlight and
> > the old UFO games (minus the base building). I.e. real time missions
> > (single or multi player) with loot divided at the end and time to
> > equip / level-up your guys before the next mission. Did you ever play
> > Syndicate? Incorporating some of its Blader Runner style and the whole
> > upgradeable body parts would be cool.
>
> Now Torchlight I love. =) Best thing to arrive in a long time.
>
> Missions are a great structure by which to impose strategy. It is
> definitely an aspect I'd like to incorporate. I guess we would have to
> try it and see how it fares as a vehicle for an entire game, in which
> case it puts the game entirely on rails; or perhaps it's best as an
> element, in which case missions provide the rails at key progress
> points and everything else in between is not so rigid.
I'm not thinking of missions as anything more restrictive than the
quests in Torchlight. My idea is more about having to choose what gear
and set-up you need before setting out rather than messing around with
gear whilst running around the dungeon.
I find the whole kill+loot+equip+repeat quite dull. When the missions
are short, action packed and fun I don't want to have to take 2
minutes out every 10 mins to go through everything I've picked up so
far, to dump a load of stuff so I can continue. I'd like to see a
dungeon crawler where you just have puzzles and monsters to kill in
the levels but when the level is over then you get to see what you
"won" and gear up for the next level.
>
> > As for multiplayer, on a technical note i'm looking for some remote
> > object experience and i'd like to investigate the possibility of using
> > PyRO with PyGame.
>
> PyRO is interesting at first glance. RPC and RMI are hot security
> topics. We'll want to take a deep look, because people will certainly
> cry "PyRO will let anyone run stuff on my PC!" :)
Of course we'll need to think about security and pyro may not be
practical in the long run but I'd like to play around with it for a
bit. Pyro can use SSL and you can implement authentication protocols
so it possible we could make it secure enough. TBH, I have no idea how
most games handle this kind of thing. As far as I can see if you open
up port on your machine accepting connections from the game on another
computer there is always a level of security risk in this.
I've knocked up a bit of code to try out pyro. The game is a rubbish
version of Pong but i think it demonstrates the power of pyro quite
well. I've attached the code. I develop in Ubuntu so have no idea if
this works in windows.
>
> > I'd describe my experience as:
> > Python: Intermediate
> > PyGame: Beginner
> > Artistic Talent: Very little
> >
> > Let me know what you think. Maybe if we can get some ideas bouncing
> > around we can hook a few more from the PyGame list!
>
> I'm thinking a small prototype would be a good advertisement. Ideas
> and pep talks aren't as good as a demo.
>
> If SF is the way you really want to go, perhaps you could OpenOffice a
> very high level flowchart and storyboard for a chapter or level or
> whatever you'd call it. That way I can get a feel for what kind of
> game-play experience you're trying to create. By storyboard I don't
> mean a novelette; I mean just an "in the thick of it" description of
> what the player would see and do as s/he plays through a chapter. Or
> we can keep talking possibilities if it's still too early for that.
I'm not fixed on any one idea specifically. I might brain storm a few
ideas down to try and get a better feel of where I see it going but
I'm open to persuasion on all fronts.
I might also buy myself a tablet soonish so i could try and do a few
sketches for graphical ideas.
Cheers, J.
Jonathan Hollocombe
I've been jotting a few ideas down:
http://docs.google.com/Doc?docid=0AYzhI2PnShkEZGR4c3o1Mm1fMjRoYzlra2ZobQ&hl=en
It's not complete yet but let me know what you think.
Have you thought any more about the project? Let me know what your
plans/ideas are for it.
Cheers, J.
stabbin...@gmail.com
I like the way you've presented your concept. It's very clear to me
now, and the ideas are quite close to what I was visualizing. And very
doable. It should not be difficult to build a demo that does all this.
Then we might see more interest after the demo.
This is all one big experiment. I love it. *cackling and rubbing of
hands* :)
I have been thinking about game structure, i.e. the layers. I'm not a
student of game design, but I have picked up concepts along the way
from some well written papers and articles. Here's a first whack at
it. These are not necessarily single modules, files, or classes. I
think of them as layers for simplicity, but they're probably more akin
to dimensions.
Object: provides state of objects; (im)movable, (in)destructible,
container, what/how many it can contain, what containers it can go in
World: provides geographic units, rooms, exits to link rooms together,
and facilities to attach objects within a plotting system
Player: provides stats and slots for managing aspects of a player
character
Interactions: framework for object behavior, e.g. a sound when
something happens; protocols for sequence and timing of progressive
interactions (attack, parlay, etc.)
UI: self-explanatory
Visual: self-explanatory
Audio: self-explanatory
Collaboration: multi-player messaging; not just chat; methods for a
game to tell other connected games about itself
Intelligence: AI system; game plot and progress
These would be very high level and will not define the real code that
drives the computer. They define the facilities a game programmer uses
to manipulate the game environment, like audio.load_sound,
room.add_object, player.shoot. They are general actions on things in
the world, and don't care how the actions are implemented. You can
(and probably will need to) layer them per game, so if for example you
change your UI library you only need to change your layer next to the
UI library and not the many usages of UI throughout your game.
Python already aids this kind of design very nicely with its object
features. But I found even my thoughtful use of classes in Trolls
Outta Luckland was prone to creep towards tight integration, and it
became hard to change some areas of the game without having to search
out the many resulting breakages. That's when I began to feel strongly
that I needed a looser integration of parts. :)
Of course, the downside to this is that a considerable amount of vague
code needs to be written before you can make something interesting out
of it. And it's engine-like in its concept, which begs the question:
why reinvent it? There are engines out there.
Gumm
Jonathan Hollocombe
Glad to hear we've got similar goals for this. It'll be interesting to
see what we can produce.
As for game structure, i was reading
[http://ezide.com/games/writing-games.html] that was linked in a
pygame list post. This seems a pretty good starting point for any
project and gives a good starting framework to expand upon. You're
right that we need to keep the game model separate from the UI,
networking, audio, etc.
My initial idea would be along a structure like (rough idea, not
thought through clearly yet):
- Model
- Creature
- Player
- Enemy
- AI
- World
- Physics
- Creature interactions
- Persistence (saving)
- View
- UI
- Sprites
- Creatures
- Levels
- Menus
- Audio
- Controller
- Keyboard
- Mouse
- Network
You mentioned existing game engines, which would be good ones to look
at? Keep in mind this is for fun and learning as well though, and
reinventing the wheel can be fun :)
Have you much experience with UML? I don't think we need a great deal
of design upfront as this will (and should) be a fairly organic design
but UML is a good way of nailing down a few design patterns and class
structures. I'll try and put together a rough high level design that
we can discuss.
I think we need to sort out a name so we can host this project
somewhere (google code seems a good choice). I'm pretty open on names
and it's a bit tricky thinking of them before starting the coding. We
could always use the working title of "gumms rpg", or my only idea so
far is "Swarm" (based on my thoughts on AI design).
Cheers, J.
p.s. I'm pretty busy the next few weeks... not going to be able to
start any coding soon but can still reply to emails.
stabbin...@gmail.com
On Mar 5, 11:01 am, Jonathan Hollocombe <jholloco...@googlemail.com>
wrote:
> [http://ezide.com/games/writing-games.html] that was linked in a
> pygame list post. This seems a pretty good starting point for any
> project and gives a good starting framework to expand upon. You're
> right that we need to keep the game model separate from the UI,
> networking, audio, etc.
Thanks, I'll give it a read. My jumbled thoughts could use some
organization. :)
> You mentioned existing game engines, which would be good ones to look
> at? Keep in mind this is for fun and learning as well though, and
> reinventing the wheel can be fun :)
I think FIFE was the first one I looked at. I didn't like that it
required Blender 3D objects. Its pathing was quirky. And it wasn't
documented. Besides, I wanted to code more and FIFE seemed all about
the content and mini-scripts for FIFE's event engine.
I may have looked at another, but I'm fuzzy on the month or two
journey, pre-Pygame. Maybe that was Pyglet--not an engine, rather a
multimedia platform alternative to Pygame.
So here we are, mulling over choices: pre-rolled libraries or roll-yer-
own.
> Have you much experience with UML? I don't think we need a great deal
> of design upfront as this will (and should) be a fairly organic design
> but UML is a good way of nailing down a few design patterns and class
> structures. I'll try and put together a rough high level design that
> we can discuss.
I've never used UML. It looks interesting from Wikipedia's 10,000 ft.
view. Also potentially rather complex, and as much work as just coding
it. =) I know, that's what all undisciplined coders claim. Diagrams
are a great way to show ideas, though, and I think I could easily
understand some high-level UML diagrams if not create them.
> I think we need to sort out a name so we can host this project
> somewhere (google code seems a good choice). I'm pretty open on names
> and it's a bit tricky thinking of them before starting the coding. We
> could always use the working title of "gumms rpg", or my only idea so
> far is "Swarm" (based on my thoughts on AI design).
Dunno. My muse is reprehensibly lazy. I use name generators where
available when rolling game characters. I don't need to my moniker up
in lights. Since we want to attract other contributors eventually, we
need something enticing, or at least not off-putting. :)
Yesterday I made a world_kit package just to toy with some design
ideas. It's nice and small, but conveys the organization of my
thoughts pretty well (upon which I also went into some detail in a
pygame-users post today). I will put it up on Google Code soonish and
let you know where it is. It has me leaning towards parallel projects,
or at least a project design where the low-level world kit can be
yanked out for use in another project. I'd like to not have to rewrite
the nuts-n-bolts, as I will have done twice now on a fairly large
scale.
I have been using SVN on Google Code so far. Are you okay with SVN?
> p.s. I'm pretty busy the next few weeks... not going to be able to
> start any coding soon but can still reply to emails.
Me too. Work has kept me very busy, leaving not much energy to do
cerebral things. But that will change. And I can always find time to
progressively chat. It's been good hearing your ideas.
Gumm
stabbin...@gmail.com
foundation I'm heavily invested in. I suspect it could be another idea
generator. You know: keep the good parts, throw out the rest. I have
no problems canning it and starting over.
Gumm
Jonathan Hollocombe
I'm far too lazy to make complex diagrams of what i'm going to code,
it's more a case of a few high level ones to express my ideas. A
picture can be worth a thousand words and all that.
> I will put it up on Google Code soonish and let you know where it is.
Sounds good. Let me know when it's up and i'll take a look.
> I have been using SVN on Google Code so far. Are you okay with SVN?
I'm fine with SVN, been using Hg (mercurial) more recently but either is good.
I like your idea about keeping the projects separated. It would be
good if we can end with a few pluggable components that other people
can use or we can swap one out for another one later.
Cheers, J.
stabbin...@gmail.com
I added you as an owner using your googlemail account. Not sure if
that will work, or if you need a gmail account. Let me know if you
have trouble.
Gumm
Jonathan Hollocombe
I've had a look at the code and even made a few tweaks (i'll explain
these when i check them in tonight).
My main question about this is: where do you see this going?
There seems to be two levels of abstraction here. At the highest level
we have the Object and Container (world_kit) classes which provide
very abstract (though perfectly reasonable) notions of "something" and
"something that contains other things". On top of this we have seem to
have the start of game engine with Rooms, Items, etc.
Are you planning to develop the very abstract world_kit side or
develop the game engine using what is there now. My concern with the
latter is that developing anything at that level of abstraction is
_very_ hard as you not only have to think about how it will be used
now but all the ways it might be used in the future.
My inclination would be to take the game engine and try to expand it
into an all-singing all-dancing generic game engine. It could be built
to maximise the number of types of games that could be generated from
it. Whilst building this we could, when possible, refactor some
concepts out of this engine and into the world_kit.
Cheers,
Jon.
On 8 March 2010 16:36, stabbin...@gmail.com
Jonathan Hollocombe
crazy but i though I'd explain some of it.
The two main changes are:
1. Adding properties to the classes.
2. Adding Level class.
1. The way I see properties is that they some encapsulate the getting
and setting of values. Properties (or plain attributes) should be
used for what class holds, usually nouns such as name, age, id, etc.
Methods should be about what the class does, usually verbs such as
run, open, do_stuff, etc.
2. This seemed like a natural re-factoring and Level seems like a
natural extension of Room and Exit.
I've also added a bit more white space to the files as I find it hard
to read code without it. Hope you don't mind.
My next thoughts were to add a LevelCreator class that I could subclass to make:
> TestLevelCreator: creates the very simple level we have now.
> FileLevelCreator: loads a level from a (probably XML) file.
> RandomLevelCreator: creates a random level, would need to figure out how to place links so they made sense.
Another idea was to create a MobileObject class, inheriting for
Object. I am still try to figure out how a physics engine would be
integrated with the kit (or whether it should be defined outside of
the kit and passed in), but I'm pretty sure we need an object type
that has position, velocity, orientation, etc.
I've also knocked up some UML diagrams of what there was, is, and could be :)
See attached files. If you'd like the actually diagrams I can send
them to you, they are made using Violet UML (a very simple UML sketch
pad, almost a fantastic little program but has it's niggles, adding
some features/fixes to it is on my list of things to do :)
Cheers.
stabbin...@gmail.com
I've just started reviewing your modifications. I intend to take some
time thinking about them, and about your comments and diagrams. But I
can reply on the soft topics now.
I don't mind whitespace. I've simply developed the habit of not using
it inside subroutines and classes while writing code in Nedit and vi,
which offer wieldy keystrokes for skipping forward by paragraph (a
group of adjacent lines separated by a blank line). But I don't use
Nedit and vi for Python coding. Using whitespace is considered a best
practice anyway, so I vote yes.
I'm lazily reading through the writing-games tutorial you linked. I
have to say, the MVC model is very slick. I'd never seen it before.
One thing I was curious about is whether the many instances of CPU
spinner events might trigger a disruptive amount of garbage
collection. Have you tried it?
My intent for the world kit is for it just to provide building blocks,
so it is purposely generic and plainly abstract. The game engine would
be one or more layers above the world kit. I think my notion of the
game engine layer is what you were speaking of when you mentioned an
organic framework--something that closely represents the game world,
and is likely only reusable for that particular kind of game. Where we
draw the line remains for us to decide. I'm not really interested in
creating a generic game engine. Like you said, you have to provide
functionality for every conceivable common use. Gah, what a lot of
work. :) Of course, I'd like to hear your thoughts on this.
Small side-topic. Looks like you're using some Python 2.6 features. I
was using Python 2.6 for a while, and digging it. But when I started
learning OpenGL I had to go back to Python 2.5.4. If I recall
correctly Numpy had no builds for Python 2.6 yet. This is worth
mentioning because if we're going to do a smooth-scrolling display I'm
inclined to suggest OpenGL 2D for the speed, and most OpenGL sample
code and libraries require Numpy. If you download my first project,
Gummworld (pure Python+Pygame), and run the demo game you may notice
good frame rates on a beefy computer. But the demo game is just
boring, static sprites. Adding anims, effects, and a lot of game logic
would really tax the CPU, and it could turn out that only folks with
the beefiest rigs would be able to enjoy the full effect. So there is
something to consider: selecting a standard development environment.
I'm pretty sure Numpy will catch up eventually (maybe it already has
when I wasn't looking). But it would kinda suck to have to remove
advanced code to retro-fit it. I had to do it once at work and it made
me a bit grouchy to dumb down my elegant solution for Python 2.3. :)
So we should think ahead and decide before writing a large body of
code.
Gumm
Jonathan Hollocombe
> Small side-topic. Looks like you're using some Python 2.6 features. I
> was using Python 2.6 for a while, and digging it. But when I started
> learning OpenGL I had to go back to Python 2.5.4. If I recall
> correctly Numpy had no builds for Python 2.6 yet. This is worth
> mentioning because if we're going to do a smooth-scrolling display I'm
> inclined to suggest OpenGL 2D for the speed, and most OpenGL sample
> code and libraries require Numpy. If you download my first project,
> Gummworld (pure Python+Pygame), and run the demo game you may notice
> good frame rates on a beefy computer. But the demo game is just
> boring, static sprites. Adding anims, effects, and a lot of game logic
> would really tax the CPU, and it could turn out that only folks with
> the beefiest rigs would be able to enjoy the full effect. So there is
> something to consider: selecting a standard development environment.
> I'm pretty sure Numpy will catch up eventually (maybe it already has
> when I wasn't looking). But it would kinda suck to have to remove
> advanced code to retro-fit it. I had to do it once at work and it made
> me a bit grouchy to dumb down my elegant solution for Python 2.3. :)
> So we should think ahead and decide before writing a large body of
> code.
>
It hadn't even occurred to me which version of Python to use :(
However, I'm pretty sure I have Numpy installed on my dev environment
(which is 2.6 as you noted). Quoting from a quick Wikipedia check:
"NumPy version 1.3.0, released April 5, 2009, supports Python 2.6.[7]
Support for Python 3 is planned, but not yet scheduled."
Same we can't use 3.0, I've had a play with it and some of the feature
are pretty nice. I've also been force to use an older version (2.4)
for work recently and it is very annoying, I am most used to working
with 2.6 so my vote lies with this, though would be happy to go back
to 2.5 if necessary.
Cheers,
Jonathan.
Jonathan Hollocombe
with a few IDEs but haven't been massively impressed with any so far.
I tend to just used a text editor at the moment but as the project
gets larger some IDE support my be useful.
one IDE that looks interesting is PyCharm by JetBrains. People i know
who use IntelliJ rave about it so i'm hoping for big things from
PyCharm. It is in preview state at the moment so is probably a bit
rough around the edges.
stabbin...@gmail.com
are still some good free ones out there.
I started out using PyScripter (http://mmm-experts.com/Products.aspx?
ProductId=4). This is a great little IDE. All the basic frills I need.
And it has source helpers, like tooltips over identifiers to tell you
their class, and a modifier key combo (Control I think) that makes the
source "hot" so you can click an instance, function, variable, etc.
and go right to its definition. Very slick. I had to give it up,
though, when I installed PyOpenGL and it began hanging for one to two
minutes, looking up library references I assume. I couldn't figure out
the cause and had to give it up. Alas, I really liked it.
Then about that time someone posted an IDE thread to pygame-users. I
saw that DrPython has a source browser. I really, really like the
source browser so I'm sticking with DrPython. It's written in Python
and wxPython, so it works on Linux as well. It's great to have an IDE
that works on all my platforms.
Since DrPython I've looked no further.
Gumm
stabbin...@gmail.com
wrote:
> "NumPy version 1.3.0, released April 5, 2009, supports Python 2.6.[7]
> Support for Python 3 is planned, but not yet scheduled."
You're right. I dug around in my downloads directory and found Numpy
for Python 2.6; and PyOpenGL, and PIL. I know there was something that
stopped me. I remember now. Older OpenGL demos were blowing up on the
new Numpy, which changed a fundamental aspect of its usage. I spent
days researching and talking to people and finally gave up, as I
didn't know Numpy or OpenGL enough to fix the issue myself, and had to
wait on library authors to spend time on it. RB[0], for example, told
me he wasn't currently active on Pyggle, and had a lot of work that
took precedence over Python 2.6 and Numpy N.n compatibility. So I back-
revved in order to catch my OpenGL wave of enthusiasm before it was
gone. :)
The other point of reluctance I had centered around Pygame's download
page, which states Python 2.5.4 is the most stable release for
Windows. I do not know if that info is stale, but I recall that
comment has been posted there since I began using Pygame a little over
a year ago.
Gumm
Jonathan Hollocombe
Thanks for the tips... i'm going to check out DrPython soon. I develop
in linux (Ubuntu) mostly but i also have Windows 7 so i can check that
the code runs in that too.
What is the conclusion about the Python version? Sounds like you think
we should be targetting 2.5.4? If this is the case i'll make sure i
have everything set up for 2.5.4 and use that from now on.
Whats you thoughts for next steps? I should have some time this
weekend to spend on it (though i just bought Mass Effect 2 which could
be taking up lots of my time :)
Cheers.
stabbin...@gmail.com
Looks like we both got a little busy. I'm still reading/not quite done
with the CMV tutorial. And spent some time shopping for Python IDEs.
On Mar 23, 3:59 am, Jonathan Hollocombe <jholloco...@googlemail.com>
wrote:
> Hi,
>
> Thanks for the tips... i'm going to check out DrPython soon. I develop
> in linux (Ubuntu) mostly but i also have Windows 7 so i can check that
> the code runs in that too.
I'm gonna start a new thread for this one. I have some useful links to
help your search.
> What is the conclusion about the Python version? Sounds like you think
> we should be targetting 2.5.4? If this is the case i'll make sure i
> have everything set up for 2.5.4 and use that from now on.
I don't have a strong opinion yet. I've decided to ask on pygame-users
mailing list. I'm game for 2.6. Let's see what they say, it may help
steer our decision.
> Whats you thoughts for next steps? I should have some time this
> weekend to spend on it (though i just bought Mass Effect 2 which could
> be taking up lots of my time :)
Oh no! You will never come up for air. :) I've been toying with the
notion of getting Mass Effect 2. I have a AMD 3000+ dual-core which is
2-3 year old technology. Wondering how it will perform.
I just got Assassin's Creed, so we're in the same mode right now.
That's somewhat convenient. :)
For a next step I was considering modifying the basic (network-
unaware) MVC code to use world kit with its two-room example. I don't
quite understand the Twisted networking stuff. I recall you mentioned
another preference for networking, so I thought it best to defer any
effort along that line. MVC makes it looks very easy to add a network
controller later anyway. In fact, using the MVC model it should be
very easy to swap out the world kit for a different one, as well.
Did you have any notions for next step? Whatever you want to try at
this stage is okay with me.
Gumm
Jonathan Hollocombe
> mailing list. I'm game for 2.6. Let's see what they say, it may help
> steer our decision.
>
The outcome from the list seems to be that 2.6 is ok to use. I'm going
to keep going with 2.6 then and we can look at this again if we hit
any problems later.
> For a next step I was considering modifying the basic (network-
> unaware) MVC code to use world kit with its two-room example. I don't
> quite understand the Twisted networking stuff. I recall you mentioned
> another preference for networking, so I thought it best to defer any
> effort along that line. MVC makes it looks very easy to add a network
> controller later anyway. In fact, using the MVC model it should be
> very easy to swap out the world kit for a different one, as well.
>
The networking stuff in that tutorial is more than we need at the
moment, i think you're right in just ignoring it for now. Bits like
networking can be added on later with the MVC pattern.
I might have a try at creating a prototype game, a simple one level
isometric shooter thingy, using the basics of what is there now. I'll
create a branch in the repo for this so not to clutter up the trunk
too much. Once it's done we can look to see how much (if anything) can
be generalised back into the world_kit.
Cheers,
Jon.
stabbin...@gmail.com
I unintentionally let this sit a few days. No idea why, but the email
conversation didn't update when you posted here. As a result I thought
you were off doing life stuff and hadn't responded. I guess I'll need
to build the habit of checking in every couple days. Our open
topics...
Python version:
The major concerns with Python 2.6 seem to be
1) MS Visual C runtime availability. Using Python 2.6 means all users
of WinXP will have to install the newer MSVC library. It's not a big
deal to do that, but making it a seamless part of application
installation is something I have never solved. I seem to recall it's
not distributable unless you've bought a Visual Studio license.
2) py2exe packaging. We need to try this. If it works, then it's no
longer a concern.
MVC tutorial:
I can't get the standalone example to work. The rewrite required was
approaching absurd, so I gave up. Only the client-server example is
functional. So perhaps we'll have to base our project on that and
stripping out the network components?
Isometric:
I was looking for tile engine for this. PGU caught my eye, but I'm not
sure how integration-friendly it is.
http://www.pygame.org/project-PGU+-+Phil%27s+pyGame+Utilities-108-.html
A while back I considered Isotope. I didn't like the engine approach,
and didn't like the feel of it. Even if we decide not to use an
engine, they might be good sources to learn from.
http://www.pygame.org/project-Isotope-167-.html
Did you already have something in mind to base your isometric view
upon?
Misc:
I finished the MVC tutorial and looked over your docs. Good stuff. I
think they are keepers. :)
I'm looking for a new SVN client. I love Tortoise, but it's having
deadlock issues now that affect everything on my system. I think it
was responsible for the deadlocks that I blamed PyScripter for. The
deadlocks went away after I removed Tortoise SVN. Before I go off on a
perusal safari, do you have a favorite you might recommend?
Gumm
Jonathan Hollocombe
> conversation didn't update when you posted here. As a result I thought
> you were off doing life stuff and hadn't responded. I guess I'll need
> to build the habit of checking in every couple days. Our open
> topics...
Don't worry. I have been off doing life stuff, turns out I didn't
actually have time to do anything that I was thinking about.
> 1) MS Visual C runtime availability. Using Python 2.6 means all users
> of WinXP will have to install the newer MSVC library. It's not a big
> deal to do that, but making it a seamless part of application
> installation is something I have never solved. I seem to recall it's
> not distributable unless you've bought a Visual Studio license.
>
> 2) py2exe packaging. We need to try this. If it works, then it's no
> longer a concern.
Newer MSVC lib not included in service packs? I'm totally new when it
comes to packaging and supplying code on Windows. This is why I
develop in Linux, trying to get things compiled and working in Windows
makes my head hurt. I agree we should try out the py2exe and make sure
it works with 2.6.
> I can't get the standalone example to work. The rewrite required was
> approaching absurd, so I gave up. Only the client-server example is
> functional. So perhaps we'll have to base our project on that and
> stripping out the network components?
I'll take another look at the tutorial soon, I have to admit that I
never worked through any of the code but it looked like it should
work.
> Isometric:
I've got somewhat sidetracked on this messing around with Blender. I
wanted to get a simple 3d model so I could some take isometric images
from it. I'd like to get something a lot nicer looking that the 4 view
1980s style isometric game, something more like Torchlight.
> I'm looking for a new SVN client. I love Tortoise, but it's having
> deadlock issues now that affect everything on my system. I think it
> was responsible for the deadlocks that I blamed PyScripter for. The
> deadlocks went away after I removed Tortoise SVN. Before I go off on a
> perusal safari, do you have a favorite you might recommend?
I have never used anything other than Tortoise for SVN (and Hg) on
Windows. I think the other options are using the command line SVN
(which is pretty straightforward once you get used to it) or using an
IDE that has built in SVN support such as Eclipse. Have you tried
updating to the latest Tortoise client? Sometimes this can help a bit.
Jon.
stabbin...@gmail.com
py2exe works with Python 2.6.
I fixed my Explorer hangs. Windows had a corrupt event log, and
everything that wrote to it was hanging. I can use Tortoise SVN again.
Yay.
Gumm