B
Brandon J. Van Every
I am
- *TENTATIVELY* -
(operative word) undertaking the project of porting the GPL open source game
"Freeciv" to Python. Freeciv is, in essence, an almost straight clone of
Sid Meier's Civilization II, albeit with better cross-platform and
multiplayer support. www.freeciv.org
I'm undertaking the project independent of the current Freeciv project
managers. They are not a variable as to how the project will proceed. Our
goals are too disparate for us to attempt to coordinate with each other.
I'll consider offers of assistance, although first I must do a lot of work
on my own. Still, if my goals strongly ring a chord with your own goals,
let's talk. (And conversely, if you want something totally different, let's
not waste the breath. ;-) Here are my goals:
- the working title of the project is "ProtoCiv," but I'm amenable to better
names. "Better," in my parlance, means more marketable and more likely to
get people to play / develop / notice / care about / remember the project.
- the primary language of ProtoCiv development will be Python. Freeciv is a
C codebase, so a lot of migration work is needed. Python will "own" the
app, I will be starting at main() and digging as far down as I can easily
go. Once the digging is no longer easy, i.e. once I've hit "bad dirt," an
initial Python extension interface will be established. Over time, with the
help of others, the C code will be whittled away to bare performance
essentials.
- new coding in C will be actively discouraged.
- no clones of commercial games such as Civ II will be supported. One of
the first things I'll do in the ProtoCiv project is remove the current Civ
II support, and change the game significantly so that it is no longer almost
just like Civ II. I find straight or near-straight clones of commercial
products to be an offense to the game industry.
- "knockoffs" are ok. I define a "knockoff" as something very similar to
another game, but still a distinctly different game. For instance, Call To
Power II is a knockoff of Civ II, not a clone.
- the main purpose of the ProtoCiv project is to encourage rapid prototyping
by 4X TBS Game Designers. This is against the desires and energies of the
current Freeciv project management, and is my primary reason for going my
own way with this.
- an \alpha, \beta, and \release directory infrastructure will be
established in all distributions so that it's easy for Game Designers to add
features and get them distributed for in-the-field testing. Users will
voluntarily enable features. In ProtoCiv, there will be no Gatekeepers
deciding what game designs may or may not be tried. Anyone will be able to
submit \alpha features, although of course they'll be turned off by default
and the game developer will have to jazz people up about turning them on.
\beta and \release will be more stringently controlled for purposes of
making sure the code works, not for purposes of evaluating whether a given
game feature is good or not.
- ProtoCiv emphasizes Game Designer flexibility, not techie flexibility /
libido for its own sake. Gatekeepering to keep the system architecture
working properly will be more "traditional."
- I am a Windows-centric developer. Currently I'm working on the subgoal of
eliminating Freeciv dependencies upon crufty Cygwin and/or MinGW tools. I
will be maintaining Visual Studio .NET 2003 solution files. I am amenable
to cross-platform support, given that Freeciv already has a lot of
cross-platform client code, but Windows development will not be Cygwin or
MinGW dependent.
- I may integrate .NET support later on, using Python for .NET.
- This is a 4X TBS genre project. It is not a RTS, RPG, FPS, or other kind
of genre project. Project management will not become confused about the
basic nature of 4X TBS. Creating an engine for any game is not a goal.
Creating an easily modified 4X TBS engine, starting from a Civ-style
codebase, is the goal.
- If project components could in fact be used independently of genre, i.e.
world map generators, their modularity will be considered.
- I'm a commercial developer, not a hobbyist. Project participants are free
to treat the project "as a hobby," but when hobbyist and commercial
development cultures collide, commercial culture will win. For instance,
Commercial developers don't think all tools have to be free, nor does all
software have to be open source. Commercial developers do not say "let's
wait a long time before trying X." Commercial developers don't badger
people about giving away tons of work as some kind of moral virtue.
Commercial developers consider time to be money, and assess risk before
spending their money.
- FWIW I'm a proponent of MIT / BSD style "do whatever you want with it"
open source licenses, not GPL. I believe if you're going to give something
away, you should give it away completely. And if you don't want to do that,
don't give it away. I don't want GPL licenses interfering in my business
decisions, what I choose to make open source or proprietary. However,
Freeciv is a GPL codebase, so if I want to use it I'm stuck with it. I will
be looking for ways to put independent project components under MIT / BSD
license.
- Because of the GPL license, no commercial gain of any kind is believed
possible with this project. My main motives are:
1) get Game Designers to advance the Art and Science of 4X TBS game design
2) prototype game features that I might try in Ocean Mars someday
3) find out what level of 4X TBS modding is or isn't possible
- to accomplish these purposes, the project will be actively marketed. i.e.
Get articles about it on Gamasutra, Gamedev.net, gamer websites, etc. when
it's at an appropriate stage.
- *TENTATIVELY* -
(operative word) undertaking the project of porting the GPL open source game
"Freeciv" to Python. Freeciv is, in essence, an almost straight clone of
Sid Meier's Civilization II, albeit with better cross-platform and
multiplayer support. www.freeciv.org
I'm undertaking the project independent of the current Freeciv project
managers. They are not a variable as to how the project will proceed. Our
goals are too disparate for us to attempt to coordinate with each other.
I'll consider offers of assistance, although first I must do a lot of work
on my own. Still, if my goals strongly ring a chord with your own goals,
let's talk. (And conversely, if you want something totally different, let's
not waste the breath. ;-) Here are my goals:
- the working title of the project is "ProtoCiv," but I'm amenable to better
names. "Better," in my parlance, means more marketable and more likely to
get people to play / develop / notice / care about / remember the project.
- the primary language of ProtoCiv development will be Python. Freeciv is a
C codebase, so a lot of migration work is needed. Python will "own" the
app, I will be starting at main() and digging as far down as I can easily
go. Once the digging is no longer easy, i.e. once I've hit "bad dirt," an
initial Python extension interface will be established. Over time, with the
help of others, the C code will be whittled away to bare performance
essentials.
- new coding in C will be actively discouraged.
- no clones of commercial games such as Civ II will be supported. One of
the first things I'll do in the ProtoCiv project is remove the current Civ
II support, and change the game significantly so that it is no longer almost
just like Civ II. I find straight or near-straight clones of commercial
products to be an offense to the game industry.
- "knockoffs" are ok. I define a "knockoff" as something very similar to
another game, but still a distinctly different game. For instance, Call To
Power II is a knockoff of Civ II, not a clone.
- the main purpose of the ProtoCiv project is to encourage rapid prototyping
by 4X TBS Game Designers. This is against the desires and energies of the
current Freeciv project management, and is my primary reason for going my
own way with this.
- an \alpha, \beta, and \release directory infrastructure will be
established in all distributions so that it's easy for Game Designers to add
features and get them distributed for in-the-field testing. Users will
voluntarily enable features. In ProtoCiv, there will be no Gatekeepers
deciding what game designs may or may not be tried. Anyone will be able to
submit \alpha features, although of course they'll be turned off by default
and the game developer will have to jazz people up about turning them on.
\beta and \release will be more stringently controlled for purposes of
making sure the code works, not for purposes of evaluating whether a given
game feature is good or not.
- ProtoCiv emphasizes Game Designer flexibility, not techie flexibility /
libido for its own sake. Gatekeepering to keep the system architecture
working properly will be more "traditional."
- I am a Windows-centric developer. Currently I'm working on the subgoal of
eliminating Freeciv dependencies upon crufty Cygwin and/or MinGW tools. I
will be maintaining Visual Studio .NET 2003 solution files. I am amenable
to cross-platform support, given that Freeciv already has a lot of
cross-platform client code, but Windows development will not be Cygwin or
MinGW dependent.
- I may integrate .NET support later on, using Python for .NET.
- This is a 4X TBS genre project. It is not a RTS, RPG, FPS, or other kind
of genre project. Project management will not become confused about the
basic nature of 4X TBS. Creating an engine for any game is not a goal.
Creating an easily modified 4X TBS engine, starting from a Civ-style
codebase, is the goal.
- If project components could in fact be used independently of genre, i.e.
world map generators, their modularity will be considered.
- I'm a commercial developer, not a hobbyist. Project participants are free
to treat the project "as a hobby," but when hobbyist and commercial
development cultures collide, commercial culture will win. For instance,
Commercial developers don't think all tools have to be free, nor does all
software have to be open source. Commercial developers do not say "let's
wait a long time before trying X." Commercial developers don't badger
people about giving away tons of work as some kind of moral virtue.
Commercial developers consider time to be money, and assess risk before
spending their money.
- FWIW I'm a proponent of MIT / BSD style "do whatever you want with it"
open source licenses, not GPL. I believe if you're going to give something
away, you should give it away completely. And if you don't want to do that,
don't give it away. I don't want GPL licenses interfering in my business
decisions, what I choose to make open source or proprietary. However,
Freeciv is a GPL codebase, so if I want to use it I'm stuck with it. I will
be looking for ways to put independent project components under MIT / BSD
license.
- Because of the GPL license, no commercial gain of any kind is believed
possible with this project. My main motives are:
1) get Game Designers to advance the Art and Science of 4X TBS game design
2) prototype game features that I might try in Ocean Mars someday
3) find out what level of 4X TBS modding is or isn't possible
- to accomplish these purposes, the project will be actively marketed. i.e.
Get articles about it on Gamasutra, Gamedev.net, gamer websites, etc. when
it's at an appropriate stage.
