Has anyone thought about a turn-based strategy in PHP? Each player gets a number of turns each day (get resources, build stuff, move units, attack). The object is to conquer the map or something, and the map is like an RTS (fog of war and all). Maybe RPG elements could be added too (like in Might & Magic) - player could have a few unique character units he trains and controls armies with. Each game takes between a week to a whole month. Once the winner is found, the map recycles and next game starts. Besides the usual stuff, players would also be: - exploring map (maybe a maze/labyrinth?) - collecting unique items (relics from "ancient city", teleportation warp-gate, magic weapons, etc) - helping friends (building defense wall, sharing resources, technologies, map intel) - going on quests (retrieve/deliver item, defeat creature, save town, explore place, send tributes, etc) A usual game would go like this: - first few days players build up economy/infrastructure and tech - next few days players send out forces to explore map and secure new resources - some small battles, players also start making alliances - players go on quests, start new towns, build defenses, develop armies, train "hero" characters - armies fully developed by now, most quests done, so major battles start, empires begin to crumble - remaining alliances break, last players fight it out to the end - winner is put into the "hall of fame", next game starts That's about all I can think of right now... is there anything like that already?

Check out Utopia. I'd get the link for you but I can't get to that particular site because I'm on a school computer.

I briefed through their site. One question: is Utopia graphical?



This is the GUI-format I was thinking (a lot simpler, though):

sure, it can be done
the only problem would be bandwith as soon as you get quite a few users.

edit: first post :-)

Why is bandwidth a problem? Not anymore than any other browser-based game... or at least any website with graphics.

For the GUI, all it would need to show is:

5-10 Resources (with graphics)
5x5 - 9x9 Tile Grid (not isometric/diagonal, each tile is an element of a table)
5-10 Buttons

The Resources, Buttons, and most of the Tiles would be the same, so they wouldn't need to be reloaded each time a user does something.

Also check out Quantum star SE. Sounds very similar.

Quote:

Original post by polyfrag Why is bandwidth a problem? Not anymore than any other browser-based game... or at least any website with graphics.

Any web server that gets a lot of requests is going to accumulate bandwidth quickly. Say you have just four users connected to the game. But each time one of those users executes a command on the interface it's going to send a request back to the server, which is going to use processor time, and then the amount of data sent back to the client (i.e. the webpage with all new updated graphics, etc.). And trust me even with only a few players connected the amount of requests and responses to and from the server is going to get pretty high. That's just my own practical knowledge though. You might ask someone more knowledgable about web servers and the like if you want a more complete answer.

Quantum Star SE looks great. I was thinking of making a similar system based on a simpler text-based game, but I see there's this already.

But it's still not the idea I had in mind for this TBS/RPG.




So I guess this is something unique I came up with? I'm going to work on it this weekend, if that's the case.

Quote:

Any web server that gets a lot of requests is going to accumulate bandwidth quickly. Say you have just four users connected to the game. But each time one of those users executes a command on the interface it's going to send a request back to the server, which is going to use processor time, and then the amount of data sent back to the client (i.e. the webpage with all new updated graphics, etc.). And trust me even with only a few players connected the amount of requests and responses to and from the server is going to get pretty high. That's just my own practical knowledge though. You might ask someone more knowledgable about web servers and the like if you want a more complete answer.

Oh, I see the problem here. You see, for the idea I had in mind, the graphics would never need to be regenerated by PHP.

For example, say there's a set of icons (grass terrain, one for a castle, one for a farm, a wall, a hero unit, etc).

Each time the map needs to be drawn, an HTML table is generated. For each cell/element in that table, the background-image is set to the terrain, and on top of that background is put the building or unit icon (probably a GIF with transparencies to blend in to the terrain).

Each time an action needs to be carried out, or when unit/structure/item/whatever needs to be selected, the user clicks on one of these tiles/cells/icons.

The actual table would have dimensions of 5x5 to 9x9, and the player would "scroll" by use of Up/Down and Left/Right arrow buttons (to reload the table).

The mini-map would be presented in a similar way, without the need to regenerate graphics, but you get the idea.


I think this idea has a lot of potential. The amount of content that can be added is considerable, because ideas can be taken from RPG's (items, quests, characters) and RTS's (units, buildings, techs), combined to make a grand chess-like world.

Players would check the game each day, to see what their friends did, how their empire is doing, and make interesting choices (where to go, what buildings to make, what units to create, what research, attack, train characters/pick skills, quests, collecting, etc).

Each game would be a new experience - new map/maze, new characters to try, new strategies to experiment with new items to discover, new quests to do...

I think this is really good. What do you think?

Hey what's up peeps.

Here's a screenshot from what I have so far. It demonstrates the HTML-table GUI I was describing.

Yes it can certainly be done.

You might want to consider, rather than creating your own scrolling system, use the browser's scroll bars.

Using a table is definitely not a good way of doing it - much better to use absolutely positioned elements. You'll have fewer problems, and it will render faster.

I made (partially) a turn-based strategy game in PHP. It only had a small graphical element - a sort of "location map", which was a single large image, with various icons placed over it - all done on the client-side.

A placed icons on the map using absolutely positioned elements - this worked fine.

Mark