Operational Warfare Developer's Blog

Developer's blog for the Operational Art of War series

About the author

Ralph Trickey maintains TOAW III
I set this Blog up for fun, and for my own edication! Nothing is guaranteed, it's for my own use primarily, so even if I say that something may happen with the next release, please understand that it may not. I plan to post random thoughts and other things like that at random times here. I don't have a specific plan for what will be here.
E-mail me Send mail

Recent posts

Recent comments

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2012

Translation help needed

I need help upating the various translations to add the new strings.

Please help if possible.

http://www.matrixgames.com/forums/tm.asp?m=2469439&mpage=1&key=&#2470929

 


Posted by Ralph Trickey on Monday, May 17, 2010 8:30 PM
Permalink | Comments (0) | Post RSSRSS comment feed

More Geek Stuff

Still here,still working away. I had some issues, but everything should be cleared up now, so I'm ready for the final sprint to get everything finished, packaged, etc.

Here's my new development environment.

8Gb Quad core laptop running Windows 7 64-bit.

Visual Studio 2010 for development and release builds.

I'm using a productivity tool called CodeRush from DevExpress.

I'm using TFS for my source code control and bug tracking.

My backups are being done right now wilh Microsoft 'Live Mesh' I'm backing up TFS, I'm also backing up my development directory, and several other directories. These backups are going both to three other machines on my home netowrk, and also up to 'the cloud.' Live mesh gives you a free 5 Gigabyte account which has been enough. I also pull off DVDs about once a month. The TFS backups are daily, and the backups of my development directory are near real-time.

I'm also doing daily backups to a second drive attached to the system.

Ralph

 


Posted by Ralph Trickey on Saturday, April 17, 2010 10:19 AM
Permalink | Comments (2) | Post RSSRSS comment feed

Graphics update

I've been working with Damezzi to add a new set of PNG graphics with Alpha support.

For the non geeks, this means that it should be possible set the transparency of each pixel from 0 (transparent) to 255 (solid). It should be possible to add in things like clouds that don't obscure the terrain beneath, but are semi transparent. There may be a slight performance hit, but I don't think it will be noticeable. I'm still working on finishing up the code, so we haven't seen the finished item, but I think it should look pretty cool. Once I get everything working, I'll upload a sample.

I think it would be neat to be able to see where the coulds are without having to toggle them on and off. I'm sure that there are some other more important things that are going to happen with this, including cleaner fonts, but for some reason the clouds fascinate meCool. They're very nice to know for some scenarios, but a pain in practice.

I know that the high end products like Adobe support Alpha, but there's also an Alpha editor add on for Paint.Net (free) which I haven't tried out. I have enough problems with the simple red green blue without the added alpha channel!!!Wink

Ralph

 


Posted by Ralph Trickey on Thursday, December 10, 2009 11:48 AM
Permalink | Comments (14) | Post RSSRSS comment feed

Future Game ideas

The major thing about the next game will be that it's built from the ground up using C#. That's has a couple of advantages. One is that since C# is also my day job, making changes is going to be easier.  Right now, I'm thinking that it's going to be an XNA game with WPF added for extra features. XNA means that things like smooth scrolling are practical, and WPF means that things like a chain of command tree are a lot more practical.

I'm also pushing towards standards like XML, so creating alternate editors, and even modifying the save files for 'campaigns', etc. should be possible in single-player.

The feature list for the next game is similar, but there are areas like naval combat, chain of command and AI/Strategic programmability will be enhanced. There will be other changes as well. The wishlist is a good place to start for things like that.

WeGo and multiplayer is probably for the game after that. I can see where they go together for smaller, quick games, but there is too much to do there for it to make it into the next game. It's probably not going to have rounds, and is overall going to be a different game although it should allow play of the same scenarios. I see a multiplayer game as having to be more polished and having a simpler interface, since it's going to be a lot easier to get a friend into a multiplayer game than into a PBEM game. I can also see where wanting to be able to control at a higher level would be very nice to make it go faster, otherwise anything much larger than Arracourt is going to be a problem. Unfortunately, multiplayer coding is HARD, there are all kinds of issues like threads, ports and firewalls that you have to deal with. The combat model totally changes, you have to queue up all the moves and planned combats and then watch a movie after the fact (That means that there have to be new combat rules, etc.). There's going to have to be some expermentation to find out what user model works best. It almost begs for a model where you control at a higher level, and the individual units decide what to attack after moving instead of plotting the individual attacks. It's also true that it's a smaller market share, that's why it's a lower priority. I think that there's a market for it, it's just going to have to be a very different game.

