WitP 2 (Full Version)

All Forums >> [Current Games From Matrix.] >> [World War II] >> War In The Pacific - Struggle Against Japan 1941 - 1945



Message

Oznoyng -> WitP 2 (9/3/2005 6:50:54 PM)

I've been pondering writing a WitP-like game for some time and wondered what the level of interest would be from current WitP players. A few details:

1. The game would be web-based to allow for simultaneous order entry and team play. There would be a monthly fee (probably $10-$15) for each player to play and an initial purchase price probably around $50. Price may vary depending upon campaigns played.
2. Campaign games would be played upon a map measuring 1080 hexes by 667 hexes. The map would be a mercator projection covering the world from 75 degrees north latitude to 60 degrees south longitude. Scale at the equator would be 20 nautical miles per hex and 5 or 6 miles per hex at 75 degrees north.
3. Time scale of the game would be one day turns. No plans exist for either longer or shorter periods.
4. I hope to eventually have the following campaign games (largely dependent upon volunteer scenario/campaign designers)
a. From the Beginning - September 1939 to whenever you want it to end
b. Rising Sun - December 1939 to whenever you want it to end
c. War Plan Orange - Duh...
d. Additional post-1941 start dates, roughly year by year. (last priority)
5. The game would make it possible to create and play scenarios like Midway, Guadalcanal, the Marianas, War in the Med, North Atlantic u-boat hunting, Barbarossa, etc. on a subset of the map.
6. Team based play would be facilitated by a hierarchical command structure, with each team's players assigned commands and subordinate commands which only they would control.
7. The game would have detail settings for Research, Production, Supply, and Transportation and could be player controlled or computer controlled.
8. The game would include notes and reminders tagged to game dates, units, and facilities.

What questions do you have and are you interested in such a game?



Captain Cruft -> RE: WitP 2 (9/3/2005 6:56:50 PM)

Awesome. It sounds more like War in the World though :) I honestly think the wargame world is crying out for something like this.

Does web-based mean browser based? Or would you use Java and/or Flash clients? Or even UML/Mozilla or .NET and all that new-fangled stuff that I don't know much about?



Oznoyng -> RE: WitP 2 (9/3/2005 7:05:54 PM)

quote:

ORIGINAL: Captain Cruft

Awesome. It sounds more like War in the World though :) I honestly think the wargame world is crying out for something like this.

Does web-based mean browser based? Or would you use Java and/or Flash clients? Or even UML/Mozilla or .NET and all that new-fangled stuff that I don't know much about?


Yes, it means browser based, but with a variety of tools used including but not limited to Java, Javascript, SQL, C/C++, etc. The map data, for instance, will be distilled into .bmp's and basic hex data by feeding USGS survey information into a C program. I've programmed in probably 15 computer languages, and several of them are uniquely suited to solving some problem or other. I would use the one that solved each problem best, though the bulk of it would probably be in Java, javascript, SQL, and some of those new fangled technologies you mentioned.



Big B -> RE: WitP 2 (9/3/2005 7:12:35 PM)

I believe jwilkerson(I hope I spelled that correctly) is already preparing a team to do just that. You may try to contact him.
There is a thread a couple of months back called UWitP (Uber WitP) to find the details.

B



Captain Cruft -> RE: WitP 2 (9/3/2005 7:20:23 PM)

OK cool.

Now let's wait for the complaints about being subscription-based to start ... ;)

One thing that always worried me about doing something like this was how to account for "inactive players" i.e. players not doing their turns promptly. Do you just run the turn daily at X hour regardless? Or do you try and incorporate some sort of flexibility e.g. a 3 day deadline or something? I don't have any good answers but one idea I did have was the concept of player delegation. If someone knows they are going to be away for a time then they can pass the "baton" for their role to someone else for that period.

Incidentally, there is an existing example of this sort of thing already in existence. It's called WWII Openwar and can be found at www.wwiiopenwar.co.uk. This is on a much larger hex scale though, with each turn lasting month in both real and game time. Plus the actual turns are resolved completely manually! Ouch.

Lastly, will be there be some sort of an AI player to cover the gaps in the command structure? If so I would guess that will be the hardest part to do. Obviously there will have be a "tactical AI" to resolve the turns but that's much easier.



Captain Cruft -> RE: WitP 2 (9/3/2005 7:22:00 PM)

quote:

ORIGINAL: Big B

I believe jwilkerson(I hope I spelled that correctly) is already preparing a team to do just that. You may try to contact him.
There is a thread a couple of months back called UWitP (Uber WitP) to find the details.

