I was thinking about this maximum number of models on board. Now, let's make an example. I can make a 1k-army of... 18-25 models I think (Iyanden), or another at 121. It is all too varied. Making a limit like that, unless ridiculously high, like 500, will get in someone's way sooner or later.
That's a whole lot more than I anticipated and after reading your post I promptly did a test with two 500-unit armies. The good news are that neither one of the clients crashed and I was able to move the units around. The bad news are that when I moved my mouse over the unit "stack" in the reserves area, things slowed down to a crawl - that's what happens when 500 flash movie clip objects try to react to a mouseover event at the same time. It took a couple of seconds for the top-most unit to become highlighted and dragging and dropping the unit was equally slow. Once the unit was on the battlefield, though, it reacted much the same way as before, with no visual lag. This is a promising result as it means 1000-unit games, at the very least, are possible. And to be fair, both test clients were running on the same computer, so the poor machine was essentially doing twice as much work as it normally would. Another positive thing to note is that if one player had a 500-unit army and the other had only four units, the player with the smaller unit count did not see any of this unit-stacking-induced graphical slow-down at his end (even though both clients load both armies).
In any case, the way I've designed the unit markers right now is not optimal as they contain code which makes updating them a pain and increases per-unit memory requirements. Initially when loading the client up (in Flash Player, not a web browser) it took about 22 megabytes of RAM, which shot up to 58 megabytes after loading 1000 units. I imagine my next short-term goal should be to move all code from the markers into a separate object within the client program which the markers query when needed. Once that is done performance might improve slightly (mostly on the memory side I reckon), but if it doesn't, I'll have to think of some other method of initial unit deployment instead of simply stacking X number of units in one spot.
On a related note, how common are four-way games with 100+ unit armies on all sides? Another issue rising from this is how the client program will handle crashes or sudden disconnections from the game. The more units there are in a game, the longer a game takes and the higher the risk of something going terribly wrong becomes. Right now all game events are stored on the server so it shouldn't be too hard to get a returning client up to speed, but obviously there's no way to tell for sure before some actual testing. Plus, if a game takes several hours it would be nice to know that you can "save" the game and come back to it later.
As for a descriptive line I am not sure. I mean "Ghosthelm, Rune of Witnessing, Witchblade, Shuriken pistol, Spiritstone, Guide and Fortune" is something like 90 characters long, whereas "Gh, RoW, Wb, SP, Ss (as oppsed to SS which is a Singing Spear by the way), Gui, Fort" is just under 30...
I tried that 90 character line and it fit within the client's description text field with a bit of space to spare, but not enough to fit the attribute string in aswell. The simple solution is to use abbreviations, but if I can somehow allocate a third line of text for the status area I'll do that. It's too early to say since not all GUI elements are in place yet and I can't be sure how much space will be left in the tool area once they're in. I'd rather not make the client any larger either, because even now it's 1100 x 850 pixels in size and thus fits barely within a browser window in 1280x960 desktop resolution.
Thanks for providing that description text!
Welcome!
I'm very intersted in giving you a hand developing this:
I am a software engineer.
I know php, html and Mysql very well. I started playing 40k in second edition, and began collection and playing again recently..
Storing the data in sql would be best, and you could use session variables in php for keeping track of who's turn it is etc...
- sk
Hi and thanks for your interest! At this stage I am mostly in need of gameplay related information such as the example unit counts and the gear description line Rasmus provided - things I have no real experience with. However, should the project not go down in flames for whatever reason I imagine MySQL knowledge will come in handy eventually (I personally know nothing about it). Right now the client stores armies and terrain in XML format, which is fine and does not need to be changed necessarely (they are very portable and anyone with the know-how can write a program to create and edit them if they want to). Chat messages, game status information and the log of game events, however, are stored as strings within text files which is far from optimal. Presently there's NO file locking in place in fact, so if two clients try update the same file at the same time bad things will happen.
Remember what I said about this being an Ork contraption? This part of the client would benefit from MySQL integration, I imagine, but until formats for each of these three items are final it's probably too early to start thinking about switching them to MySQL. Do you think it's a big job to change a PHP script which reads from and writes to a file to read from and write to a database instead?
As for PHP sessions, the client - server interaction works in a way where PHP sessions can't be used (I don't think they can, anyway - correct me if I'm wrong). The client is a Flash object embedded into a regular webpage - neither one of these are reloaded at any stage during game play, so implementing PHP sessions would not work. The web browser itself never, ever even sees the back-end PHP file - only the flash client interacts with the script stored on the web server, doing so when it wants to:
Ask for list of games
Store a new game onto the server
Change game information
Check if there are any new chat messages since last update
Get chat messages
Send chat messages
Check if there are any new game log events since last update
Get game log events
Send game log events
..plus possibly some others I can't remember right now. In any case, since I do not plan to implement any WH40k rules into the client to keep things legal, I don't think I'll need to keep track of turns; especially not the different phases of a turn, since those are rules created by GW and can't be used. We'll see.
lol, i WISH i knew how to program as i would love to work on somethnig like this. if you need plain old playtesters im up for it!
69Lazarus.
Thanks for the offer, Lazarus. Right now there is nothing to test and I don't want to get people's hopes up unnecessarely. If nothing ever comes from this, I'd hate for people to lose their sleep and will to live (so to say). I didn't bring the client up sooner than I did for the reason that I didn't even know myself if I could do it. When it started to look like things worked the way they should (I was able to move units around, hide them, reveal them, send LOS data, use the chat, etc) I figured that it was time to get discussion underway and find out which things I had not even considered yet.
I don't like to make promises I can't keep, so I can't promise that anything will ever come of this project. At this point I simply needed to open a dialog with people who actually play the game and can point out things which the client HAS to be able to do for it to be useful for its intended purpose. IF, however, things go forward as planned playtesting WILL be required and at that point you're more than welcome to lend a hand.
Whatever happens to the project, I'll make sure to post about it in this thread.