Rebooting the game

Here's the story so far:

On 1st Jan 2005 I decided to write a turn-based hexagonal strategy game in Python. I dived into the code, and over the next 2 or so years produced enough code to make what looked like the start of a game.

However, I was too ambitious, and gave up in late 2007 after several spurts of activity.

One good piece of code that I was reasonably proud of was the custom GUI, and I returned to it a few times to maybe use in other projects.

I directed my programming in other directions (also got married and had a child) but the end I came back to SPQR because it's the best piece of work I've made, and the only one that keeps me inspired.

Recently I worked on the game PARPG http://blog.parpg.net/ and that gave me a good chunk of experience about working with a team.

So here I am again, with the determination to make SPQR at the very least, a playable, enjoyable game.

I think a major aim of the reboot is to simply be DIFFERENT to current strategy GPL games.

In the land of board gaming, there has been a slow movement away from hex-based games to using other mechanisms (such as card-based rules in certain areas). I feel that SPQR should go that way as well (I have already decided on a region-based map, and not hexes).

Also, look at the 'competition' so to speak: FreeCiv, Wesnoth and FreeCol are all hex or square based and their combat is very similar in its gameplay. SPQR should aim to be different in this way and not just follow the herd. This project is a game, not a follow-the-leader exercise

Well, after a lot of thought, I AM going to stick with hex based, but those hexes will be split into regions and your control of them will not be as complete as you would like (in most cases, anyway).

What is a "card-based" game? I have no understanding of what you mean by region instead of / in additional to hex. Is it just about how fine grain the area units are? Granularity aside, how else is SPQR different than other GPL games?

Toeholds wrote:What is a "card-based" game? I have no understanding of what you mean by region instead of / in additional to hex. Is it just about how fine grain the area units are? Granularity aside, how else is SPQR different than other GPL games?

Card based; in recent years, many board wargames (and SPQR is really just a board game on a computer) have started using some card-based rules, where you may pick up or 'play' various cards on each turn of the game. These mechanics, if implemented carefully, can add a lot to a game. A good example is the game Hannibal: Rome vs Carthage.

Region based: Historically - or at least in the period we are looking at - the terrain was dominated by the city-state. The way we represent it in this game is that a 'region' consists of a hex with a city and it's surrounding hexes (regions can vary in size). My intention is that military moves, supply and battles will be conducted hex by hex, but the economic and political status will be set region by region. Also, when you conquer the regions city, then you will conquer the whole region's hexes (normally).

Other differences:

SPQR is populated by people. You as a gamer only play one of those people. This means that you will not have full control over the whole empire. In the region that you are in, you will have full (hex-based) control of the military and battles, outside of this you will have less control. At the start of every game turn you will the choice to play a different person.

Fine control can be achieved (you can have this control, if you like) but it will come at a cost (as it did historically); much more bureaucracy, making the government much more expensive to run.

The other main difference is that I would like the economic and political aspects of the world to be just as fleshed out as the military ones (which might mean dumbing down the military side, I know).

maximinus wrote:
Card based; in recent years, many board wargames (and SPQR is really just a board game on a computer) have started using some card-based rules, where you may pick up or 'play' various cards on each turn of the game. These mechanics, if implemented carefully, can add a lot to a game. A good example is the game Hannibal: Rome vs Carthage.

Region based: Historically - or at least in the period we are looking at - the terrain was dominated by the city-state. The way we represent it in this game is that a 'region' consists of a hex with a city and it's surrounding hexes (regions can vary in size). My intention is that military moves, supply and battles will be conducted hex by hex, but the economic and political status will be set region by region. Also, when you conquer the regions city, then you will conquer the whole region's hexes (normally).

Other differences:

SPQR is populated by people. You as a gamer only play one of those people. This means that you will not have full control over the whole empire. In the region that you are in, you will have full (hex-based) control of the military and battles, outside of this you will have less control. At the start of every game turn you will the choice to play a different person.