B


AFAIK that project is not "fully asynchronous multi-player" like this. I might be wrong though ...

Edit: I checked out the "Uber WitP" thread. It is just vague discussion, with the possibility of an open source project mentioned. Nothing about the actual nature of the proposed beast one way or the other. Personally, although I am an open source fan, I doubt that it is the best model for making something like this anyway. It is good for horizontal applications and core services e.g. operating systems, web servers etc. Vertical apps need the prospect of money at the end IMHO :)



Oleg Mastruko -> RE: WitP 2 (9/3/2005 7:29:22 PM)

I am OK with subscription. In fact that is the best and most fair market model I can think of - perhaps because in real life I am editor of the magazine and we LOVE our subscribing readers much more than those who buy the copy on the newsstand (we love them too, but subscriptions are the way to go... [;)] )

What I am not very delighted with is the web based application. Those I don't like.

O.



Oznoyng -> RE: WitP 2 (9/3/2005 7:37:01 PM)

I have no desire to duplicate effort. If jwilkerson has a team up and running, and he is serious about it, more power to him.

As for subscription based or not? As I see it, many of the problems with WitP would be far easier to fix with a web based game, and would be far more likely to *be fixed* if there was a continuing revenue stream associated with it.

I see lots of interest in team based play, but unless the team can work on a turn simultaneously, it will not be of uinterest to many. With respect to the waiting for a person to do their turn thing, I see three things resolving that problem. First, each player would vote "Done" each turn. When all players vote "Done", the turn is processed. Second, I envision having a Supreme commander that can reassign units, issue orders, and vote done on behalf of his subordinates. Third, orders will be timed and linked. You can have an order sequence for a TF that says,

Order 1: On 41.12.13, Sail to SF
Order 2: When order 1 completed, refuel TF with 1200 tons of fuel oil
Order 3: When order 1 completed, Detach DD Sims
Order 4: When order 2 completed, load 811th EAB
Order 5: When order 4 completed, Sail to middle of nowhere
Order 6: When order 5 completed, Sail to Suva
Order 7: When order 6 completed, unload 811th EAB.

In other words, way points on steriods. Given that, a player nto entering their turn may not be the tragedy it could be in WitP.



Tankerace -> RE: WitP 2 (9/3/2005 7:39:04 PM)

quote:

c. War Plan Orange - Duh...


I'm in [:D]



Captain Cruft -> RE: WitP 2 (9/3/2005 7:43:35 PM)

Ah I see. Voting is a nice idea. It causes no end of problems on FPS servers though. Whether that would be relevant here I'm not sure. Since the audience would largely not be silly egotistical teenage males we can hope not :)

Order "strings" are an absolute necessity, and would ameliorate the absent player problem somewhat. How about full scripting capability? There are N embeddable languages about these days.



Oleg Mastruko -> RE: WitP 2 (9/3/2005 7:43:52 PM)

quote:

ORIGINAL: Oznoyng
As for subscription based or not? As I see it, many of the problems with WitP would be far easier to fix with a web based game, and would be far more likely to *be fixed* if there was a continuing revenue stream associated with it.


I agree subscription based services (and that includes games) are easier to maintain, but why do you put equation sign between "subscription" and "web based"?

There are non-web-based games, that are implemented as standalone applications on client computer, that use subscription as market model. Name any MMORPG, like insanely successful World of Warcraft for example.... (I hate that game, but at least 3-4 of my buddies are WoW junkies).

O.



Captain Cruft -> RE: WitP 2 (9/3/2005 7:46:47 PM)

quote:

ORIGINAL: Oznoyng
As for subscription based or not? As I see it, many of the problems with WitP would be far easier to fix with a web based game, and would be far more likely to *be fixed* if there was a continuing revenue stream associated with it.


I totally agree with you but I get the distinct impression that most of the potential customers don't see it that way.



Captain Cruft -> RE: WitP 2 (9/3/2005 7:51:40 PM)

IMHO the existing WitP order entry interface is very web-like. Lots of "Back" buttons ... I dare say someone who knew Javascript could knock something similar up in very short order.

What is more difficult is the "combat movie".

--
There are numerous advantages to web apps. The main one is deployment. Players don't have to do anything to play except login and then "just click". No downloads, no messing around with folders and config files etc. Code and data changes only need to applied in one place, and this can be done "on the fly". No more re-starting to pick up OOB changes ... That alone should be enough to convince anyone :)





Oznoyng -> RE: WitP 2 (9/3/2005 8:33:31 PM)


quote:

ORIGINAL: Oleg Mastruko

quote:

ORIGINAL: Oznoyng
As for subscription based or not? As I see it, many of the problems with WitP would be far easier to fix with a web based game, and would be far more likely to *be fixed* if there was a continuing revenue stream associated with it.


I agree subscription based services (and that includes games) are easier to maintain, but why do you put equation sign between "subscription" and "web based"?

There are non-web-based games, that are implemented as standalone applications on client computer, that use subscription as market model. Name any MMORPG, like insanely successful World of Warcraft for example.... (I hate that game, but at least 3-4 of my buddies are WoW junkies).

O.


Whether an executable exists or the app runs out of the browser, the game will use the web to get data back and forth between the client app and the servers. MMORPG's are web based in my nomenclature because if the web is down, or the servers are down, you can't play them. I intend for the client technology to be a mix of Java, Javascript, HTML, and XML. I could also make it VB or C/C++, but the portability for Unix is a plus for me.



Oleg Mastruko -> RE: WitP 2 (9/3/2005 8:43:35 PM)

Ah OK then.... in my book "web based" means something that is used thru the web browser as interface (clunky when games are in question). If you mean "as web based as World of Warcraft" in sense that its played over the Internet, and unusable without central server, but it has nothing to do with browser as such then this design sounds very promising.

The only question is how much time you're willing to invest and do you plan to get Very Rich (tm), Just Rich (tm) or Bankrupt (tm) after the project [:D]

O.



witpqs -> RE: WitP 2 (9/3/2005 8:58:59 PM)

quote:

ORIGINAL: Oznoyng

2. Campaign games would be played upon a map measuring 1080 hexes by 667 hexes. The map would be a mercator projection covering the world from 75 degrees north latitude to 60 degrees south longitude. Scale at the equator would be 20 nautical miles per hex and 5 or 6 miles per hex at 75 degrees north.


If you're starting from scratch, that would be the time to get away from flat maps and go with a globe. The benefits are great in terms of accuracy, especially if the map cover teh whole planet rather than just a small region. I know it could be difficult, just making a suggestion that might be worth looking into.



Oznoyng -> RE: WitP 2 (9/3/2005 9:04:07 PM)

quote:

ORIGINAL: Oleg Mastruko
The only question is how much time you're willing to invest and do you plan to get Very Rich (tm), Just Rich (tm) or Bankrupt (tm) after the project [:D]

I would do it for two reasons: it is a hobby already, and I'd like to make a little money off it. All things being equal, I would prefer Comfortable(tm) over Very Rich (tm), Just Rich (tm) or Bankrupt (tm).



Captain Cruft -> RE: WitP 2 (9/3/2005 9:06:19 PM)

Web-based != HTML only

With Java you can make as full-featured a GUI as you want. OK it won't be quite as fast as a native app but with a 2D turn-based game does that really matter? No :)

This whole type of framework is what virtually the entire corporate world is now using for new apps BTW. A lot are using .NET to do it but Oznoyng's idea is to use portable and standard tools instead so you are not tied to the Windows/Internet Explorer platform.

For an example of how good a full-featured Java-based strategy game can look, check out TripleA (an Axis and Allies clone) at http://triplea.sourceforge.net/



Oznoyng -> RE: WitP 2 (9/3/2005 9:09:27 PM)

quote:

ORIGINAL: witpqs
quote:

ORIGINAL: Oznoyng
2. Campaign games would be played upon a map measuring 1080 hexes by 667 hexes. The map would be a mercator projection covering the world from 75 degrees north latitude to 60 degrees south longitude. Scale at the equator would be 20 nautical miles per hex and 5 or 6 miles per hex at 75 degrees north.

If you're starting from scratch, that would be the time to get away from flat maps and go with a globe. The benefits are great in terms of accuracy, especially if the map cover teh whole planet rather than just a small region. I know it could be difficult, just making a suggestion that might be worth looking into.

I toyed with the idea. In the end, I decided that the biggest reason why hex based flat maps are problematic is that they skew distances between bases when a constant hex size is used. Therefore, making hex size a function of latitude rather than going to a globe and continuous coordinates seemed the simpler solution.



Oznoyng -> RE: WitP 2 (9/3/2005 9:11:17 PM)

quote:

ORIGINAL: Captain Cruft
This whole type of framework is what virtually the entire corporate world is now using for new apps BTW. A lot are using .NET to do it but Oznoyng's idea is to use portable and standard tools instead so you are not tied to the Windows/Internet Explorer platform.

Guess where I grew up as a programmer?