Ralph


Posted by Ralph Trickey on Sunday, October 11, 2009 2:25 PM
Permalink | Comments (6) | Post RSSRSS comment feed

Another one went out to the beta testers

3.4.0.95 was sent out to the beta testers and put into subversion. That's 95 separate builds that I felt were good enough to send out.

We're still making progress. I did a chunk of work this weekend, and I think I've got most of the things in that we're going to do for this release in now, although I need to go back through the list to make sure. If that's true, then we're just in for a load of testing, packaging, etc. to get things packaged up. That always takes a lot more time than I expect.

Never again will I do anything crazy like being this ambitious abut what's going into a patch, that was just too wearing. The number of major changes is jsut too many.

I'm going to play some TOAW now and wait for the bugs... Bob's too good at finding where I hid them.

After this goes out, the next patch will probably be early next year with any bug fixes that I put in and a few features that I didn't have time to get in.

Ralph

 


Posted by Ralph Trickey on Sunday, October 04, 2009 7:27 PM
Permalink | Comments (3) | Post RSSRSS comment feed

Money quote for this release...

We added in a debugging feature that's intended to help some designers fine tune how Elmer plays the first rounds of their scenarios, and to understand how Elmer plays. It's pretty rough, but I think some of the designers may use it. In a single player mode, you can press a key (the | key right now, but I'll change it before release) and it will move all your units the way that Elmer would, does overruns and sets up the attacks, all you have to do is press the 'E' key and the '1' key to end they turn, yes I'm sure. Or you can fine-tune Elmer's decision to meet the strategic demands.

We now allow single player games to be loaded into the editor, edited, and played. I figure between those two features, there is probably 1-2 players that may try playing solo games by allowing Elmer to move each side with some guidance from them. (I've seens one request on this blog from someone that did it in CoW, so hopefully he's listening ;)

I definitely want to expand on this for the next game, and I'm sure I'll get some feedback on it, both 'why are you wasting your time' and 'great idea, but...'.

Obviously, Elmer plays better in some scenarios than others, but...

Here's the quote from one of the TOADs, it wasn't me, but I'm getting the same feeling... 

Elmer does a better job than me in setting up first round battles and leaving a large percentage of my turn for further movement and combat... I'd rather see this feature disabled in PBEM mode

 


Posted by Ralph Trickey on Friday, March 13, 2009 6:46 PM
Permalink | Comments (4) | Post RSSRSS comment feed

June was a waste

June was incredibly painful for my day job. We rolled out a new credit card tracking system, started a SarBox audit, thought that we might have some lost revenue, had a lot of fraud in Indis/Asia and was a general mad-house. Things are finally slowing down, so I am finally able to get back to work  It's also been incredibly hot for Colorado here.

I'm going to be saving the non-discrete supply structures and adding in the effects of the supply units this week, and I'll probably play some more with taking the translation stuff out of the DLLs and putting them into text files instead.

I also played a little of Civ Recolution, and I'm considering whether the tooltips make more sense next to the cursor, or if I should put them on the bootm left corner. I'll play with that too. I think that the bottom left may be a little less distracting. I'd rather not put in an option, tbut that one may make sense.

Ralph


Posted by Ralph Trickey on Sunday, August 03, 2008 12:24 PM
Permalink | Comments (1) | Post RSSRSS comment feed

Pathfinding and Supply

I'm posting this so taht people can understand what was, and what it's changing to.  It's mainly for the people that are looking at what features may/may not fit into future releases, so that they can understand a bit of the mecahnics, and why some things aren't as diffucult as they might seem.

The 'old' way of finding your way from point a to point b was to try to go in a straight line, then look for a different line, etc. Then do special processing for roads, etc. It was extremely slow, but worked well enough on small maps.

The 'new' way is something called A*. It works differently.

A* works by figuring the distnace from the source to the destination, and then starting at the source, calculates the cost to move into the 6 hexes around it. It marks these as 'open' and the starting hex as 'closed'. It them looks through the map and finds the hex where the cost to move into that hex + the remaining distance is the lowest. Once it's foind that hex, it looks at the 6 hexes that are adjacent to that hex, and figures the cost to move into each of those hexes.. If the cost is less, it sets that hex to 'open'. If it's more (like the starting hex would be) it leaves the hex alone.

By doing this, A* will snake a path towards the ending hex. If there's a path to the target, A* is very fast, The only problem with A* is that it will potentially look at every possible hex trying to find a solution if there isn't one. Even on a 300x300 size map, that hasn't been a major problem so far, but if we go to 700x700, it's going to be about 5 times as many hexes.

There are ways to fix this problem by prepopulating a grid, and numbering each hex with a number 1 through N that represents a contiguous region of land or sea. I'll wait and see if I need to do that. That would at least cut down on the search space for 'impassible' paths

It's also possbile to make this allow for trains, planes and ships for Elmer's use, but I haven't tried using these yet. It's probably going to break some scenarios, so it has to wait. Once the program is modified to allow for pathfinding through multiple transportation means, that should help Emler, especially in places like the Pacific.

One very interesting feature about A* is that it's possible to modify it to be useful when you have more tha one source/destination. For example, when retreating, you could use that same algorithm, and stop once you'd reached a command or HQ unit. It would be a little better than what currently works, but probalby not noticeably different in most situations.

Another interesting applicaiton would be for things like supply. It's possible to 'seed' the map with all the supply points, and then to move outward from all of them at the same time , filling in the supply map. This is a LOT faster than the current method, it's also a lot more flexible. The old method made 4 passes through the map. Once for Rail, Roads, etc. The new methid doesn't need to hard code those levels, and can be a lot more flexible, and easier to modify. If we want to allow for supply to travel through friendly owned ports, that's possible, if we want to attentuate by distance instead of doing 4 levels, that's possible. Heck, if we wanted to allow for supply points to provide different levels of supply, that may be possible too.

It's also going to (eventually) provide some perfomance boosts for Elmer. Most of the Elmer code still uses a brute force method of determing his next target. We can do faster/better than that.

I probalby did a poor job of explaing how A* works. There are a lot of tutorials about it on the Net now. The important thing to remember is that is kind of flows out like water, looking for the low spots, and is very fast for a lot of things, and is very improtant for this game going forwards. The fact that is handles multiple sources/destinations makes it very useful for a lot of things.

 

 

 


Posted by Ralph Trickey on Sunday, July 13, 2008 8:50 AM
Permalink | Comments (3) | Post RSSRSS comment feed

.Net complile

TOAW seems to compile and run fine now as Managed C++.

Why do you care? Because next version is getting a major facelift. I was thinking that I'd have to go off into the woods for a year or so in order to do that, but it looks like I may be able to do someof it in pieces instead of all at once. That means that I can combine internal changes and user interface changes and some testing and new coding all at the same time, instead of having to convert everything first before doing anything else. It makes my life a little easier, and may help to keep some of the Beta Bunnies. Definitely not something for TOAW III, I'm afraid. Doing something like that could be a support nightmare as all of the Mac/Linux/Windows 98 users came out of the woodwork after me.

Ralph


Posted by Ralph Trickey on Saturday, June 07, 2008 10:37 PM
Permalink | Comments (2) | Post RSSRSS comment feed

User Interface design

If you do anything with presenting data to users, this is something that you should watch. There are a lot of neat ideas in here that I want to apply to TOAW or the next game. It's definitely got some really good ideas. I'm going to pick up the book too, although i don't know when I'll have the time to read it. It talks about things like using the font size and contrast to help direct peoples attention to the important pieces, keeping the attention focused on one spot (like tooltips) and several other details like that which most people don't consciously think about. Some of the things I can implement now, and some (most of the contrast ones) will have to wait until the next game.

 One example would be looking at the pop up menu to see if it makes sense to center it on the place that I might expect a user to click by the context. I don't know if it's possible, but it's something to look at.

http://www.dnrtv.com/default.aspx?showNum=112


Posted by Ralph Trickey on Saturday, June 07, 2008 1:09 PM
Permalink | Comments (0) | Post RSSRSS comment feed