Fine control can be achieved (you can have this control, if you like) but it will come at a cost (as it did historically); much more bureaucracy, making the government much more expensive to run.

The other main difference is that I would like the economic and political aspects of the world to be just as fleshed out as the military ones (which might mean dumbing down the military side, I know).

Ah, gotcha. Settlers of Catan meets Civilization meets Heroes of Might and Magic I would totally be into painting cards. Particularly if the cards can be described by XML... then the content can be extended dynamically. That, I think, would bring the mechanics sufficiently far from the umbrella of other GPLs. And we can make SPQR extra special bonus collectibles and theme-packs...

Speaking of gameplay, is it possible to (eventually) wrap all this in platform-specific binaries? Normal people don't compile their games... (and normal people also think python is a kind of reptile.)

I still don't get what the fuss about region is. It sounds like you're saying that there are properties at both hex and hex-aggregate levels... which is true for all other strategy games. "Gold" in Civ is a property of a civilization, but troop movements are property of a hex.

The multiple people concept is intriguing. Do you mean that in each turn you're playing a different city-state? What prevents people from intentionally sabotaging the other city-state for a victory?

What are the victory conditions? How long is each game going to last?

Is SPQR multiplayer-enabled? Being turn-based, it seems like it's very suitable for a fun MP game.

Ha! I've just noticed the "docs" folder in the package. Good stuff. You might want all that info on a webpage somewhere though. I still can't figure out how cards integrate into the mechanics of a hex game.

...and I just can't get pygame to work so I can see for myself. Bleh.

Is pygame that difficuly to get working on Mac? Admittedly I've never tried it myself.

What version of Python and Pygame are you trying with?

I have multiple python installs, and that may be part of the problem. The pygame installer doesn't work, and I don't feel the urge to build it from source yet.

Toeholds wrote:Speaking of gameplay, is it possible to (eventually) wrap all this in platform-specific binaries? Normal people don't compile their games... (and normal people also think python is a kind of reptile.)

I still don't get what the fuss about region is. It sounds like you're saying that there are properties at both hex and hex-aggregate levels... which is true for all other strategy games. "Gold" in Civ is a property of a civilization, but troop movements are property of a hex.

The multiple people concept is intriguing. Do you mean that in each turn you're playing a different city-state? What prevents people from intentionally sabotaging the other city-state for a victory?

What are the victory conditions? How long is each game going to last?

Is SPQR multiplayer-enabled? Being turn-based, it seems like it's very suitable for a fun MP game.

Right, one at a time again

Q: Is it possible to wrap all this in platform-specific binaries?

A: Short answer: YES. Longer answer: Why should I have to, since the idea of using Python + Pygame is partly to avoid all that anyway.

Q: I still don't get what the fuss about region is.

A: Military units are moved via hexes, economics and politics only has a regional granularity.

Q: Do you mean that in each turn you're playing a different city-state?

A: You play a person who's normal total control is limited to one region, although most of the time you have some control over other regions. You can choose WHICH person to play each turn, although most of the time you'll probably stick to the same person (until they grow old and die).

Q: What are the victory conditions?

A: In short, survival, or building a great (money+culture+power) empire.

Q: Is SPQR multiplayer-enabled?

A: Not now, but the game type (turn based) and code architecture makes that pretty easy

Q: Is it possible to wrap all this in platform-specific binaries?

A: Short answer: YES. Longer answer: Why should I have to, since the idea of using Python + Pygame is partly to avoid all that anyway.