Captain Cruft -> RE: WitP 2 (9/3/2005 9:15:18 PM)

quote:

ORIGINAL: Oznoyng

quote:

ORIGINAL: witpqs
quote:

ORIGINAL: Oznoyng
2. Campaign games would be played upon a map measuring 1080 hexes by 667 hexes. The map would be a mercator projection covering the world from 75 degrees north latitude to 60 degrees south longitude. Scale at the equator would be 20 nautical miles per hex and 5 or 6 miles per hex at 75 degrees north.

If you're starting from scratch, that would be the time to get away from flat maps and go with a globe. The benefits are great in terms of accuracy, especially if the map cover teh whole planet rather than just a small region. I know it could be difficult, just making a suggestion that might be worth looking into.

I toyed with the idea. In the end, I decided that the biggest reason why hex based flat maps are problematic is that they skew distances between bases when a constant hex size is used. Therefore, making hex size a function of latitude rather than going to a globe and continuous coordinates seemed the simpler solution.


How do you deal with vertical movement? Or does that just remain constant?

BTW there is an open source game called Xconq, which is very lacking in many ways but does seem to deal with this mapping the earth issue quite well. http://xconq.org



Captain Cruft -> RE: WitP 2 (9/3/2005 9:18:15 PM)

quote:

ORIGINAL: Oznoyng

quote:

ORIGINAL: Captain Cruft
This whole type of framework is what virtually the entire corporate world is now using for new apps BTW. A lot are using .NET to do it but Oznoyng's idea is to use portable and standard tools instead so you are not tied to the Windows/Internet Explorer platform.

Guess where I grew up as a programmer?


Hmm let me think ... How do you feel about the statement that 'vi' is the fastest editor on the planet? Or the question does that make it worth the pain of learning to use it? ;)

I sent you a PM BTW.



jwilkerson -> RE: WitP 2 (9/3/2005 9:44:08 PM)

snip ...
quote:

Whether an executable exists or the app runs out of the browser
... snip

Exact-a-mundo

The great "windows versus web" debate is a non-starter ... and with concepts like "smart client" coming along, even more so ... how does the code get to the mahine it will execute on, and where does it execute, these things matter, but not whether windows DLL or active-x like equivalent ...




ChezDaJez -> RE: WitP 2 (9/3/2005 9:45:47 PM)

This game sounds like it would be fun. As far as subscription based, it doesn't matter so long as the game is playable and enjoyable.

I expecially like the command structure idea. Players are far less likely to be reckless with their units if they have only a finite supply of them without timely replacements.

quote:

2. Campaign games would be played upon a map measuring 1080 hexes by 667 hexes. The map would be a mercator projection covering the world from 75 degrees north latitude to 60 degrees south longitude. Scale at the equator would be 20 nautical miles per hex and 5 or 6 miles per hex at 75 degrees north.


The problem as I see it is that it would be very difficult calculating hex based movement rates because the size of the hexes are not homogenous. In addition calculating allowable hex distance movement for aircraft could be a nightmare becuase you have to first determine direction in order to determine the number of allowable hexes it can fly.

I would offer an alternative suggestion to this. Use lat/long coordinates to indicate position and movement such as used in the game Harpoon and SH3. Hex data can be used to describe the land terrain. A simple comparison could be performed during the movement phase to determine the allowable movement rate for land forces and used during naval movement to avoid land masses. Lat/long distance calculations are pretty simple and would allw for precise range measurements so that aircraft ranges would not have to be truncated or expanded to meet the requirements of a hex grid.

A hybrid system might also work with a hex grid used only for land position and movement and lat/long with course/speed for naval movement.

Anyways, just a thought. I wish I could help but I gave up trying to learn programming after getting thoroughly confused in Pascal!

Chez



Captain Cruft -> RE: WitP 2 (9/3/2005 9:57:21 PM)

quote:

ORIGINAL: ChezDaJez
I would offer an alternative suggestion to this. Use lat/long coordinates to indicate position and movement such as used in the game Harpoon and SH3. Hex data can be used to describe the land terrain. A simple comparison could be performed during the movement phase to determine the allowable movement rate for land forces and used during naval movement to avoid land masses. Lat/long distance calculations are pretty simple and would allw for precise range measurements so that aircraft ranges would not have to be truncated or expanded to meet the requirements of a hex grid.


There are problems with the idea of vector-based movement in a game of this size, which I have investigated a bit.

