Creating a computer-aided version of WCTO

Phase 4 development begins today. I'm also happy to announce that I met with Panda for 2 hours yesterday, and he finally has the time to jump in and help with some coding.

For those that may be following along, but don't feel like scrolling back up to the very top phase 4 is about coding the game engine. Work wise, this is likely the largest section, and probably makes up between 25-40% of the actual work.

Within this section, there are 6 primary modules to be coded. There are 3 primary game engines:

1. Process Movement Orders
2. Process Combat Orders
3. Process End-Turn Orders

There are 3 secondary game engines, which pre-process the potential valid orders before each of these above phases (i.e. the 'Movement Pre-Processor' module determines what valid movements a given piece can make and ensures that the orders screen doesn't present invalid options. This will be most challenging with the weapons pre-processor, where we have to pre-validate all the possible targets).

A number of the classes still need updating as we go to add in necessary support methods or properties, so that will also add some work.

Hopefully we can release alpha versions to play with each of the three engines as they are ready.

By the end of phase 4, we should be able to fly around ships and have them shoot at each other, etc. I am not initially planning to code in any of the pilot class stuff *yet* but it may become necessary. The missile class and the environmental object class (aka flak/asteroids) are also not yet even started, and both will be necessary before this phase is done.


The movement engines should be the easiest, and I will work on them first. Panda is going to start sketching out some general support functions for ranging and line-of-sight in preperation for the combat engines.
 
One small rules change announcement for everyone: Ironduke has asked me to update all the dice rolls from a 2d6 to a 1d12. This means your odds of hitting every number are now equal; natural hits are on a 12 and natural misses are on a 1. The big difference, of course, is that there is no longer going to be a central tendency towards seven. Otherwise, I've received no other rules changes from him to be implemented in the first version.
 
Do you require a special font for this page? I just took some screen shots of various browsers, on systems with standard fonts, and these are the results. Firefox looks the best (presumably this is your starting point), but even so, the windows expand and cover some of the text.

  1. Gecko/Windows
  2. WebKit/Linux
  3. Presto/Linux
  4. KHTML/Linux
  5. Trident/Windows
Also, in this context, the correct spelling is "Fighter Complement". For your information.
 

Attachments

  • firefox.png
    firefox.png
    278.5 KB · Views: 147
  • chromium.png
    chromium.png
    338.8 KB · Views: 171
  • opera.png
    opera.png
    340 KB · Views: 152
  • konqueror.png
    konqueror.png
    351 KB · Views: 180
  • ie.png
    ie.png
    273.3 KB · Views: 153
Good catch on the typo; fixed.

These are very useful; while I'm not particularly worried about the ship entry screen being cross-platform (since its usefulness will end when all ships are in), this does give me a great baseline for how things should differ on the various platforms for the main game. You're absolutely right, in that I am using firefox as the starting point, and chrome as the second point.

As a general progress report, I've now written the core 'run_engine' which will determine if and when a processing engine is necessary, and done some restructuring in how we load in the core info. I've also produced a pair of reference arrays of all current game pieces, one mapped by coordinates, the other by id. I'm also 50% done the move_engine(). Depending on time tomorrow, I believe I can debug and finish it.
 
I'm happy to keep testing the major browser engines, if you find it helpful.

Good work on the progress, even if I don't understand all the game mechanics. (:

Edit: Do you plan on using any HTML DOCTYPE? Even HTML5 has one. It might help with cross-browser consistency without actually having to do anything explicit to cater for the various engines.
 
At some point, I'll throw in the doctype tag. At the moment, I'm far more interested in getting the game working; once that is the case, I'll slowly go over the actual html and css to see to make it as cross-browser compliant as possible.
 
I just thought it'd be worth doing from the start. Various browsers' 'quirks' mode are all different and it doesn't really break anything to add the DOCTYPE. But up to you, I suppose.
 
You're probably right, that the smart way to go forward is to build good code at each level, including at the html-level. That said, I'm not really an html guy; it is just a means to an end (I dare you to 'view source' any of it and cringe at all the missing line-breaks since it is coming out of php and I am lazy). To keep myself interested, I prefer to get the game working, and then go back and make it cross-browser compliant. That said, more people are coming on board now; Panda will be helping and I just got a PM from another coder who wants to help, so I may be able to have someone else focus more on the html itself and clean that part up.
 
Whoa, whoa! I was invited to a party yesterday, and today I'm reading all those good news about steady progress and other people joining in. Considering that I'm invited to another party today, I wonder whether the game will be completed by tomorrow... :p
Just kidding - and of course, I feel bad now, since it seems like I'm partying all the time while others do the hard work. :rolleyes: I guess I'll be more useful once we're doing some more graphics. ;)
 
Rule interpretation question (this goes out mostly to ironduke, but all of you are welcome to chime in):

Does a burnout prevent a 10 square dumb-fire missile target?
 
Okay, the 'movement engine' is complete, but un-tested. Before I can test it, I need to create the movement order submission form processor (which shouldn't be more than an hour's work) but also the movement pre-processor to generate the movement submission form on the fly (i.e. the program that will make sure the movement form only has legit options). The "good" news is, of course, that I spent a fair bit of time in phase 3 roughing in the html necessary for the movement form itself. Unfortunately, I don't have time to do more work for the next few hours, and not at all tomorrow, so this may end up waiting until early next week before more progress is made.

As soon as I have all 3 'movement phase' code blocks done, I'll look into releasing a semi-hack to let you just kick from movement phase to movement phase, so you guys can start trying it out and debugging it.


As a side note, I noticed in the phase3 demo (which now has a second ship, by the way, added into the database) that there is a few minor jquery bugs. With 2 ships on screen, when you try to open the slider, it appears to interfere and close it again right away. I suspect I just need to make the open/close slider buttons 'unique', which shouldn't be hard.
 
Avacar said:
I dare you to 'view source' any of it and cringe at all the missing line-breaks since it is coming out of php and I am lazy
Click to expand...
No need, I've already taken a peek, and Firefox's live HTML validation add-on tells me what's wrong. (: And PHP-generated code isn't so bad. But you're right, making things as best as you can make it is the way to go, at least in terms of what I've learnt from incremental, iterative development.

Anyway, looks like a game-related discussion is going on. I'll leave you folks to it. (:
 
Avacar said:
Rule interpretation question (this goes out mostly to ironduke, but all of you are welcome to chime in):

Does a burnout prevent a 10 square dumb-fire missile target?
Click to expand...
According to the rules, the answer is no. Afterburner or not, if the original course was kept (and for a burnout, that's the case), the DF will work.

Now we could debate whether this makes sense, and introduce a penalty on the TR or make it impossible altogether - but considering a target can also afterburn straight away from a ship (or straight towards it), this wouldn't affect DF effectiveness at all.
The other possibility would be to check if you're in line with the target. (Which could be performed by the same function you use for tailing later on.) Of course, I would then have to mention this separately in the 0.15 manual. ;)
 
Code wise, it is easier to simply say a burnout allows a DF fire, as long as that is the intent. That said, if you want to change the effectiveness, etc. that can be done.

For now, the movement_phase_engine() has been updated to have burnouts allow 10-square df targets.
 
Since I'm feeling somewhat guilty, I converted some more ship pics for the project... I've completed all transport vessels and bases. along with the Kamekh. Next up are capships! And of course, I have to update the ship database anytime soon... :)
 
I'm happy to announce that the project has picked up its 4th official member. Wedge009 has volunteered to help out with cleaning up the html/css and enhancing the cross-platform compatibilities, enabling me to further focus on game engine itself.
 
New Rule interpretation:

The rules put no actual limits on immelman turns. Technically speaking, a capital ship can attempt it, although it requires them to roll 13.5+ (which is actually possible with sufficient pilot bonus...) Do we want me to put in a limit which says that if you have turn rate less than 1, not to display the immelman command?
 
Looks like this project is really picking up momentum... Glad to hear it! :)
It's true that the Immelman turn isn't restricted at all - but I guess it should be restricted to fighter-class vessels. I'm not sure if a transport/corvette doing an Immelman would make sense... It certainly doesn't make sense for capships. ;)
So if it's possible, I'd hide this maneuver from any class other than fighters/bombers. If that's too much of a hassle, we can go by your proposal, but this would mean that capships with a turn rate of 1 will actually be able to try an Immelman.
 
Finished the pre-engine, although it doesn't know how to handle any of the capital-ship exceptions yet. Also fixed the pop-up expansion bug I had previously alluded to. The slide-outs now work independently for each ship. I've also implemented another database variable that tracks whether orders are in or not; the Rapier is flagged as needing to submit orders, the ferret is done. Tomorrow I'll make that order button call the movement pre-engine and generate the correct order screen.
 
You must log in or register to reply here.
Back
Top