Having a "one-click" install solution helps attract players, which have positive secondary effects. (Improving morale is the one I'm having in mind... which down the road, helps attract and keep helpers) Even though I have experience coding in python, I have a hard time getting it to work.

Speaking of which, I did manage to get pygame installed from source! I get to see the GUI, and it does look good. However, it crashes on exploration, sometimes mysteriously, sometimes with an error code ("NameError: global name 'SCREEN_HEIGHT' is not defined" is one of them).

I played around with adding my own elements to the game. First impressions is that the engine is tied to the graphics much more tightly than I expected. Adding in any resources that are not exactly the same #px causes havoc (e.g., the move arrows are all anchored on the upper left and displayed without scaling; any higher resolution images end up displaced and cut-off) The map clearly is off, and since each grid is tied to a database, I don't know if there is any shortcut to fixing it (short of redrawing it using your map as a template).

For better or worse, here's how it looks ATM... it's kinda cool to be able to integrate assets so quickly.

Looks pretty cool!

In response to your points:

A one-click solution is preferable, I just suppose that since I don't own any of the platforms on which this is a problem (windows and Mac), this is not something that I can easily fix.

Bugs: Currently, IF YOU RIGHT-CLICK ANYWHERE THE GAME WILL EXIT IMMEDIATLY! This is because I sometimes test on full-screen mode and need a way to exit quickly. These will show no errors. If you DO get an error, then let me know the error message and I can fix it I think SPQR is reasonably error-free to be honest.

Graphics are SOMEWHAT tied to the engine. If you look at the file spqr_defines.py you'll see a whole ton of values for various gfx placement values; these ccould instead be generated by the engine at the start of the game. It at least means that you (well, me really) don't have to hunt and peck around the engine code to change the parameters. It is just the move arrows that you wanted to change?

Map database is a more serious problem, I think I need to build some kind of map-editor into the game, but that is quite a long-term solution. My feelings are that at some point the size of the map and hexes are FIXED and that makes it a lot easier to move forward. At the moment it's a lot of work to re-do everything for different sizes (since SPQR is written to only deal with the one set of sizes right now).

One of the things we (we... damn, when did that happen?) should do is Release-Early-and-Often. The projects I've worked with which comes to fruition all follow this principle. That said, you're no pie-in-the-sky dev, so you probably know that... (on the aside, REaO is probably where python would really shine.)

The binaries may be less of a problem once it's semi-playable, and folks volunteer to compile for each platform (ala Wesnoth). When we can't provide binaries, there should at least be some regular YouTube tech demos to show some signs of life.

--

I fell into the right-click quit trap a few times. I keep trying to right-click some other things The other times it's mostly when scrolling to the edges of the maps. It then gives:

Code:

File "/Users/Toeholds/Desktop/spqr/SPQR_0_3_5b/scripts/spqr_gui.py", line 921, in mainLoop
    if self.checkScrollArea(x,y)==True:
  File "/Users/Toeholds/Desktop/spqr/SPQR_0_3_5b/scripts/spqr_gui.py", line 528, in checkScrollArea
    elif y==(SCREEN_HEIGHT-1):
NameError: global name 'SCREEN_HEIGHT' is not defined


--

Having the graphics programmatically scaled is the way to go; I'm convinced that 60x60px icons have no uses in 2010, and part of that automatic scaling helps your team test out stuff quickly. (I still can't get over how awesome it is to be able to do plug and play.) I suspect it's more than generating the defines.py though; you'll likely need to rewrite some code.

For the map, can you generate the database with code?

Code:


def TerrainCheck(xy, mapimage):
    if(Seacolor(xy)):
        return SEA
    else:
        return LAND


First pass fills in terrain check for all hexes, second pass computes passable edges. You mentioned somewhere that the hex grid is getting decoupled from the main map.png, so I presume you have some hex dealing code around already.

Release early: Fully agreed, I'll put v3.6 up on sourceforge tomorrow night.

Will fix that bug tomorrow as well. There are various ways you can move the map:

1: Click the middle mouse button and drag.
2: Use the up/down/left/right cursor keys.
3: Click, or click and drag, on the bottom right mini-map.
4: Move the mouse to the side of the screen.

Generating the database with code is easily possible if you can generate such an image (since the boundaries of the land do not match the hex boundaries exactly. Still, it would do probably 90%+ of the work for us.