Creating a computer-aided version of WCTO

Avacar

Vice Admiral
We should probably split off into a new thread for this, but i'll start here anyway.

What is stopping (aside from coding time) implementing this on the web? I know right now you appear to be using flash, but based on the turn-wise updating, couldn't this be done with a combination of javascript and php with a database? I would highly recommend jquery in that case (a repackaging of javascript into a way more intuitive and faster to use version targetted mostly at things like controls, menus, mouseovers, etc. as well as on-the-fly updating from a php script as is done with AJAX). Some clever use of css, jquery, with a php core to do the game computations and a mysql database to store games, moves, etc, and you'd be set! With proper object-orientation, it wouldn't be too hard to then add in new game features, without too much extra work, and all the 'rules' would be hardcoded in. Of course, you'd also need some sort of player interface, but at least then things like pilot stats could be auto-tracked.

Do you need help with it? I'm sure f you asked the community, a lot of people would have the necessary skills and offer to help you code it up. Hell, I would do it, but I wouldn't have time for that kind of side project until mid-july.
 
We should probably split off into a new thread for this, but i'll start here anyway.
Moved this to a new thread...

What is stopping (aside from coding time) implementing this on the web? I know right now you appear to be using flash, but based on the turn-wise updating, couldn't this be done with a combination of javascript and php with a database? I would highly recommend jquery in that case (a repackaging of javascript into a way more intuitive and faster to use version targetted mostly at things like controls, menus, mouseovers, etc. as well as on-the-fly updating from a php script as is done with AJAX). Some clever use of css, jquery, with a php core to do the game computations and a mysql database to store games, moves, etc, and you'd be set! With proper object-orientation, it wouldn't be too hard to then add in new game features, without too much extra work, and all the 'rules' would be hardcoded in. Of course, you'd also need some sort of player interface, but at least then things like pilot stats could be auto-tracked.
Yes, I'm using Flash right now. It's the simplest way for me to get the graphics the way I want them to look like. And your proposal would indeed work - that's pretty much how my friend ran his "Crimson Skies" game. However, apart from Java (or JavaScript), I don't have a clue how to code this stuff. (Mind that "having a clue" doesn't mean I can program properly. :p)
Maybe I can ask my friend if he can share his old source code, so someone who's more proficient than me at programming could have a look.

Do you need help with it? I'm sure f you asked the community, a lot of people would have the necessary skills and offer to help you code it up. Hell, I would do it, but I wouldn't have time for that kind of side project until mid-july.
That's the main problem: I don't doubt there are a lot of people here who would have the skills required for this kind of job. But do they have the time? So far, there were two people trying to make a computer-aided (or even stand-alone) version of WCTO - I've never heard again from both. ;)

Seriously, I'd gladly wait until mid-July if you could pull it off. If anyone else wants to jump in, you're more than welcome! Just don't expect me to be of much help when it comes down to programming... :(
 
I know Panda in person outside these forums and spoke with him about it. He's interested in helping. We both have the requisite skillset, well more or less. I don't want to get your hopes up until july does actually roll around and I find the time to start, but should I start, I can promise I'd at least see it through. We'll need access to an appropriate server; I have some personal ones we could use, but something more community-run would perhaps make more sense (I don't know if your fleet-commander.net system has php or mysql, but that's what we'd need, server-side).

Also, when the time comes, I can provide access to a coding repository (SVN) so that if anyone else wants to work on it with us from the community, they can.

I'm going to use this space to roughly sketch out what I've thought about so far, and see what other people think about how to structure the source. We certainly want to make this object-oriented, and store most of the object data in the database. Please note that while I do coding, I tend to not use proper pseudo-code or break things down in a way that professional programmers would, so bear with me.

The system will be storing two different types of data in the database itself: meta game data like what the stats are for a given ship or weapon, and then game-specific data, such as where what ship instances are located, orientation, etc. I will try to refer to things that are overall stats as 'playing pieces' in the database (aka what is a Rapier) and 'game pieces' (how badly damaged is the rapier piloted by Avacar in game X?) The latter is a 'game piece' the former is a 'playing piece', the 'template' if you will.

We need a top-level class, maybe called 'piece' or 'indicator' that would have map-related features to it. For instance it would track:
-x-y coordinates of the 'indicator' on the map
-orientation within the hex of the piece of the map
-velocity of the object (note, I don't think we need acceleration here, because only ships have that thus far)
-basic methods for moving the piece around the map, including smart checks for map-edges (i.e. indicator->move(2,1) for 'move 2, turn right 1' as a move order and have it update x-y appropriately)
-a reference to a transparent .png file set for various orientations of the piece (or maybe just 1 and use the php draw libraries to rotate it; gotta think on that)
-an 'explosion' method which determines what happens when the indicator is destroyed
-a reference to a transparent .png file for the explosion picture
-some amount of 'volatility' (aka when it goes boom, does it take anything with it, and in what radius; default for all our current indicators=0, but this could be useful down the road for things like the mace)
-a default target roll (TR)

There would be at least 3 classes that inherit from the indicator class, they would be:
-ship
-missile
-environmental_object (aka asteroids)

We also need 2 more classes, which does not inherit from 'indicator' which is:
-weapon
-pilot

The ship class would need *at least* the following properties:
-all the ship stats (including acceleration, current/max hull and shield, shield regen rate, note that all indicators have a TR, so this was inheritedetc.)
-an array of weapons on the ship (note that in the database of playing pieces, it would have to store the weapons AND their orientation w.r.t. the ship 'forward' direction. The weapon class' constructor would take in weapon names and orientations, but once this was done, orientation data is stored on the weapon object)
list of each weapon on a given ship class
-a 'constructor' method which would, knowing what type of ship it is supposed to be, pull the base stats out of the database of possible pieces
-a reference to which pilot object is flying it
-counters for chaff pods and afterburners (max values and defaults set by constructor)
-a number of methods for special movement a normal indicator can't do (banking, all the afterburner related moves, all the pilot-skill related moves)

The 'missile' class needs:
-damage done on hit
-a calculation against chaff pods/hit avoidance
-health? (just put hp=1 so they can be shot down by point defence?)
-a 'death' timer (aka after X turns, you just vanish)
-an intended target (blank when not applicable)

Note carefully: 'missiles' are the things we see on the map itself, whereas 'weapons' are a ship component that fires missiles. The rules for things like heat-seeker, df, etc. are all stored in the weapon, done when you try to fire the weapon at a valid target. The 'missile' itself just knows who it is going after and how long it sticks around.


The weapon class needs:
-damage, range, orientation vs. ship, firing arc width, refires
-a method for determining if a target is in range of a weapon (aka rapier->weapon[0]->range(Panda) to see if my #0 particle cannon can hit him drivers can hit panda)
-a method for firing the weapon at a target (same as range, but does damage.. hmm, maybe we can just merge them, and have it return the damage and the range, and if you happen to fire at something way out of range..well you're stupid)
-targetting requirements (if you're firing a missile)
-a field which says 'I'm a missle launcher' to toggle on special firing requirements
-a field which references which missle-indicator 'playing piece' needs to be spawned as a game piece if successfully launched


Note that down-the-line, if component damage is better fleshed out, then we would likely introduce a top-level 'component' class, of which 'weapon' is a sub-class, and the ship would
have an array of standard components, not just weapons. In this case, we would want to
also add a few lookup methods to the ship class, that can find one of its components based
on a keyword 'aka rapier->lookup(particle cannon)' to have it return a reference to both
particle cannons, which could be items like 13 and 14 on a list of 'ship->components[]' which
was populated by the server's database of playing pieces.

Okay, on top of this, clearly we have a 'game' class which doesn't have any 'playing pieces' to be stored in the datatabase, but instead only 'game pieces' per se (okay this terminology is getting cumbersome since the game itself isn't a piece, but whatever). The 'game' would store things like:
-all pilots
-all current indicators
-current turn
-eliminated indicators
-grid size
-background image
-"slow player" countdown timer value (auto-kick-from-game system anyone?)
-current turn number
-current phase number
-human readable game name
-unique game indicator (likely integer)
-methods for reading/storing the game data from the database. note that this would involve
creating and loading all the ships from the 'playing pieces' info, and then updating them based on stored 'game'-class info to their current 'game piece' data. I am not sure what's best here, to store all the changes in the 'game' class, or to separately store a whole table full of actual incremental ship updates. Certainly no reason to re-store 90% of the ship/indicator data on a per-turn basis; only really orientation, position, health and consumables are necessary)

Each 'game' instance would be stored in the database, meaning each turn would have
a database entry with all the above info, possibly with references to a side table for the game-specific piece data (note that for everything discussed so far, I'm talking about the php end of things, and not at all what the mysql tables look like, for the most part. They would obviously have cross-references all over the place, so a ship 'game piece' knows what 'game turn' entry it is associated with, if we store the data that way).


Okay things I haven't covered here but could have:
-pilot classes

Things I haven't covered here that aren't directly related to the core classes:
-the entire UI (player mode, game administrator mode, add-new-'playing piece' mode to do the initial setup of the server as Ironduke adds new rulesets or features)
-player login/authentication system
-handling players in multiple games, players controlling multiple ships in a given game
-I did not point out where much of the game code resolution takes place, how it handles turn
calculation etc. (much of the actual combat code I think ends up on the 'weapon' methods, but that's up for debate)
 
You have that very well thought out, I'm impressed.

Just a few details:
Missiles:
- I think we'll need a reacquire target method, but that will probably be just a special method for FF only, not for the whole class (or just make an acquire method and call it again from somewhere, e.g. at the beginning of a turn or when the vanish counter drops)
- and then there are special targeting rules for DF (either range 2 or range 10 if the target hasn't changed its heading), so the ship class will maybe need to have an attribute to store the last turn's movement as well as the current

weapons:
- just because of the missile launchers, I wouldn't merge the range and damage methods (or we still can, and let it deal 0 dmg, but that might be an extra hassle in terms database handling)

I hope that is all... Anyway, you did a really good job, and I hope everything turns out great. ;-)
 
Wow, it's definitely great to see you're putting in so much thought into this already!

Some remarks from my humble self: ChrisReid and KrisV already mentioned it wouldn't be a problem for us to get WCTO hosted on SolSector.net - which should solve all our problems as far as a server is concerned. (My fleet-commander.net website doesn't support PHP or MySQL anyway...)

I see ship movement as one of the more intricate mechanics in this project - basic movement is fine, but then you have to consider not only banking (if possible at all for a given ship -> means we'd have to classify ships into at least "fighters/bombers," "transports/corvettes," "capships" and perhaps "bases"). Not to speak of all the special maneuvers that can enhance or override your regular movement. It's not the rules that worry me so much, but all the exceptions to these rules. ;)

Orientation of ships shouldn't be a problem, though - I'm currently using transparent .png "sprites" and rotate them by 60°. I think it's just a matter of "<ship>._rotate += 60" in Java if you want to turn 1 to starboard, for example.

Player login and authentication should be the least of our problems here... ;)
 
Yeah, I decided I was already going into enough detail as it was, but you're correct. We might want a 'ship' class that does have a few sub-classes. Certain ship movement is determined by your stats, but then there are some exceptions, like banking. The special shields on cap+ ships make it interesting too.

For things though like 'bases', I think anything cap-ship related is also base related, just with 0 max velocity? I'm not sure if a corvette special class is necessary at all, or if they can just fit in with the capship class, but with some kind of toggle for shield type? Definitely things to think about.

Certainly things like sheldon-slide or burnout, etc. all all their own movement functions, and only present on the fighter/bomber class, and would return failures with insufficient turnrate/etc.

I suppose we could consider a 'movement' class that determines how every move works, and then have an array of possible move functions added to a given ship; maybe that's the way to avoid too much class splitting?
 
Okay guys, I'm back. I'm going to make an attempt at doing this. I am fairly certain Panda is behind me on this.

Does anyone else out there want to help out? Skills in any of the following languages would be helpful:
PHP
HTML
mySQL
CSS
Javascript (jquery)

Or more specifically we will need:
-layout artists
-interface creators
-game engine coders
-database designers (access/data structure/etc.)

We hope to use PHP as the core backend, storing data in a mySQL database, and using a combination of html/css/php and jquery to produce 'AJAX-like' responsiveness for the front-end that most game-players would see. I say 'AJAX-like' because honestly, front ends are not my forte, but at the moment, I seem to be the most likely candidate to code that side of things, so it may be less responsive at first than we like as we learn. (I am more confident that people can pick up the php and code the game backend with less learning than the internet side of it).

Those are just my recommended skillset groups; honestly if you label yourself differently, or are profficient in any/all/combinations of these, we'd love to have you on the team.

We'll be using a SVN server as a code repository, run off one of my personal machines.

Ironduke: we're going to need you to get us that php/mysql capable server access now. If you could start the ball rolling as we hopefully form a team, that would be great. If not, I have a server I can use to do the development on.
 
I'll post some progress reports as I go here. At the moment my plan is as follows:

Phase 1: Establish a working, static html/css board which successfully overlays the grid on a background, and puts ships in grid cells. Being static, I expect a hardcoded change is necessary to move the ship to a different cell. I also need to work out how ships that are larger than cells will work (since images typically aren't positioned based on their center), and how to handle multiple ships in the same cell.

Phase 2: Generate database format, and take apart the CSS/html, causing it to be formed using php. Create a 'test' game in the database, which successfully repositions the same ships when viewed. (While present, don't yet worry about users, validation, etc.)

Phase 3: Insert in a jquery (javascript) layer which adds in things like the mouse-over info (possibly retrieved using Ajax and php, or perhaps just pre-loaded and hidden. Ajax-style coding is new to me, but I want to try it out on this project to speed it up and also to learn)

Phase 4: Develop the ship order database storage format, and code the game engine to process the orders correctly.

Phase 5: Add one final layer to the system, including 'games' 'turns' and 'users' such that the system can keep track of who is playing in which game, and knows to run the turn order processor when a given game's "we're waiting on X players" counter empties out.


Phase 6: Populate object database with the ship/environmental/missile templates.

Phase 7: Test and add new features per request.

I welcome help at any phase, if you feel this is something you want to learn or can help with.

I hope to complete phase 1 this week, hopefully very quickly.
 
Phase 1a is complete.

I'm adding a second part to phase 1, where I get the php to move ships around, without worrying about the database yet, nor the game engine.

The key thing shown here, is that we have determined how I'll layer the css and the html, what is a child to what, tag wise, and how I'll move ships around. While this static version can't move ships without a hard code change, *where* to put that hardcode change is obvious.

The next step, I'll put in the hex-coordinates to pixel-position math, and a form to let us control them. Additionally, I may mess with some simple jquery. finally, I'll start playing with the php GD library that lets us rotate the image on-the-fly, and see if we want to do that, or simply store 6 orientations for each ship.

I haven't decided the best way to address if 2 ships are on the same square yet.
 
finally, I'll start playing with the php GD library that lets us rotate the image on-the-fly, and see if we want to do that, or simply store 6 orientations for each ship.
I'd prefer rotating, simply because you have more control over the game and less data to store. However, I admit I don't have a clue how difficult this is in php... (E.g. for Flash's ActionScript, it's adding a mere "<ship>._rotate = 60".)

I haven't decided the best way to address if 2 ships are on the same square yet.
This is actually one of the biggest problems I've had with the game... Especially when there are more than two ships involved. So far, I haven't come up with an elegant solution to this issue. I mean, you could always display the biggest ship (or a smaller ship on top of a bigger one) in a hex and let players click on a "stacked" icon or something to show a pop-up list of all ships in that specific hex. However, I don't particularly like that idea, as it's inflating the GUI. It might also confuse players when their ship doesn't appear on the map at first glance.

Looking forward to your progress - keep up the good work! :)
 
Well.. one possibility is that (since with user-inputted commands we'll need user logins and accounts and such) I could dynamically make the user's ship(s) always be on top of stacks...
 
Phase 1b is complete

You can now have fun moving ships around and rotating them. I originally tried to do on-the-fly image manipulation, but based on my current skills, and/or laziness, it was going to start dumping new images for every ship/turn. Since there are only 6 discrete positions they can be in anyway, there would have been a lot of repetition and bloat. I've opted for just creating/storing the 6 sprites per object necessary.

I'll start phase 2 either tonight or tomorrow, depending on time. This will take longer; I'll be putting into place all the base classes (originally sketched out above), and the database itself. It still won't actually 'play' though.

Have fun with Phase1b.

edit: Oh, and yes, the Rapier in angle 1 sticks its nose out a bit. I haven't taken the time to make sure that the center of every image is the center of the vehicle; that kind of cleanup is low priority at the moment (any volunteers?).
 
Well.. one possibility is that (since with user-inputted commands we'll need user logins and accounts and such) I could dynamically make the user's ship(s) always be on top of stacks...
Excellent! I hadn't thought of this possibility, but you're right. At least it'll work if each player/account only controls one ship (which should be enough for starters...).

Don't worry about manually rotating all the ship images - I'll gladly help you out and send you the necessary files via email!
 
About 50% of the way through phase 2. I have roughed in most of the classes in php, and have also created 50% of the database tables. I've also worked out some priliminary member functions for the classes (for instance, indicators can move around and turn, and the extended 'ship' class can already bank and afterburn) although I've done 0 testing/debugging yet so there could be errors. I've thought a fair bit more how the actual program will flow, but to reach the Phase 2 objective, I need to be able to re-create the images from Phase 1, even if they are static, using database-driven information. It still won't be user controllable; likely less-so than Phase1b was, but it will be orders of magnitude more sophisticated under the hood.
 
Don't have much free time on my hands right now, but I at least finished the Drakhri and Rapier II top-down shots, which completes the light and medium fighter sets. Next up: Heavies and bombers... :)
 
I haven't reported in for a few days, so an update to "all" the readers out there.

Phase 2 is almost finished. While I'm not actually splitting the phase 2 up, I did just hit a nice debug point which shows off where I am. As such, please go take a look at the phase 2 early demo. While this may look a lot like phase 1, there are some key differences.
  1. The Rapier is drawing all its stats (which are present, but not yet displayable) from database info.
  2. While not all the methods are in place, all the classes described above have been fully outlined and prototyped. They are in use to produce these shots.

To further iterate my point, see if you can figure out what is going on with the ship (this is 1 ship moving a lot with images dumped as it does, so not typical gameplay, but it is based on legal ship movement.)

If you can't figure it out, check out this code (which shows off what Phase 2 is all about):
Code:
$avacar = new ship("Rapier II", -1);
$avacar->x = 1;
$avacar->y = 9;
$avacar->speed = 4;
$output.=$avacar->generate_display_html();
$avacar->move(3,0);
$output.= $avacar->generate_display_html();
$avacar->move(5,2);
$output.= $avacar->generate_display_html();
$avacar->move(2,1);
$output.= $avacar->generate_display_html();
$avacar->move(3, 2);
$output.= $avacar->generate_display_html();
$avacar->bank('left');
$output.= $avacar->generate_display_html();
$avacar->move(5, 3);
$output.= $avacar->generate_display_html();

edit: for those who have played WCTO, recognize that the code above isn't checking for 100% valid movements yet; hence 'bank' is using a speed of 4, but the 'move()' function takes in *any* distance, irrespective of current movement speed, or acceleration abilities. These sort of things will actually get checked at order-writing level, not at game-function level. (i.e. I plan to do careful checks of submitted orders to ensure ship stats are maintained) /edit

I'm just doing the finishing touches on phase 2, which is putting in a fake 'game' into the database, and having the single rapier show up in its phase 1 turn 1 position. At this point, it should be a piece of cake, and then we can move on to phase 2.

Please note that I am trying to get the working game code out as fast as possible, so while Ironduke is doing great work with graphics, I haven't actually put any ships other than the rapier in the database yet. I'll probably take a short break from pure engine coding between phases 2 and 3 to code up some tools to let 'volunteers' insert ship data into the database templates.

edit2: Another note: the page linked above is calling functions and classes I am doing active maintenance upon. While I won't change phase2.php anymore, it calls files I am updating. If it doesn't work, don't panic, I'm likely working as you refresh on something potentially related.
 
Phase 2 is now Complete.

At first glance, it looks a lot like the original Ironduke WCTO website. This is because I 'borrowed' all his html; down the road, based on any user suggestions, I can improve that part of the interface.

There is only 1 game, 1 turn and 1 phase being displayed. Nothing else is in the database right now, but I may in the next 24hrs through a few more fake turns/phases in.

For interest sake, I've done a dump on the rapier object displayed at the bottom of the page, so you guys can get a feel for some of the inner-workings.

Everything you see there, however, is completely dynamic. It is all read from the databases; unlike the snapshot I showed you earlier of me using move() directly, this is pure game-data driven.

That said, we still have a *long* way to go. The interface itself needs to be designed. I haven't designed the 'orders' database yet. The entire core game engine (3 parts: movement, combat, and evasive actions) still has to be built... but we're making progress!

I'll probably take a couple days as a break. If anyone wants me to demo something in particular for fun, just post here. I could move the rapier around, or take some time to input another ship type.
 
Looks good! I'm really impressed by the amount of progress you've already made. Making this work definitely takes a lot more than meets the eye...
I'd be happy to help you complete any database entries of ship stats. Maybe we could make this viewable to the public, so people can spot stat typos more easily...?

In case you're bored (haha), you could implement some form of basic movement orders (like checkboxes for port, straight and starboard and a textfield for inputting the speed along with an "Execute" button) to allow people to play around with the ship. :)
 
I'm not quite ready to do that. Based on the way it is coded, it is currently more work to let them move it around than it is for me to push through and do Phase 3, and THEN let them toy with it. (The type of interactive ajax control that I'll be developing for phase 3 is much more suited for some 'fly it around' fun).
 
Back
Top