1) It requires floating point calculations, which may greatly increase turn execution time.
2) Tracking x,y and possibly z positions for every ship and plane (even groups of planes) is a lot of work and may also greatly increase turn execution time.
3) A second of arc corresponds to a relatively small distance (can't remember exactly). If you are going to track movement (especially of aircraft) in these small increments it requires a very small "tick time", something in the order of a few seconds. This may also greatly increase turn execution time.

I think trying to use a hybrid vector/hex solution would probably cause more problems than it solved. Applying vector-based movement to land units as well would be a better idea. The HTTR engine shows it can be done :)



Oznoyng -> RE: WitP 2 (9/3/2005 10:25:04 PM)

quote:

ORIGINAL: ChezDaJez
The problem as I see it is that it would be very difficult calculating hex based movement rates because the size of the hexes are not homogenous. In addition calculating allowable hex distance movement for aircraft could be a nightmare becuase you have to first determine direction in order to determine the number of allowable hexes it can fly.

I would offer an alternative suggestion to this. Use lat/long coordinates to indicate position and movement such as used in the game Harpoon and SH3. Hex data can be used to describe the land terrain. A simple comparison could be performed during the movement phase to determine the allowable movement rate for land forces and used during naval movement to avoid land masses. Lat/long distance calculations are pretty simple and would allw for precise range measurements so that aircraft ranges would not have to be truncated or expanded to meet the requirements of a hex grid.

Using the hex based system I am thinking of, indicating a hex location would be exactly the same as recording coordinates to a precision of 20 minutes of arc. So hex 0, 0 corresponds to a position bounded by the "square" with corners at 0 degrees 10 minutes East, 0 degrees 10 minutes North and 0 degrees 10 minutes West, 0 degrees 10 minutes South.

I do not intend to specify ranges of aircraft (or ships for that matter) in hexes. I intend to specify them in nautical miles. A "movement point" will equal one nautical mile. Movement into a hex requires accumulation of movement points at least equal to the size of the hex (for land movement, the cost to move into the hex will be modified by terrain, weather conditions, stack density, and unused transportation facilities).

Edit: After reading Captain Cruft's response below, I realized that the explanation above was not really accurate given what I had planned. The longitude adheres to the 20 degrees of arc statement, but the latitude is not 20 minutes per hex row as the above suggests. It actually varies from 17 minutes of arc at the equator to 4 minutes of arc at 75 degrees North. Next time I will go back and look at the spreadsheet before I post...



Captain Cruft -> RE: WitP 2 (9/3/2005 10:54:45 PM)

I am still intrigued by movement at extreme latitudes, where the hexes are narrower.

Assuming WitP style "horizontally stacking" hexes: 
             /\ 
        NW  /  \  NE
           /    \
          |      |
        W |      | E
          |      |
           \    /           
        SW  \  /  SE
             \/

I understand that the effective hex width will decrease based on some sort of formula dependent on the hex Y co-ordinate. This will have the effect of increasing movement speed in the W & E directions.

What about movement in the NW, NE, SW & SE directions though? The hex height (not represented by a hex side) does not change. Will you actually use vector calculations to work it out? Or just apply a simple ratio? Or just use the basic vertical speed unmodified? Or ... ?

Or perhaps you are thinking of using vertically stacking hexes? That doesn't actually change this problem though since you still have NW, NE, SW & SE directions ... 
              N
            ----
       NW  /    \  NE
          /      \
          \      /
       SW  \    /  SE
            ----
             S



EUBanana -> RE: WitP 2 (9/3/2005 11:35:06 PM)

subscription based = not for me.

Never given in on that basic point yet, and hopefully never will.



Captain Cruft -> RE: WitP 2 (9/3/2005 11:46:35 PM)

quote:

ORIGINAL: EUBanana

subscription based = not for me.

Never given in on that basic point yet, and hopefully never will.


Fair enough, but in this case it would not be about ripping the customer off.

This sort of persistent multi-player game *requires* a server infrastructure and accompanying bandwidth. These things cost money, and on a monthly basis. That's the reason why it has to be subscription based.




Alikchi2 -> RE: WitP 2 (9/4/2005 12:06:29 AM)

I like the idea - esp. the Supreme Commander/voting system.

Would it be possible to delegate non-"theatre" responsibilities to individual players? I could see people enjoying playing an "Albert Speer" type player.

I don't know enough about the map/hex debate except to say that I dislike the "hex" approach as a general rule - after 1all these years, we should be able to do better - but that a 3d map has never been proven workable in a game like this.

Edit: Don't forget the WitP Wish List sticky!



Page: [1] 2   next >   >>

Valid CSS!




Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI
0.796875