 |
|
|
Killer Bee Software Update:
February 28th, 2005 - This
Report Retired
Update: February 15th, 2005(late)- Just Checking In
There's not much to report in today's status report. Last week was not the stellar week of progress I had hoped for, because I spent most of it on my back with the flu. I still have not gotten my voice back yet. Being sick was a bummer.
What this means is I am still not ready to release a patch yet. It is getting a little frustrating because I had hoped the trial patch would be out by now, but it really will not be too much longer. I am working on it this week and hopefully it will be there. Most of the additions have been put in, there are still a few fixes that are on the log and need to be inserted. It is really all only a matter of time. The only "mystery" is the hang that occasionally happens in network play when one player resigns. This is definitely a "race condition" (has to do with timing), and I have not been able to solve that one yet…for on the surface everything appears to be done correctly (which is usually the case with race conditions). But I am sure I will catch it.
I am very pleased with the interest surrounding Oblivion's unit database. It appears several people are looking at it and enjoying it. I am also getting other emails from people who have added one or two units to perform tasks they have always wanted to have in the game but up until now have not been able to. I am also getting many letters from a lot of fans saying how much fun they are having. One central theme is that the game "grows on you". This is very exciting, because EDEE was designed to be a game that you would play for another decade, as it was with the previous versions of Empire. I am starting to think this is going to happen.
One player sent me a bug report saying that he had played the game for over 200 hours already and that was the first issue he had found. I jokingly responded that no bugs are fixed after the first 100 hours of play…but seriously it is exciting when you think that most games that come out today are designed to provide up to 60 hours of play before they get 'old'. To me, Empire never gets old. Sure you won't play it for a while, but if you are like me, you will always find yourself going back to it as time goes by,
I have mentioned this before, but in regards to the longevity of the game, the real power of the modification capabilities of the game won't be realized for quite a while yet. It will take a great amount of time to experiment with what works and what doesn't….then wrap an AI around what works. Unit Sets like Oblivion's are a great start in that direction. If you like his mods, or someone else's…make sure you send them a little praise or recognize what you like about them in the forums. Encourage their creativity and explore your own. That is truly what making mods is all about.
So anyway a little soap box there, but not much else to report. I will just say I am really ready to get this patch out the door…but like everything else, it will only come out when it has reached a state I am happy with, regardless of the delay. So hang in there with me and it will get out in due course. In the mean time, please continue to play the game and spread the word to other that Empire lives on, and is a great deal of fun.
Update: January 31st, 2005- Taking a Little Time
Work continues on the first patch for Empire Deluxe Enhanced Edition. Some of the patch work has slowed down, mainly because I found I needed to take a little time off, for I had worked non-stop all of last year, and did not want to burn out. I am trying to get myself to "normal" hours in both waking and sleep. I will admit EDEE took a tremendous amount of effort on my part for the entire part of last year, and it is important that I recharge myself. It is very difficult for me to think of future projects when I am deep in a project such as EDEE, and I have found I also need a little reflection time. So I hope you can indulge me a little.
This slowness has also caused a pause in the previously planned start of the Pocket PC build. I plan on looking into this now after the trial patch is released. I definitely intend to pursue that though. It should get started soon. Speaking of other operating systems, I got a report from a player telling me that they have been using Virtual PC for MAC as a windows emulator and have not had any difficulty with EDEE. This should be good news to MAC users.
The patch is moving forward and it is over 50% done. I put up a couple of screen shots of the "Strategy Map" in the forum. Last week I added an "Escort Mode", which is a hot key command which indicates the next mouse click is an escort target. I have also added a "patrol base" command capability with the mouse much like the repeatable path command capability already in place. If you hold down the control key, the path you set up will be a base patrol with the unit's current host as the base.
While looking at orders, I fixed a problem with base patrol and with order points that could cause the game to hang. Another order that has been "added" was the "client alert" order…this command is also used in the production till efficiency order that will now pop up a production dialog at the designated time.
There are still several things yet to be done in the patch. I have a few crash conditions that have been reported that need to be repaired. Some of the causes for these are already known, others still need to be investigated. There is also the resignation problem in Internet games that needs to be resolved, and a few AI issues.
I think players will be pleased with the patch when it comes out. I have received a great deal of positive mail about the game this month. I must say I am very pleased by this. I would encourage you to spread the word amongst friends and via the forums if you like the game. I have always said people listen more when it comes from you. Spreading the word is a great way to support the game. Making mods and such is another (also a great way to enjoy it).
So I am sure it will still be a couple of more weeks or so before I am ready to think about releasing a trial patch for EDEE. Work is progressing steadily, and a few issues are still coming I and being investigated. But soon enough, it will be ready for players to check out.
Update: January 17th, 2005- Working Towards A Patch
Well, the game has been out about three weeks now, and I am very pleased both with how it was received, and with how few problems there have been. I do have a change list, and I have started work on that, and I have received a couple of crash reports from people, and these will be fixed, but overall I am very happy with the stability of the game.
I would like to take this time to again encourage everyone to post about the game to your favorite forum.
It will be a few weeks before the trial patch is ready. By the time of the next status report (at the end of the month) I should have a good idea as to when it will be out…possibly around that time.
The trial patch will not just make fixes, but should include a few additions as well. There has been quite a discussion about slowing down the automatic processing for the game, and I believe I have come up with a good solution for this. I also have added a "strategic map", which will be a separate window with the map, what ever size, stretched onto it. I have not yet, but plan to address the convenience of the "No Production Alerts" that users apparently loved in EDIE. I had not realized this was such a well-loved feature.
A feature that will not be added to the game is hot-seat. I have had a few people request the addition of this, but frankly hot seat is not very friendly for this type of architecture. There have been some people who have expressed "surprise" at this, but I have never said hot seat would be available, and had commented several times publicly about that. Hot seat is also not available in the demo. As someone has suggested, you can run a hot seat game via the PBM mechanism. And if you desire hot seat play a lot, I would recommend getting a license for the Remote Client and running both on the same machine if that seems necessary.
One must remember that with additions and changes, though I am considering some, nothing can be called "easy". When you have an existing piece of software, at the scale of EDEE, nothing is simple or easy when it is added. All additions must be evaluated carefully, and may not be possible due to their effects on other aspects of the game.
We are seeing some mods surface. The Yahoo mod group is an excellent place to hang and keep your ear on what people are sharing. There is some evidence some have worked a little with the AI source code, but I have not heard much about that yet. I do know that WATCOM's free compiler has a bunch of errors during compilation, and I am looking into making that a little better. That may be a lost cause though. Currently using MS VC++ is the intended compiler.
Development on the handheld version of the game will most likely be delayed until the patch is released. After that I should get a good time frame as to when such a port would be ready,
I plan on keeping this report going until the patch is released, then I will most likely start a new "general report". This report will discuss all of the aspects going on with Killer Bee Software, such as the future for The Perfect General, and some other projects I have been mulling over. I definitely need a little time to recharge, and am looking forward to that time.
So in a couple of weeks we should be hearing about the preparation of the trial patch.
Update: January 3rd, 2005- And So It Begins
The launch for EDEE has been a huge success. There have been several things that have come up regarding the game, and some changes are going to be made, but for the most part there have been very few problems. This is great news. I am very thankful to the beta group.
Many users are still adjusting to the game. I believe they are finding it a great deal of fun. I have received a great deal of email from people saying how much they like the game and how they have been playing it an awful lot.
I have not seen a great deal of online games yet, but I suspect people are currently still playing a lot of solo play and are not ready to test the waters of online play with the new units in battle. I am sure this will change and time moves forward.
I would encourage those that like the game to spread the word with their friends. EDEE is a great game, and it is through word-of-mouth praise that helps build the community. Also I would encourage player to help build up the extra capabilities of the game, including maps, scenarios, units, icons, and even computer players. Within you is the power to make the game much greater than it is now. This is something Empire fans have wanted for a long time.
I will begin work on the first patch shortly. There are corrections to be made to the game, and I am sure more will be discovered in the coming weeks. Also, there are some adjustments that are still needed for the interface. I hope to get these into a "trial patch" which will become available towards the end of the month. As previous KBS game player's may know, a trial patch is released and will be out for a few weeks as sort of a large test. Players that apply the patch are encouraged to backup the game, for the patch may have some problems within it. If the patch proves stable enough, there is then an official first patch released shortly afterwards.
I have already received questions as to what is next for KBS. After the patch I will begin to consider the options. There are some short projects and some longer ones. The Perfect General has many things that I would like to adjust. There are also some other games that I would like to bring the AI extensibility to. But it will take a little while for m focus to change from EDEE…it has already felt quite odd to not do as much code work on It a before. It has been a very long road...and there is a little sleep I must catch up with as well.
So the game is now out, and it is up to you to make it the game all you wanted it to be. I have always loved games that had editors, for the creations people come up with are always way beyond what I ever thought of, and that makes it all very interesting.
Update: December
The Preview is out. Wow. I can hardly believe it. I am calling it a preview because there are a couple of minor adjustments needed before release, and it may have some hidden bombs in it waiting to go off. But it is out there, and if for some reason you have not seen it yet, best hop to it. I have opened up the "Pre-Sales" period where you can save money on the game. I am shooting for a December 28th release date, but that of course depends on how it fares in this final beta week, in the preview, and if I can get everything that remains done.
But the distribution of the preview and the setting up of the presales, and the discount mailing were a huge logistical step in preparing the game for release. That road is behind me now, and the "pedal is to the metal" as we head towards the full release.
Regarding the quality of the preview, I am thrilled with how it is performing with all of the people that have looked at it. As I told the beta group, I am not naïve enough to believe it does not have any defects, but the lack of issues today is a testament to how effective this beta really was. I am very pleased with the group. And I hate to break it up. But the end of the beta is very near, and it is time to move forward with the future of Empire.
Now that you have seen the preview (I assume), I am sure you can see the differences between the new interface and the old if you are an ED/EDIE user. To me the adjustment is not difficult because I did it over 12 months. For the testers it was quite rough, because they had ZERO documentation on many things, and I did not have the time to explain it to them (again they were fantastic at taking this abuse and moving forward). But their honest critiques and questions helped shape the interface in a big way. (As you can see, I am very proud of how the beta group performed). Hopefully for you it will be less bumpy.
I do not anticipate EDIE becoming obsolete. That game is a classic in its own right, and I know many people will still enjoy playing it.
So what remains to be done? The manual is being proofed by a tester, and those changes are being worked back in. There is some additional info I want to get in there. I may have time to add some tutorials. The code continues to settle, (I am trying my best not to touch it) and admittedly the Preview will help with that, as it gets more and more exercise. There are a couple of items that will be addressed in the next couple of days. If you find a problem, definitely let me know. A big factor is I do not want to feel like it is being rushed - so the settling is important to me. I am sure you can appreciate that.
There will always be problems…this game is way to big for there not to be. As I recall, the first patch release for ED 3.0 was pretty major. I think 3.12 was a year into the game. My plan is to continue to support the game of course. And trap and fix problems as they arise.
My target release date is December 28th. I see no reason why at this point the game will not be released. The exposing of strings has been put on hold as mentioned in previous reports. A decision on whether to move forward with this feature post release will be made after next week.
The AI source code and World Building code is a big hurdle that much be approached shortly after the release. Looking over the calendar, January 3rd is a good estimated date of that release. Then the fun really begins, as our AI hounds begin to work on improving and changing the AI.
So in two weeks time you will be playing the full game. Hopefully you will find it as fun as I have. And we will begin to embark on the journey of new AI possibilities. There will be an AI tourney scheduled for some point in 2005. That is going to be a great deal of fun.
So for Christmas, enjoy the preview, and next week I will do my best to get you the full version early next week.
Update: December 6th, 2004- So Very Close...
The intensity of the beta development is starting to wane. I actually slept eight hours two nights ago. The game is now in a feature freeze…pretty much. I have a couple of items that are needed to go in, but for the most part the game is done. The testers got a build last Friday, and it has done quite well. The beta group has done an absolutely outstanding job, even though they have been quite rough on me ;>. They have really done everyone quite a service. I am going to miss the beta forum. It has been going on for two month, but it seems like much longer, and I have become quite familiar with many if the testers. I can tell I am going to crae online play when this is done.
The largest challenge that remains is the manual. There is a great deal going on under the hood of EDEE, and the manual is going to be an important aspect of this game - enabling you to take advantage of the various features of the game. For the most part, the beta testers have been forced to learn by trial and error. Various aspects of the interface were written and presented, but they received virtually no information in regards to the units and most of the concepts of the game.
Preparing the manual is a very time consuming process and will take a slight while. It will be another HTML manual, but it will not be one big page as it was in EDIE. It will be indexed, and hopefully it will be easy to look up information regarding the game.
Experienced ED players will definitely need to read the manual and make adjustments t the changes in the interface. Some of the changes are subtle, others more direct. It may take some getting used to…after all, you have experienced the ED interface for a dozen years now. Some of the keys have changed, and some operations are done differently. It will take some time to find ways of doing things that are most comfortable to you. Reading the manual is important in this regard. It will help you see the features that are available.
I am not yet satisfied as to the stability of the game. There are still some assertions, a couple of which must be rectified. I feel it needs a little more time to settle. It will never be perfect, I am amazed with the size of the program - about four times that of EDIE when you count semi-colons. It is so new and there are so many variations to it. I am sure after release I will be still chasing issues that come up due to people setting up the game the way the want it most. I hope you will be patient in this regard.
I had hoped to get it out before Christmas, but it may actually have to wait until shortly after that. A medical emergency with a family member caused a slight slip in the schedule, as I was called away for a few days. One of the disadvantages of being a one-man show is no one can pick up the slack for you. The jury is still out, but it really needs some time to make sure there aren't problems with it. If I were to release before Christmas, I would need to have a demo out next week. That seems a little bit rushed. A demo before Christmas is a distinct possibility. The game would follow a week or so after a demo release. I have marked on my calendar Jan 12 as the absolute latest time needed. I have Dec 23 and Dec 28 penciled in as release dates as well. I would pay attention to the web site, for it will come pretty soon.
This week I need to add the real sounds to the game, and as I mentioned, work on the manual. The only other aspect that needs a great deal of work is the string loading for internationalization. This feature may not make it in the first release, due to the logistical work required to perform it.
Today I played two online games. One was a three way with a player in Texas, the server player in California, and a player in Belgium. There was a connection drop at one point with the European player, and it was nice to see that he was able to come back in, without anyone else having to disconnect. It took a while, for he had his caps lock key on and was entering the wrong password. ;>
The 'connection service' has worked out very well. Players are able to quickly find games, and even use it to reconnect in situations mentioned above. The way it is set up is nice, such that individuals themselves can run one.
The three way game was fairly loose in play. One player wanted to fool around with gifting, so I ended up with an extra destroyer. I was nice and gave it back about three turns later. Towards the end we had one player abdicate his position. I also took part in an explore treaty with another player. It was interesting to watch his land area expand as he sighted new terrain.
The second online game was a one on one, and more competitive which was played to a resignation. My opponent had never played a live game before. It was great that he was able to easily connect and play a game. I am so pleased with how the game is playing now. It really feels good. I know I talked of vaporware long ago, and it certainly is not vaporware now. It is just about ready.
So you should keep a close eye out in the coming two weeks for the mention of the demo. I don't want to promise a pre-Christmas release at this point, because the quality of the game is very important to me. But very soon it will be ready. It has been a very long journey, and now we are so very close to the end of it, which will mark the beginning of the next generation of Empire.
Update: November 22nd, 2004- Riding The Wave
Wave Three began this weekend. It is the last Wave of testers to look at the game. The path to demo and gold have now been set. I suspect that within the next two weeks, the scheduling of both of these events should come clear, and they will come quickly.
It looks like the game will be released just at the beginning of the Christmas holidays. This will enable folks to play it while they are relaxing, and will give them a chance to look into what has turned into quite a game. This is my goal, and I appear on target at this point.
Wave Three is still in the early stages, but now most of the development work is bug fixes and minor interface shaping. There do not seem to be major obstacles in the way of the game. It appears as of this week the real meat of the code slinging has been done, and the mop up operations are in full effect. I anticipate this mopping to last through next week.
A manual is starting to emerge. It really only defines basic parts of the interface, but I work on it everyday, and it will soon encompass more subjects, such as game rules and concepts. It will be highly recommended that you read the manual if you get the game.
Online play has gone very well, though last week there was a hiccup with online chatting. But that was fixed with our "lucky version 13" and I am sure there will be some play over Turkey Day. The modders seem to enjoy the extended interface for unit database editing, and they have not made to many comments that would cause a change.
In fact, the majority of the game is like that. I can finally see this project starting to wrap up. But there are still a few things to do. The biggest of which are I have to insert a method for a remote player to change the player colors if he desires. I also have to do various final architecture things like encrypt some of the data and see if I can't compress some of the saved game data a little more. The game lacks a color scheme, which I will add very soon as well, and there are a few more properties that need to be fixed.
I am very proud of what is being accomplished with EDEE. But I can tell it will be a bit of time before it kicks into full gear. I am sure some people who are used to playing ED for 12 years will need some time to get used to the interface because it is different in several ways, and I am sure understanding some of the subtleties of the units will take some time as well. It will take time for those with the skill, desire and will to produce meaningful Computer players, and for others to shape and support the unit sets top come. When EDEE is released, it is not going to be the end. It will be the beginning. And I intend to support it after release.
So the next couple of weeks are going to be spent continually shaping and cleaning up the game. After that everything code wise will hopefully pretty much be done, and the attention can be put on making a preview copy for you folks to examine. As I said to the beta group, it is "crunch time". They have done a superb job in helping me prepare this game…preparing it for you.
Now I feel it will only be a matter of weeks before it will be ready. The next two weeks will be very telling, and at the next report, I should be mentioning the demo preparation. Not much else to report, but there will be a lot of action, very soon.
Update: November 8th, 2004- Riding The Wave
I am deep into Wave Two now, and starting to prepare for Wave Three. The testers are spread out all over the place. Some are playing solitaire, some network, some PBM. Others are watching the AI do his thing and tweaking him. Some are actively making maps and unit sets. All in all, quite a bit of activity is taking place. I receive reports from several people nightly as to what they are doing. There seems to be a good deal of attractiveness to the game, or these testers are gluttons for punishment.
There have been some time setbacks, while not serious, they will impact the final release time by a week or so. It was discovered at some point previous to now (I have lost track of the time), that there are various display limits built-in and hard coded into Windows 98. This has impacted two areas of the game, namely the game setup and the Unit Database Editor. The reasons why these two areas presented a problem to Windows 98 users was that there are many options available. The editor was impacted the most. This caused a pause as those interfaces had to be redesigned somewhat. Fortunately, I have a good group of Windows 98 testers, and a Win98 machine at my disposal. With the Unit Database Editor redesign completed, the preparation for Wave Three can become my focus.
I do not anticipate Wave Three starting for two more weeks though. It is possible that when the next report is logged, it will have just begun. Presentation is important for Wave 3, and the presentation of in-game help is going to be important, and is not yet in place. Also, user preferences and such still need to be adequately stored and recalled. The game is too fast in some places and needs to be throttled. Also, I need to attach the sound. Towards the end of this week my attention should be pointed towards these topics.
Wave Two has done a great deal with the online play. I am thrilled with the success of the "Connection Service", and I have found myself wanting to play online, though I really have not had the time. I can't believe I have been working on this project for nearly a year, and I can't wait to play it now! That is a very satisfying thing within itself. The service makes it easy to hook up and play a game with just a double click. The client server architecture enables players to disconnect and reconnect from a game. The server is able to stay up or restart without the other players.
Wave Two also has sported some PBM play as well. The logic to make the beginning of the game go faster has been improved. This was quite a challenge due to the open nature of the game. There have been a couple of constraints placed on PBM play due to the rapid start. Namely, actions such as gifting or making/breaking treaties will not be allowed until there is visual contact between players.
Several members of W2 are getting into "unit modding", making their own unit data sets. They have started there own group which will become a public forum once the game is released. Several testers are also closely scrutinizing the AI player. It's exciting to see them think about the AI, and I cannot wait for the programming to begin for others. There have been some debates as to what the best strategy to expand is, etc. Writing an AI is a great challenge. Although I now feel more confident with the "Standard" AI player, I still intend on having a contest a few months after release to encourage others to build one. That will really be exciting.
The last build (testers have a version 09) has been with the group for a while. I am going to release v10 in the next few days. This version has the unit editor changes, some additional to the Map Editor, including cut and paste, flip, etc. and some efforts to make our keyboard centric players more comfortable. Two testers convinced me to bring back "survey mode". I had not realized the dependence on this mode for those that focus on keyboard play. The interface will be different in some ways for the one we have gotten used to for twelve years, but I believe EDEE will be close enough, with improvements (of course). Online help will be of great use in bridging these differences.
So there is still some work to be done with Wave Two. But it has been an excellent test thus far, and I am really looking forward to getting things done over the next two weeks or so. It is staggering to see how far the game has gone since the beta began. I am very proud if it, and I think you will enjoy it. Wave Three will wait in the wings just a bit longer, but each day brings it closer.
I have been periodically posting some screens in the forum. Feel free to continue to make comments and ask questions.
Update: October 27th, 2004 - Late, But For Good Reason
Whoa, Where to Begin…
My apologies for being tardy in this report. Right now is most intense.
It has been continually busy, as EDEE is worked through the beta heading towards release. I currently have over two dozen people looking at it, with about fifteen more waiting for "Wave Three". Wave One was a huge success, and Wave Two is really taking off.
There was a great deal focus on solitaire play in Wave One. Many aspect of the Interface were added and improved upon. The game already looks and feels different than before beta began, as I knew it would. It still has a way to go, but I am pleased with its progress.
Wave Two started this past weekend, with the release of the "Remote Client" for network play, as well as the initial release of the source code for both the computer player DLL and the World Building code. Testers have been using the "Connection Service" nightly to hook up and play games. I know they are going to be thrilled with my beta version #08, which will be out this Friday. It has more improvements to network play, many of which were based off their comments and experiences with the game.
This connection service is really intended to be a network of individual "service hosts" which receive "advertisements" from games looking for players. If configured correctly, a game looking for players is a simple double-click away. I actually played a game Saturday night, the first competitive game of Empire I have played since I acquired the rights almost two years ago now. I really, really enjoyed it. This game is going to rock!
The testers have been doing a great job of learning the game, and the manual at this point is quite sparse. There is definitely some confusion at times, for there are things that are different than they were in EDIE. But the players are adjusting to the changes, and making suggestions on how to make the adjustments easier for the EDIE veteran.
The game itself is easy and simple to get into. With one menu option and one more button press, you are ready for your first turn. And it feels like Empire should feel. But beyond that, the size and scope of Empire Deluxe Enhanced Edition is now coming clear to the testers, and even myself. There are many, many details of the program that have been attended to, and some that still need attention. The testers from both waves have done a superb job in finding out what needs work.
When queried, the overall consensus of the testers is excellent. The word "Love" is bandied about by many testers. The maps, scenarios, and saved games I have looked at all suggest players are really getting into the games, and trying out different units.
Several testers are now looking at and tinkering with the unit database. I have seen images of Humvee units, and radar units, and even some new terrain. I think the strength and power of the unit editor is starting to sink in, as they are generating a lot of ideas for units.
I can see now why efforts for other games and such have failed in the past. The list of things to be done is enormous, and can be overwhelming to one not prepared. My advice to anyone trying something like this is to make sure you have plenty of time, then make more time.
Some players are stretching the scale of the game, and the limits of their own machines. I have seen an absolutely gorgeous map of Middle Earth measuring 800x600 or so. Who knows how long it would take to play such a game. I have received a report about a 500 AI player game on a 500x500 map, "because it was a rainy day". I have no idea how well this performed, for if each AI player took one second, each full turn would run close to ten minutes. I understand it took quite a bit of memory, and caused some paging, increasing the time to around 25 minutes a turn….I figure there was some smoke rising from that machine…I will start on the Cray port as soon as I can find the time….
I know of at least one tester who has successfully compiled the released source code for the AI player. I have several that are "examining it", but I do not know exactly what this entails. The AI player is not a very simple player, although the concept of receiving events and issuing commands is easy enough. But making a player who can challenge will truly be a test for those interested in Artificial Intelligence.. I can't wait to see the results.
So where does the game go from here? I will be sending a version 8 out to the group around Friday, and I am sure an 09 before the next status report. As I mentioned, 08 will entail a spruced up networking capability, as well as several other things. PBM play is now being looked into as well, and I hope to get some changes to that in this week as well.
I predict the second wave will last three weeks or so, which may, (and I emphasize may) enable a demo to come out around Turkey time, but I cannot promise this as of yet. The release date still has not been set. There is a great deal to this game, and every feature is worth the effort at this point. Nothing that is in now is going to be cut to save time.
So EDEE development continues to be an incredible experience. And I hope that soon enough, it will be available for you. By the next report, we will be deep into Wave II, and probably starting to think about Wave 3. Beyond Wave Three will most likely be the demo, and beyond that….
Update: October 11th, 2004 - It's Great!
Wow. Finally made it to the beta. And I am beginning to believe this is going to be a really excellent game.
I have selected three separate "waves" of testers, and the first wave hit the beach a week ago last Saturday. Since that time it has been extremely busy, with each user looking into various aspects of the game, and finding issues and making comments.
Did I say issues? Oh yes, the game is not perfect yet. There are some errors that we have been rooting out. So far though, nothing too horrible or insurmountable has been encountered. Bug-wise I feel it is on track.
There have been a large number of interface requests such as additional interface features and options. So much so that it has added some to the work log and I suspect the milestones for beta wave two will not be met by this weekend, but wave two may start later in the following week.
But the most exciting thing about the beta is, the testers appear to be constantly playing it, and having fun! Several have stated that they often forget they are testing, because they get so deep into their game play. Their questions about certain aspects of the game give me a great perspective on how they are getting into it.
Another wonderful surprise is that the AI has received some good comments. While I am skeptical of this AI's abilities, this is encouraging to hear. What will be even more thrilling will be when I turn this group loose on the AI code, for many of the people in this group have the AI DLL focus.
Right now I have limited the testing to solitaire play. No network client was provided, and the contact group for PBM has not been set up yet (though I think two of the play testers announced they were going to try it). Also, I have not yet distributed the AI code. But these limits have not prevented the first wave of doing some crazy things. One tester has a game with 49 computer opponents. Several have played games with nine or more. I have seen some very interesting saved games when looking at issues brought to my attention, and have caught even myself getting caught up into playing them.
It is a great group, with very insightful comments, a lot of patience and a fantastic attitude. The work they do here will benefit the next two waves, as well as everyone who will play the game after release. I am looking forward to the comments that will come when the second and third wave come on board. This is all very exciting.
So the focus last week, and much of the focus this week is on the interface. This includes the processing of the units, the input methods for entering orders, and the display of information for the user.
Before wave two, besides the interface, I also want to tweak the world building code, add some sound, and set up the connection API for finding Internet games available at any time. The interface will in no way be completed by wave two, but it will be fairly far along. I plan to let the AI code and the Network play come into play a little before wave two.
There have been some requests for a few additional orders…but these are essentially variations on a theme. Currently, when you 'load' a transport, it does not wait to be fully loaded as it did in EDIE. Instead, you get movment control right back. While all seem to like this, several think that a "load till full" command is missing, and it make sense to add one.
Several players have messed with the order queuing, and it does look as if there will be some presentation changes for that tab. Players are finding it a little confusing at first. However, one player has said that once you understand it, it is "indispensable".
The game feels better and stronger everyday. There is still some optimizing to be done, but it is now playing very well…although, the 50 player AI game is pretty slow I am sure...but there is still some optimization opportunities for the AI code as well.
So when is release time? I do not know yet. But it won't be much longer now. I will feel more comfortable with giving a date pretty soon, and within a couple of these reports, we should have a pretty good idea.
So from my perspective, the beta thus far has bee a terrific success. I have a great group doing great work. It's going to be a great game!
Update: September 27th, 2004 - Getting Ready For Beta
With my list of things to do before beta complete, it is now time to move forward and make Empire Deluxe Enhanced Edition a reality. That begins with the beta.
I am very pleased that I have finished up what I wanted to. The past two weeks have seen additional orders installed, as well as work on the AI player.
I had originally designed some orders called "Patrol and Engage", and "Explore and Engage", but those did not make it. I have decided that I will leave the engaging decisions up to the player. In the end I suspect the user will prefer to maintain control when it comes to combat, and such automated orders would complicate the game.
I did add the Load Detail and Unload Detail orders, which instruct a transport to load/unload a certain number of a certain type of unit. I also installed the maintain position and move to unit commands. I added commands to sweep and clear mines across a path, and to lay a road along points you draw up. Some no production orders were added as well orders to rest and repair.
My work on the AI was infrastructure oriented and focused on improving the API so that the individual computer player can provide his own name, as well as adding interface calls so that he can preserve the "extra data" that he has created in a saved game (data not stored in the Game Engine). I also added a scripting capability which allows you to change many attributes of the AI easily enough, including some grammar to describe the rules of engagement for units.
So with those things done, there are a few more things that I have to do before I can start the beta. I currently have broken "the build" down, and am rebuilding the entire project in a fashion that will be more organized for those wanting to work on World Building or AI APIs. It is now organized so that I now know what header files need to be exposed, and which libraries need to be distributed to make a world building DLL or an AI player. The world building API is more complex than it was for EDIE, but still not very complicated. There are only four or so functions that need to be implemented.
The AI player is a different story, linking to six libraries with access to probably three dozen or more external header files. My AI player I have built is approximately 20 some odd C++ files, some of which have well over one thousand lines in them. Underneath that are classes I supplied with a library that will help process some of the incoming data and provide some functions for querying that information so that you can make decisions and execute commands. There is really a lot going on in the AI. It will be exciting to see how it gets used. In the beta, there will be some people who will be working on building Ais. Being the first in this territory is going to be quite a challenge.
Once the entire program is build-able again, I will begin to prepare for the beta, which I hope will start this weekend. I have not yet gotten to sort through the applications I have received, and there were many…but should do so in the next day or so. I am sure some of those people will be contacted in the next few days and will receive the first version shortly thereafter. Then the fun begins.
Just because it will be in beta does not mean it is finished yet. There are several things that I will be working on in addition to responding to beta issues. Right now the string in the game are still hard coded, though the hooks are in place for them to be loaded via a file for internationalization purposes. I estimate there will probably close to two thousand strings that I have set aside in the program.
The external connection 'service' also will be installed while the beta is going on. With this, players will be able to send their game info to a website, and there it will be advertised for others to see and join in.
I have not installed the sound files yet, though I have had the music produced. Again, hooks in the database have been made, but this has yet to be implemented. So the first beta versions will be quiet. There are also various things that need to still be added, like name files for unit types, hot keys for the non-game applications, etc. All in all, I will be kept busy.
How long will the beta last? I do not know. My goal is eight to twelve weeks, but I am not firm on any of this yet. Give me some time to see where it is. I have stared at this program for quite a while, and it will be nice to have fresh eyes on it to give me some perspective on how much more work is yet to be done.
So by the time of the next report I will be well into the beta period. There is still a great deal to do, but hopefully I will begin to have a handle on how much effort it will take before EDEE will be released.
Update: September 13th, 2004 - Beta Is Closing In...
Development work continues on Empire Deluxe Enhanced Edition, but the end of the "to do" list is fast approaching, and this event will soon cause the beginning of the end of development, the beta test for EDEE.
The unit database has been worked and reworked, with some attributes added and others removed. A couple of new attack types have been installed, but these are basically variations on other move attacks and range fire attacks which only work on landed units and such.
The combat system has changed somewhat in the way the probability of a successful attack is calculated. I had kept the original combat system of proportional weights for attack, defense and terrain modifications…which was perfectly fine for a closed set of units. However, with the ability to add units, and with the design that has allowed this to happen, I have found that this system over-complicates both the unit design and maintenance of a unit set. Therefore, attacks by units against other units are now direct probabilities instead of weights placed into a formula. To the game player, there will be no apparent difference. But I think this will be much easier on the unit set designer.
Speaking of combat, I have added a Battle Odds Calculator in the Unit Editor. I have not put it in the game yet, though that will be a simple task. It is definitely another tool that has aided unit design.
And speaking of probabilities, I know one of the more controversial points of Empire Deluxe has been the random number generator (RNG). Many players have claimed the RNG in ED is unbalanced and rigged in some way. Last year before the release of EDIE a spent a good amount of development time looking over the RNG and determined that this was not the case. I think the display of the cumulative odds in EDIE has helped dispel much of this to the players. I have sought to find a better way to remove the mystery of the RNG from EDEE, and as a result, I can announce I will be using what has been titled "Mersenne Twister", created by Japanese Mathematician Makato Matsumoto. This RNG has been studied and is widely recognized around the Internet community of RNG developers, and Mr. Matsumoto is generous enough to provide a free license for its use. (Which undoubtedly is a huge thing for me). The source code is available from his website at http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html for those who truly think the RNG is out to get them. A Google Search on "Mersenne Twister" will produce many results, with source code in several different programming languages as well.
Another unit has been added to the Enhanced set. This will be "The General", who essentially fights like an infantry. He will be used in Regicide games, although you can set up a regicide game to focus on another unit type. Like "The Flag" (used for CTF), this unit will not be produced by cities.
Alliances have been revisited with some code cleaning work on several of the alliance types, especially "supply", "spot", and "reveal". I am very pleased with how alliances have worked out, and that along with player gifting should make for some interesting multiplayer games.
More code optimization work for the game engine itself has been done. Various adjustments to the rules (i.e. Game Engine) have been made as well. I have no doubt more adjustments will be made during the beta period, but the exciting news is that list, as well as the database changes have been completed.
So what is left before beta? Only two major topics left. One is there are several orders and "order contexts" to be implemented. The second is some optimization work and fixes for the AI. Most of the work on these two topics should be completed within the next two weeks, which is really indicating beta might begin by the end of the month.
The orders include more detailed instructions for loading and unloading units. You should be able to order a sea transport to load two AR and two IN, or to unload one AR, etc. I will also add "No production orders" which will stop when a turn or production efficiency has been reached. This will be nice because you can set up a command queue for a city to do no production for a certain amount of turns, and then build a certain amount of units.
A commonly requested command is to have units move in formation. This really does not work well within the game mechanic, but I do plan on adding a "maintain position" order which will allow you to select a leader unit and that unit receiving the order will try to keep the same position relative to the leader. There will also be a follow unit command to chase a friendly unit.
There are some units which I am not sure I want to add, because they may not work in ways a user wants them to. These would be orders such as "search and destroy" or "patrol and engage". It may be that in each case it is still best left up to the commander to decide when to engage the enemy. This will experience further review this week.
As for the work needed to the AI player. Several quirky behaviors have bee identified that need to be corrected. Also, his code is not yet optimized, so it can be sluggish at times. There are also some minor interface issues that need to be cleaned up, and the code needs to be made a little more presentable for the beta AI people.
The only other issue that seems to have crept onto my pre-beta radar is the behavior of the client in local games. It currently uses the windows message loop for processing the next unit to move. While this is wonderfully completely thread safe, it seems to give it a slightly sluggish appearance at times, and I will probably want to move it out of this. With the way the architecture is structured, this should not be too difficult a task. I may wait for beta before doing this, though.
So beta is drawing ever closer. I suspect possibly next week I will have sign up applications for beta, and it will be starting shortly after that. We are definitely closing in on the start of beta. There is an awful lot to test and guarantee, so I cannot yet say how long the beta period will be, but there will be nothing "new" to add to the game, so it should move right along. Very, very soon, others will be looking at the game. This is hard to believe, because I have been staring at it for eight months, though it seems like eternity. But the new age of Empire is finally on the horizon…
Update: August 30th, 2004 - Looking Good, Looking Ahead
It is clear to me now that the home stretch for beta has begun. There are still several items to be done, but they are all very concrete issues that are essentially known quantities and will not take too long to smooth out. Every day the list of these get shorter rather than longer. I am beginning to feel the excitement build inside as the beta test draws ever closer.
The interface is now what I consider to be "beta-ready". The game interface has production reports, status reports, unit reports, actions, hot keys, menus, and tool tips. The "Game Viewer", which allows the "server" to watch an all AI game has been re-written and is also beta ready. When a part of the server, the Game Viewer can also start a remote game in which it is not an active player, essentially acting as a dedicated server. After release I hope to produce a non-graphical dedicated server, which will be capable of running on Win32 or Linux. But for now this will have to do.
But there is another exciting aspect to the Game Viewer. When a game is completed, it can be saved in what I am calling a "Final Save Game". This Final Save can be reloaded by the Game Viewer and replayed! Game recording is now taking place…essentially, the events for the game are saved as part of the saved game and played back. This recording is not the full set of events that occurred during the game, however. Recording everything proved to make for a huge save file. Many events deemed unimportant are stripped or removed completely. Most notably unit movement points and unit orders are not accurate in the replay, as this data has been discarded. I plan to revisit filtering even more data before the release of the game. Currently, I would not recommend recording PBEM games of any real size (recording a game is an option). The file will eventually just get too big to shuffle around.
Speaking of PBEM play, PBEM is now set up so that every game is "secure", without a separate security file. To begin a PBEM game, the originating player sets up the game and then it is first passed around collecting player names and passwords before the map is created. This will prevent a player from cheating and getting an idea of what the world is like before the game starts.
In EDIE there is logic to process several turns in a row for a PBM game. The EDIE code cuts the timing of this very close, and I have been sent a couple of case over the past year where a player can get a half-turn ahead in certain situations. With EDEE, this problem has been made more complicated this time around by the liberation of the unit data. Now the limits of unit ranges and movement capabilities are less hard coded, and there are now more possibilities for turn overlap. I have new logic in place to process as many turns as possible using the active Unit Database, but it is conservative, and PBEM players can expect games to start a little bit slower than they did with EDIE. Also, actions such as making/breaking treaties and giving gifts to players will not be allowed early in an PBEM game (though there are treaties setup in a scenario). If such actions are deemed important at the start, I would recommend playing the beginning of a game under a network setting, then switching to PBEM - actually, this is already recommended for EDIE, because one hour online in the beginning can shave two months off your game at one turn a day.
The architecture is beta ready as well, leaving only some in the area of Unit Database, Game Engine, and Computer Player that need to be resolved. I know I mentioned some vague details about what was going to be done in these areas. I am now working on the few additions and changes to the database, and will also be adding the orders and other aspects of the game engine this period. The AI is showing some slowing speed-wise after a few hundred turns, and this will be examined and resolved. This code has not been completely optimized yet, and he still does a few things brute force.
So now I am actually thinking about how the beta will be conducted. I have received several emails from people over the past few months wanting to participate. I suspect I will have about 30 beta people participate. Though all testers will be selected at once, there will be two "waves" of tests about two weeks or so apart. I will have a sign up area set up where those interested can let me know. But please do not be offended if you do not get to participate. There are so many requests, but I am one person and it has to be kept at a manageable level.
The beta signup certainly will not happen within the next two weeks, but after that it is possible, so I want to mention some things about beta testers that I am sure I will repeat.
I will step on my soap box and say up front that what I have learned from the betas for EDIE and PGIE is that not everyone is able to do a beta test even though they want to.
There are people who have a hard time understanding what an "unfinished" product is, and that artwork and sound is yet undone, bugs and crashes do occur, things get changed, things get added, things get removed, and some code has not been optimized. If you are really wanting to just 'play' the game and not 'test' it, I would highly recommend you wait till it is completed so that your experience is not spoiled. I am guaranteeing that there will be a demo out before the game is available, so you will get to see it early and decide if you enjoy it before release time.
Also, sometimes beta tester want elements of the game changed. I am interested in these opinions, and many of my former testers can tell you how I am eager to hear them. I am not interested in just hearing what 'sucks' (these people often fit the description in the paragraph above), but how it can be improved or changed. I am very open minded when it come to ideas and criticisms, but in the end, a final decision will be made based on the focus for the game as a whole, and not from an individual's perspective, save for mine. Yet, I will say beta testers influence the final product greatly. For both EDIE and PGIE, what started in beta was nothing like what was released, and that is due to the efforts of the testers. The prospect the EDEE will 'evolve' once more before release is very exciting.
At times testers expect immediate resolutions to their issues. Sometimes, especially early in the beta, I get hammered with comments and requests. You cannot expect a response to everything that is sent. Unsolicited periodic reports from testers are awesome, and often quite uplifting. I log al reports, but things are scheduled and sometimes do not get put in the "next build" because that area was not covered. There is nothing wrong with inquiring what happened to an idea or issue that is still a problem, though. Also, do not assume I see something that is blatantly bad or broken.
I do not expect super-human efforts, and I do not want burn-outs. Do not feel guilty because you have a life. I want people to enjoy themselves, and be capable of enjoying the game post release. I do not give away free games for beta work, and the only expectation one should have from the test is the opportunity to help shape the game and credit in the manual upon release. You are compelled to destroy everything I have given you when the beta period ends.
Stepping off of the box and with those things being said, I will be hoping to have a few people "focus" on some subject areas. I have not fully thought out the areas yet, but certainly they will include dabbling with the AI code, creating unit sets, working with map and scenario editing, playing network games, playing solitaire games, and playing email games. There will be more details to come on this as time goes by.
I know I am delinquent in posting screen shots, so I dedicated an hour today and took several. I will post them in the forum. I will then dive back into building the game. Beta will not be too far away after the next report or two, and then after that I will start looking forward to the demo and release. I'm really getting pumped up about it. It should be a great deal of fun.
Update: August 16th, 2004 - The Momentum Begins To Build
It has been a very exciting two weeks for the development of Empire Deluxe Enhanced Edition. I have spent nearly the entire time working through the interface, and I am now becoming quite pleased with how it is turning out. I have yet to send it to the play testers, but will some time this week…and when they get it, I am sure they will now jump for joy as they have many of the working features including queue sorting, action short cuts, to graphic annotations for various unit states, to much faster map drawing and other performance issues.
For many, many month the interface has a little been slow and had generally one way to do things, sometimes not very easy. The game was playable, but the interface gets in the way of the "fun" part by making certain actions difficult. Now several features are fully implemented to make the interface easier to handle. In brief, some of the features I implemented are:
Bind-able Hot Key Commands - the player can configure the hot keys used in the game to the settings he prefers.
Annotations for various unit states - Units that are now in states such as crippled, dug -in, sentried, readiness value, and sighting age are graphically marked on the map. These can toggled via menu (or hot key) commands.
Action menus - these are popup menus on the map that allow you to perform what I call "quick actions" on a unit, such as Sentry, Wait, Clear Orders, Production Menu, etc.
Pending Unit Queue control and sorting - the user now has the capability to move a unit to the front or back of what I call the "Pending Unit Queue". This is the list of units that have not executed their orders for the turn. This list can also be sorted by location, movement points, and a few other criteria. The user can also specify rules such as "don't ignore sentried units" this turn, forcing such units into the queue to be reviewed by the player during the turn.
Unit Reports - different views for looking at and commanding your forces. This includes displays listing only producing units, enemy units on the map. Also, the quite familiar "Status Report" is back, with options now to view the stats based on individual opponents.
Unit Tool tips - top units displayed on the map can be examined in detail by putting the mouse over the unit.
These features and much more have kept me busy on the interface. The interface work is also building momentum for moving into beta. There is still a good amount of work to do, but I could hazard a guess and say beta may be within six weeks…but do not hold me to it.
I do have a few more interface features to put in at this time, and then I need to re-tool the interface to appropriately passively view a game. (for example, when only the AI is watching).
Beyond that, my pre-beta to-do list has three major areas that need addressing. These are the completion of the implementation of orders for units, unit database schema changes, and tweaks and additions to the Game Engine and infrastructure.
There are still a few orders that need to be completed. Some orders have different "contexts" to them depending on who gets them. Some orders will be useful when used in combinations with other orders. The biggest missing order right now is the equivalent of the LOAD command in EDIE. Units still at this point can only be loaded in the alpha by either manipulation via the unit tree menu, or by moving a unit onto the transport. Additional orders to a transporting unit to load or unload a specific type of unit will be nice for the micromanagers among us. I would also like to add "No Production" orders that will wake up a unit when it reaches a turn or a certain production efficiency.
There are several small items in regards to the unit database schema that need to be changed before the beta. Implementing these will hopefully make the beta period more stable, and allow some beta folks time to work on unit designs and test them out. There are also some sanity checks in the unit database that are still needed.
The Game Engine and infrastructure changes are individually small but many in number as well. Some of the bigger items are related to game saving and reloading, as well as game play back, which I still a feature I am unsure as to what level of detail the games will be replayed. Many little things involving orders and general game mechanics rules need to be filled out. It will be important to get through these before the beta so that the game program itself becomes tested and thoroughly tested during the beta phase.
So that is basically where I am heading, and as you can see, it is getting into the nitty-gritty. In regards to beta time, I will say I can definitely see that time getting closer. The time will soon be here, and after that, the game will be reality.
Update: August 2nd, 2004 - Into The Interface
The missing pieces of the logic for the AI were wrapped up last week. This is an important milestone, because it finishes all of the "missing pieces" in development. Namely, the only things remaining are items that need to be filled out or expanded, but not invented. In other words, the work is much more technical than creative. Now, I can turn my focus towards some refreshingly new subjects, such as chopping down the to-do list and working on the Interface, and move the game towards beta.
The only portions of the AI code that are missing are some architectural type operations, such as the saving of the 'extra' data that the AI player produces, and the parsing and interpreting of script data…both of which I will explain a little further.
Within the API, there is a class called a "Game Unit". This represents a unit or sighting that the player knows about. I have inherited from this class to create the "AI Unit". It has additional information not included in the Game Unit. This additional information is the only part of a unit that the AI DLL must be prepared to save to a buffer, which will be given to it by the game engine.
When a game is saved, the game engine will inform the AI that it needs a buffer of data that represents the saved information. This data will be stored with the saved game file, and then sent back to the computer player before the game is restarted. The other information regarding unit locations and such are obtained via a "Player Data Event" which is sent to each player by the game engine to initialize the player.
The AI player I have developed has several lists of unit types and values. These represent the various tweakable values of this particular AI player, such as how many transport will be working on a single capture a neutral city mission, or a list that describes what unit types are to be assigned the task of conquering cities. This data is stored inside the AI player in a default manner, or will be available to be submitted as a player script. This will enable a user to change the strategy of each AI player somewhat, or incorporate some new types into an AI player's game plan.
It is now the beginning of August, and when I had originally scheduled the work for Empire Deluxe Enhanced Edition, I had hoped that by this date I would have been in the beta period and heading towards a release…but as you know from earlier reports a secondary list of things not yet completed had emerged. The scope of EDEE turned out to be larger than I had anticipated.
There are many items regarding the interface on this list, which makes it a great place to start. The user interface is now next on my agenda to address, and I will be working on it during the next couple of weeks.
I have re-organized the "to do" list, and will now begin to focus on removing the items from it as they get implemented as well. The rate of reduction of this list will give me a good sense of when beta can begin. The list does not need to be cleared, but it does not to be greatly reduced.
As I mentioned many reports ago, the current interface has been useful to test various aspects of the game, but is not really good enough for enjoyable game play. It is now time to prepare a better interface that can be polished and refined during the beta. (This will be much to the cheers of the play testers). This will mean that hopefully soon we get to view more screen shots of the game, as the interface will no longer be considered just for Alpha development.
What I lump into the topic of "interface" is much more than just the graphical presentation, though that is obviously an important part. It also includes the code for allowing the human player to manipulate his units, view reports on assets, select an ordering strategy for which unit will request to be moved next, deal with unit production, and retrieval of details in simple way. I will add popup menus and popup information to the map, so that certain information and control of the units on the game board can be done in simple and quick steps.
For the next two weeks I have scheduled some intense work, and hope that many things will be removed from the list. EDEE has turned out to be quite a tremendous undertaking both in scope and scale. I it will be a great game when it comes out, and though no longer vaporware, it is not presentable or polished.
I am hoping I can come out with a beta prediction soon, but will restrain myself from trying to rush into such things. I will produce some more screen shots in the near future as the interface gets shaped up. I am sure many people are ready to see them.
Update: July 19th, 2004 - A Future AI Challenge
I have worked on the computer player for quite a while now, and I am beginning to finish up the odds and ends that need to be done with him. This should be wrapped up within the next two weeks, possibly a little longer with some infrastructure adjustments for computer players, and then my attention turns to the interface and polishing the game for beta.
The AI is now making full use of engineers, building roads, laying and clearing mines, constructing ports and airbases, as well as building resource facilities for better production. Supply units are being built and stored for later use. Aircraft are supporting missions, protecting units and transports from enemy counter attacks. Satellites are being built to both explore and spy. Capital ships are coordinating with other units to attack the enemy.
There are still a few missions left to be coded. For example, the game plan for submarines has been designed, but not yet implemented. I need to refresh the logic for buy point and placement situations, as well as special games (CTF/KOTH/Regicide)...But the vast majority of the mission assignments and logic have been built and tested. Code also has to be cleaned up and re-organized to make sense for those who are going to examine it.
As I have said in previous reports, the source code for this AI player will be released for use with external AI projects for the game. There has been a good deal of discussion in the forums lately regarding coding and the AI. Interfaces to other languages will be possibly to build, but I would highly recommend staying the C++ vein if possible. There will be a great deal of code written for you if you do this. If not, I suspect the effort would at least be doubled. Performance may also be an issue.
The AI as implemented is not for beginning C++ programmers, though it may be a good exercise to cut some teeth, grappling with the source on the whole may be overwhelming. I do not believe the code is obfuscated, but I do take full advantage of inheritance and pointers and references, etc. If you are not as experienced as other programmers, I would recommend first building the AI as is, then searching for one aspect of it that you want to improve upon and dabble with that. This will give you a better feel for how it works.
I have said many times the building the AI player has been quite a challenge. So much so that although I have complete my design as I had planned, I do not feel the AI is as tough as I had hoped for. I do believe he is better than the AI for EDIE, but only slightly so. I had hoped to make the AI much tougher, but that proved to be too great a challenge, and somewhat of a personal disappointment. I was hoping for a computer player that would challenge an experienced player such as myself a bit more. Hopefully, such a player is possible.
All is not dark and gloomy in the AI world. As before in ED, with handicaps the AI player can be adjusted to be more of a challenge to you. I will proceed with completing this player and moving towards beta. I am sure the AI player will improve over time, both through pre-beta and during the beta. As it gets exercised, observations by others and myself will surely lead to improvements and enhancements.
I know I will still want more beyond this. Therefore, I am planning to announce a contest shortly after release. I certainly have not thought of the details yet, but the contest will begin after a few months post release, to insure the API is stable and ready for others, as well as give potential contestants lead-time into development. I will make a challenge to ED AI developers to pit their own designs against my AI player. If they are able to 'qualify' by beating my AI in a best of three or five match, then they will be seeded and bracketed in a head-to-head competition with other qualifiers. There will be prizes for the top players of the bracket (most likely a little cash), and possibly even for those just qualifying. More details on this will come upon the game's release. It does sound pretty exciting when I think about it.
So this is probably the last couple of weeks I devote to the focus of AI design and development. There are a couple of things that I want to adjust in the infrastructure to accommodate the computer player that may take a little longer, but I will not be focused on the logic and implementation of the computer player after the next reporting time. I will move towards chopping down the to-do list and making the interface a good one.
It is a challenge to do so much work internally, and not have big, easy to understand milestones to celebrate externally. But this is the challenge of working on the project as a whole. I expect to see a great deal of outward progress and some real traction towards getting to beta soon. Then we will get some screenshots, and gear up towards getting others to look at it, which will be a busy and exciting time.
Update: July 5th, 2004 - Sculpting The End Game
The patches for both EDIE and PGIE have been released, and are available on the Killer Bee website. EDIE is now at 3.514, and PGIE is now 2.03. And if you read my forum in the past couple of days, you will see someone has already uncovered another issue (very minor) for the Battle Odds Calculator and the Standard Game. It never ceases to amaze my how much there is going on in EDIE. I appreciate the mail from people thanking me for putting out patches and maintaining the game. I know that has been something missing from ED until a year ago.
In regards to EDEE, I am still hard at work on the Computer Player. I have moved from the expansion parts and I am now working on him being effective taking cities from other players. Assault troops are now supported in the field by artillery and aircraft. Cities are now being defended by anti aircraft guns, and bombers are also striking at cities. Artillery is proving very powerful on defense, possibly too much so. This will take a little more study.
The computer player is having some difficulty closing a game. He is able to work a player down, but then does not seem able to effectively finish him off in a timely fashion. He is not currently massing his forces properly for a finishing blow. I am working on correcting this now.
This has been one of the challenges of writing the AI. You try several things, and some of them work as you've expected. Others don't work the way you wanted them to. In fact, some actions that seem like they would benefit the player are really detrimental. So building the AI player seems very much like making a clay sculpture. Making the outline is often not difficult, but refining it down to details can be a challenge, and certain portions may have to be reworked several times.
I think I am going to have to be resigned in knowing that the advanced and experienced Empire player will probably tear my AI player up pretty quickly after playing the game. But hopefully the AI will present some challenges. It will be very exciting when others tweak my code or produce their own. My AI needs to be generic to fit many different situations. I am sure players will create AI's to play particular game styles much more effectively. These will be exciting to watch grow and play.
I have added the escort orders to the game engine, as well as a unique patrol order called "Patrol Location". This patrol command will assign a location to a unit and it will move around while staying in close proximity of that location. Escort is very similar, except it focuses on a unit and not a location. I have also added a couple of other minor orders. I have not yet implemented my "Search and Destroy/Patrol and Engage" orders.
I still find myself wanting to move towards getting the game out, but there are still some things left to be done. I do hope to be finished with the AI in general this month, and to be working on the interface this month as well. If I am in that position come August, then things should start rolling towards beta. I would like to get the game out and have people playing it, but it must be ready first. I will not rush it.
So work on the AI player will continue, though I am beginning to see the end of that. With the shape and reshape nature of some of the AI development, I am sure it will be an ongoing project and never be perfect. Again, I am very eager to see what others do with the API.
Update: June 21st, 2004 - Conquering The Neutrals
The past couple of weeks of EDEE development have not been quite as slow I first had anticipated. The patches for EDIE and PGIE have been prepared early and there was some more time to work on the computer player.
The patches were successfully built a little ahead of schedule and should be released in very short order. They cover a few minor issues that have surfaced over the past 6 months or so with both games. Programs of this size of complexity will never be perfect, just by the nature of what they are and how they are used. But I have been pleased with the bugs that have been caught and squashed. This is due to those whom have taken the time to send me descriptions of possible problems. Thank you. You have made the games better overall.
The work on the two Internet Edition games has put the development work on Empire Deluxe Enhanced Edition in perspective. In several ways, EDEE is larger in scope and presence than EDIE and PGIE. The ability to customize more parts of the game is a big reason for this, as well as the migration to a client server architecture to allow for more portability as well as more coherent online play.
Being so involved in creating and designing the game, I had not realized the size and scope of the program compared to EDEE before. It is now of no surprise that the game has been delayed, and though I was a bit disappointed at the time, it would have been foolish to try and rush it. Work is progressing on the AI player, and soon I shall begin to head towards beta without being overwhelmed.
I had asked for some tests to be conducted in regards to human player expansion on an old EDIE map. The purpose of this test was to give me some general idea as to how quickly and effectively human players expand. Expansion is very important for the computer player, because it determines his capability to wage war once he has come into contact with you.
I have a few maps of that 50x50 size in EDEE that I have run several tests on many times. Each map presents some problems for the AI, and I have been working on generic solutions to these problems. The EDIE test is different from the similar tests on EDEE for a few reasons, such as additional North-South wrapping and neutral cities are dealt with differently in combat (more on that in a moment).
AI programming has been a great challenge and a lot of fun. This player I very "mission oriented". Once he has determined a mission, like 'take a city', he requisitions transports, attackers and supporting units to do the deed. Once he has the right number and types of units to execute the mission, they work together to attack the objective. It has been a lot of fun determining how to prioritize and effectively carry out these missions.
I still intend on releasing all of the AI source code for this player with the game's release, and I suspect others will have a grand time improving on and creating new opponents. If you are going to want to work on it and are not familiar with the basics of C++'s Standard Template Library, STL, make sure you read up on it.
This player I am creating does appear to have his limits, and I am sure the experienced Empire player will still be able to show him who's the boss fairly effectively. I have added a "Neutral City Handicap" which made aid the AI player in expansion, while not giving him an unfair advantage in combat later in the game.
When Empire Deluxe was initially released in 1993, combat against neutral cities was the same as combat against enemy cities. This meant that you could go up against a neutral city and lose several times before winning. As I recall correctly, after release, many people complained that this was hampering their expansion phase of the game, making it less fun an more frustrating. Due to this, Mark and Bob patch the game where neutral cites would defend less vigorously every time they were attacked. No combat was ever a sure thing, but the odds did get better. (I can still remember games though where I was burned thinking I could take a city in 2 attacks or so).
In addition to this, "Combat Level 3" was patched to specially set up to be an automatic win over neutrals. Unfortunately, combat level 3 was also a very high combat handicap, and to even the game it had to be distributed evenly amongst all the players.
For quite some time I have considered having three game "options" regarding the combat with neutrals. These were "No Distinction" (neutrals defend the same) , "Diminishing Defense" (neutrals defend less with each attack), and "Always Win" (neutrals can never win). However, after playing with the AI somewhat, I have developed what I call the "Neutral Handicap". This is another numeric value, from 1 to 500, with 100 as 'normal', which will be used to determine how neutrals defend against the player's attacks.
This neutral handicap is different from neutral combat in EDIE for a couple of reasons. First, it is on a per player basis, as all the handicaps are. So conquering neutrals could be easier for one player versus another. Second, it does not count the number of times a neutral city has been attacked. Instead, it directly effects the defensive weight of that neutral city when you attack it. The odds will remain the same on every attack, determined by the game engine which will take your neutral handicap into account.
I suspect the game will be released with a default "Neutral Handicap" for each player for something like 50, which would roughly translate into a 66% chance for an Infantry to take a city. You could adjust it to 1 to make it an "Always Win" situations (though there's always a 1% chance of losing), and you can adjust it to 100 for the "No Distinction" setting. (50 % chance on every combat with Infantry).
For the next two weeks the main focus of the work will still be on AI programming. This work also includes game engine additions and corrections where needed. But I believe my focus is going to turn towards the computer player moving units to the front, as well as focusing on several other secondary mission types like patrolling and defense. Once I feel the AI player is set, I will begin to work on the user interface, and then maybe a few screens can come out. But that is still a little bit away yet.
Update: June 7th, 2004 - Expanding and Patching
Not a lot to report this session. I have worked mostly on the AI, though other elements of the game have been addressed somewhat, and there should not be any great dramatic progress in the next two weeks, because its time to catch up on some things that had been put to the side months ago.
I have put a good deal of focus into the AI player. I have been looking into his expansion a lot. Expansion is a challenge, because if he makes several early mistakes in expanding, it puts him behind when he meets you, and then will have difficulty actually performing anything viably offensive.
AI Expansion becomes a challenge because the map changes every time. And there are subtleties about the map that a human can easily observe but the AI cannot. I am still not quite happy with the early expansion time yet for this player, though it has gotten better in the past two weeks. I now see why other game programmers find it so easy to allow the player to cheat, essentially to help him make up for such subtleties. I firmly feel the AI will do an adequate job with out cheating. It has been fun observing the AI and tweaking him, and I think people who want to build a computer player are going to have a good deal of fun doing so.
To test expansion times by human players, I am posting a couple of EDIE "test" scenarios for those interested. These scenarios are short and simple 50x50 wrap maps with 50 cities at 100% production efficiency. The opponent is tucked away where he should not be bothered. I would be interested in receiving the number turns it would take to capture 45 cities and then to capture all fifty cities. So if you would like to play a short EDIE game and send me the turn number for 45 captured and the turn number for 50 captured, please do.
The way EDEE is set up makes it easier to make such a test. In a game, you can have one opponent if you wish, as long as you set (or unset) certain victory conditions. I have been testing the computer player's expansion capabilities on such a map, by just creating one player and removing the "annihilation victory" condition in the setup. I then specify the percentage of cities I want captured to cause victory..
I am pleased with the way the player is attacking opponents. He is coordinating attack and support units in such a way that he should bring some challenges and surprises when he comes up against you. His rules of engagement have worked out nicely, and his actions make a little more sense in combat against opponents.
I have also focused on production management and production priorities somewhat. This is a challenge, to determine not only the immediate force needs, but to also plan the task force for 20-30 turns out.
I have yet to program in the capability to defend cities effectively, due to my focus in other areas. Units for these tasks are being produced, but not effectively deployed. But soon he should be able to prepare to defend cities that he feels your units are threatening.
I plan on continuing this AI work for the next couple of weeks, probably even longer, but for now I will also take some time from EDEE development to work on releasing patches for EDIE and PGIE. I had hoped to release the EDIE patch back in February, but time slipped away, and since there was nothing critical in the patch, it was tabled. Since that time, a few items have arisen and I want to incorporate those and put out the patch, and this is the time to do it. So there should be some effort put forth on patching, and we should see some patches soon.
The AI player has also exposed issues within the game engine both bug-wise and performance-wise. When such issues have arisen, I have taken the time to address them. It has become obvious that waiting for the game itself to be developed before working on an advanced AI player was an important step, for missing aspects of the game would have had the possibility of adversely affecting the computer player when the feature got added.
With the adjustments in the scheduling, I foresee AI work and all that it entails going on for a while longer. So in two weeks, I will probably just about have the patches up and out, and will have continued the work on adding to and improving the AI player. The AI component is a very important part of the game and I want to make sure it provides players with a challenge. And as I work on it, I can see the potential for different and challenging opponents to be created by others after the game is released. This is really going to be an awesome aspect of the game.
Update: May 24th, 2004 - Need To Take A Little More Time
First off, there is some 'news' with this report. I originally had hoped to enter the beta testing phase of this project by the beginning of June, in order to release the game eight to twelve weeks later. I had drawn up milestones of the major features that needed to be implemented, and these milestones had been met, for the most part.
What I have not properly anticipated was that a second list of minor details would emerge, with things that need to be done to polish the game. The original intent of this list was action items to be performed during the beta period. However, this list has grown quite large and it really needs to be addressed to a great extent before I enter beta. I could enter into a beta period now, but then it is possible that certain aspects of the game may not get the attention they deserve, and the finished product would not be what I want. Also, the entire beta period would be spent with me trying to 'catch up', and I would not be able to effectively address the concerns of the beta participants.
Therefore, I am going to release some of the time pressure I have placed on this game, and I now I will not guarantee a summer release for the game. I will not give another release estimate until the project is in the beta phase.
I will say that game development is very far along and I should be able to enter into the beta phase within the near future. There are no large features to be added, just features that need to be expanded, rounded and polished. I am very interested in releasing this game, but I am also most devoted to making the quality of the game as high as possible.
So for those of you that were eagerly hoping this game would be ready for long hot summer days, my apologies. Delivery dates are extremely important to me, and I try my best to meet them. However, at this point, focusing on meeting the date, as opposed to finishing the game, would only cause the game to suffer. But I will assure you the extra wait will not be too long, and this is a step I must take to assure the game will be as great as it can be.
The past two weeks I have been heavily involved in developing the 'Standard AI' computer player for the game (no direct relation to the 'Standard Level' of play for you classic ED players). There is still some work to do. I intend to release the source code for this player, or some variation to it, so that would be AI developers will have an example of the AI API to study.
As I have stated many times, the development goal of this player is not to make the end-all computer opponent for the game, but to add a challenging player, better than the opponent in EDIE. To that extent he is more aware of his production capabilities, and he works at coordinating his attacks with several units on a particular mission. He has a good deal of focus on exploration. He also has rules of engagement, which tell him how to behave when an enemy unit is nearby or spotted. So, unlike the previous version, a Transport may not be so aggressive against a destroyer. Instead, it would probably choose to take evasive action.
I have received email from folks inquiring about the AI API. Essentially the player receives 'Events' whenever something occurs that he sees. So if an enemy unit is spotted, for example, an event is generated. When the computer player wishes to do something, he sends a 'command'. And example of a command would be setting a unit's orders, or telling the game engine to execute them.
An AI DLL itself will house more than one instance of the AI type defined by the DLL. The DLL will contain a managing object, which will route the events to the appropriate player. In C++, this code will already be written and can be reused by the AI developer. The focus of the AI developer will only need to be on the AI player object itself, and his reaction to the set of possible events and his sending of commands.
I have also been asked if the AI DLL must be written in C++, as opposed to Delphi (or even VB…) The answer to this is yes and no. The DLL is complex enough to where I suspect it will be necessary to write at least a C++ stub to communicate with the game engine, and would have to generate a mechanism to pass data back and forth. You would also lose the convenience of some of the classes I have developed to make AI development easier. So there would be a greater effort to develop an AI player in Delphi. But it is possible. When beta begins, there will be some efforts to create such a stub.
Since the schedule has been changed somewhat, I intend on spending a little more time working on the 'Standard AI' opponent before moving on to re-shaping the interface. After this Computer player is built, I will most likely customize it for the various levels of play. Also, it has being designed so that the Rules of Engagement and various other variables will be accessible through a script. The intent is that if someone wanting the Standard AI to be more or less aggressive in certain situations the data in the file can be changed to reflect this.
On the subject of DLL interfacing, I have also begun working with Fubster to guarantee that his wonderful World Building DLL for EDIE can be easily ported to EDEE. His DLL will not be a part of the distribution, but I did want to give him a head start because it is so popular with many EDIE players. Currently, it looks like there is not going to be much difficulty in this. The real trick is writing the DLL stub code that interfaces with the VB so that Fubster can work his magic. There are also a few additional features that must be in place, like the assignment of 'capitals' and the designation of CTF and KOTH areas when required. The DLL now must also take up the responsibility of determining starting positions for all the players.
Working on supporting this DLL is also an excellent way to determine what information is required for AI World Building. All of the specification information I am providing to Fubster will be available to anyone want to build such a DLL when the game is released.
So the AI will still be in focus for the coming week or two, and as I mentioned, beta will be delayed for a little while yet. Again my apologies for the hiccup in the schedule, but I am very pleased with how development has gone so far, and I do want to take a little bit more time to make it as good as it gets, so that the game will last a decade or more on your hard drive, which is of course, the Empire Tradition.
Update: May 10th, 2004 - Time To Start Thinking About Thinking
Like so many other status reports that I have filed on Empire Deluxe Enhanced Edition development, I have evaluated the past two weeks of work and feel it is moving very steadily, with great progress begin made.
Recon reports and combat reports are now in the build. The reports are available in Full and Area flavor, just like they are for EDIE.
The server now also allows for client disconnections to occur. This means that if I players drops connection while in a game, or chooses to 'log out', he will be able to reconnect without disrupting the game. This will be quite a helpful feature for multiplayer games that can run for a long time off of a server.
In anticipation of the upcoming AI work scheduled, I have added the ability for the server to view games while not an active player. This means that, if there is no "local player" in a game, but some computer or network players, the server can observe the game from the perspective of any of the players in the game.
Weather has finally been added back into the game. There are now two types of weather rules available for players to choose at setup. (Three if you count "none" as an option).
If weather is to be in the game, it can be specified to be either "Global" or "System Based".
With Global, the weather behaves very much as it does in The Perfect General. The weather affects every unit on the entire map. Players will know exactly what the weather for the map will be several turns in advance. Fog, Clouds, and Solar Flares will affect spotting, while rain and storms will affect sighting and movement. There will be no direct effects of weather on combat, though storms would prevent combat in certain cases.
With System Based, several weather systems are moving on the on the map at once. These systems can cause weather to form in squares that they cover. These systems will move slowly about the map, with their forecasts changing every turn. In the system-based case, players will be able to determine the direction in which the system will move next turn.
I have added the "Stacking Alliance" into the game. This treaty will basically put you in a non-combat type of mode with the other player, allowing you to fly over his units, or pass them on a road. Though you can share the same square with his unit, you will not be allowed to enter his cities, or load his units onto your transports.
I also have finished the implementations for limited resources and allowable builds. If appropriately setup before the game begins, resources can be exhausted during a game. Allowable builds, which are specified for each player at setup, will prevent a player from obtaining a unit with buy points, construction or production methods. It does not prevent player gifts of that unit type, nor does it disallow a player from starting a scenario with a 'forbidden' unit.
As an aside, the difference between production and construction is that production time is affected by the producing unit's production efficiency, unit specialization, and the resource drain. Construction does not have efficiencies and drains. Cities "produce" armor units. Engineers "construct" oil facilities.
It appears I am still on track for a June beta. When in June will depend on my comfort level with the game and certain work items still needing completion. But with each day of work it brings me closer to that decision. Although I would like to have the game out as soon as possible, I will not rush the game at the expense of quality, and with the large and ambitious nature of the project, I will tend to tread on the careful side as I begin to move towards release.
The biggest areas left with the most work to do are creating effective AI opponents and shaping the interface somewhat. The schedule for the AI work begins now and is somewhat open ended, for I am not sure how long it will take to produce an appropriate opponent. There are several aspects of the game I would like the AI to take advantage of, and would like it to not appear dumb. Also, I need to polish up the AI API, for this will be inspected by anyone wanting to build a computer player. My hope is to release enough AI code to allow someone with a compiler to be able to build the distributed AI DLL on their machine. This will help the AI programmer examine what is necessary to run a computer player in EDEE.
Besides the challenges that the rules and features of the enhanced levels of the game will provide, an additional challenge will be to somehow allow you to easily insert new units into the task organization with hopes of the AI taking advantage of them. I have several design ideas on this, which hopefully will be implemented in the next week or two. Still though, I suspect real effective usage by the computer player of units yet to be created units will come with specialized AI opponents.
So there is much work to be done, and I have plenty to keep me busy. A great deal has been added to the game, and some parts have been reshaped and polished somewhat. It is really beginning to get exciting. Once I am satisfied with the AI and the user interface is shaped up a bit, it will be time to get those beta wheels turning.
Update: April 27th, 2004 - Building Building Blocks
My apologies for this report coming in the morning after it's stated time. I do like to deliver these on time, but time passed me by yesterday as I worked on EDEE and was too tired to write a decent report, so I postponed it till this morning.
I have definitely been very busy working with EDEE, and the focus now is on moving preparing the game so that it will ready for beta to begin. I suspect this process will take 4-6 more weeks, so we are looking at a beta in June. The game needs to be polished a great deal more before I can allow more players to play it. The interface is very rough and incomplete in game play, and that must be addressed first. I know the play testers will be happy when the interface has been upgraded. The AI opponents also need to be overhauled and created to be challenging. There are also various architectural details that I want to have in the game before beta.
Beta gets closer with everyday and every completed milestone. At the beginning of April, I had a schedule that appeared to have eight weeks of items to be completed. Three and a half weeks later, three weeks of that schedule have been completed, so things are progressing nicely. I am sure before entering into the beta I will add a week or so on the schedule to make sure I feel it has everything it needs to move forward effectively. I suspect I will be doing the same at release time.
Since the last report, treaties were finished in the game, except for the 'new' stacking treaty. (this will be done with scheduled adjustments to the path library). Players can now make and break treaties. I believe I have mentioned them before, but since I am awake this morning, I will repeat them. They include:
Along with alliances, remember that player may also give units to another player.
If included, the Stacking treaty will allow you to fly-over your partner's units without combat. You will NOT be allowed to host a different player's units. Roads have an added benefit that ground units can pass through other ground units on a road, and this alliance would be most helpful in getting your units to your partner's front in such situations.
Treaties take time to build, but can be broken in an instant. To start a treaty, one player initiates it during his turn. On the receiving player's turn, he has the opportunity to accept or reject the treaty. The acceptance will not be sent until the end of his turn, so he can change his mind during the turn. When the receiving player's turn has ended, the alliance is formed if accepted.
This past week I have constructed the "AI Registry", the terrain database editor, and the unit database editor.
The AI Registry will be used to prepare an AI DLL so that it can be used within the game. It will provide a list of all available AI DLLs you can use, and allow you to provide new ones. The new ones are tested to insure they fully interface with the game, and then are added to the list.
The Terrain Database allows you add terrain to the game. Terrain is very lightweight, namely consisting of the graphics needed and other display information. Statistics such as movement costs will be part of the attributes of the units. Terrain builders are able to add or expand terrain types, but they must be aware that these new types will not be usable with the distributed random world building logic. Instead, the map editor must be used to build maps, or a new World building DLL must be built which would support the new terrain categories.
Conceptually, a "Unit Database" is a set of units that you can use in a game. The unit database is not a simple beast. At this point in time, there are over NINETY (90) attributes which can be edited for a unit type. Some of these are lists such as specific combat modifiers against units or the terrain costs for the unit moving on those specific terrain. This does not mean you will have to touch 90 entries before producing a unit. Some of the attributes are only necessary when giving a unit special abilities, like making it an orbital unit or giving it range fire.
Players will be able to copy units in a database, merge two databases or copy databases as well. All in all I believe the unit database editor is very powerful, and thus it is complicated, mainly due to the number of attributes available for tweaking. It will nto be difficult for the person wanting to make Infantry move 2 instead of 1, but thought is going to be required when designing new units, for the relationships between units in a unit set seems to be key.
I will post a couple of screen shots of the editors in my forum at some point today.
I have received some questions from registered users and potential buyers of EDIE regarding discounts and 'upgrades' to EDEE. EDEE will be a new game, not just an upgrade of EDIE. Therefore, there are no plans to allow users to "upgrade" from 3.5 to 4.0 . Though efforts are being made to maintain the playability of the Basic, Standard and Advanced games, there will be some subtle mechanical differences in the games, such as the relaxing of the over-flight rule and the way transports are loaded/unloaded..
I do intend on providing a discount to registered users of either EDIE or PGIE if they chose purchase EDEE, and this discount will most likely be around 10% of the cost of EDEE. If I have a presales period, which has yet to be determined, there will most likely be another 10% discount for that as well. (which can be combined by registered users for a total of 20%). I will only have a presales period if I am able to produce a demo in a timely fashion, which I definitely want to do. It is important to me that you see some of the product before doing presales. My hope is the community appreciates this, for other software shops, large and small, do not appear to strive to meet such a goal.
In regard to pricing EDEE, a final price has not been determined, but I suspect the price will be somewhere around the mid-thirties. As I think I have mentioned previously, there will be a separate "Remote Client" sold for those wanting a network suite for their homes. The "Remote Client" is not the full game itself, but a front end to play the game with a hosting player over a network. The remote client will cost less the full game. Those people wanting additional copies so their family and friends can play at home will be able to purchase the Remote Client instead of additional full copies. This Remote Client is already being used in the alpha and will be ready at release time.
So progress is being made in development, and beta comes ever so closer. In the next couple of weeks I plan on working on such things as Combat and Recon Reports, an interface for viewing AI-only games, various other minor architectural details, and then turning my attention to certain outstanding game play issues and implementing more orders. So still much work is needed, but the end is coming in sight, and beginning the beta will soon be reality.
Update: April 12th, 2004 - Building Building Blocks
Well, even with the holidays and tax-time floating around I have not been idle, and a great deal of progress has been made on Empire Deluxe Enhanced Edition. A tentative schedule for reaching beta has been drawn up, and it looks like beta might actually arrive with the beginning of June. This would land the release date for EDEE at some point in August if all goes well. There are still several hurdles to pass, and nothing is set in stone yet, but it is really starting to come together.
A great deal has been added to the game. I am pleased to say that all the major features are now in and only some minor ones remain to be implemented. However, by "In" I do not mean "finished or completed", I mean they have at least the basics worked in and there does not appear to be any thing besides time holding them back at this point.
The Capture the Flag game style, a.k.a. "CTF", has been implemented, and it will be interesting to see how challenging this will be. Players will receive a specified amount of points by finding a "Flag" unit. They must take control of the Flag by successfully attacking it, then take the flag back to their Capital City for a capture. The flag will then re-spawn at one of a few spawn points to be found on the map, for the while process to start over again.
The King of the Hill, a.k.a. "KOTH" game style is also up and running. Players will now be shown a region of squares on the map. If at the end of a turn, one and only one player has a unit in this region, he will receive points.
Player may also now designate a unit type to be used in a regicide game. This can be one or several units of the same type that will mean defeat for a player if they are all lost.
One other different type of game play is the "Important Cities" game. Instead of total or a percentage of all the cities on a map for victory, the game can be set up with the player only needed to control "important" cities. These important cities are determined when a map is built.
With all game types in, my attention turned towards Order Points. Order points are like enhanced movement paths. Instead of just receiving orders to move from A to B, a unit receiving orders from an order point may now receive a set of orders which he can carry out. Orders can also be saved as scripts for easily preserving common and detailed order sets between games. This is really a nice feature for big games, and if you are able to organize yourself, it should serve you well.
Last week I worked on the map and scenario editor, which I also have posted some screen shots of in the forum. I am please with the editor and maps and scenarios can also now be loaded and used in games. Now that this capability is in, more complex tests and games can be setup and executed.
There are still two file types used in the editor. These are the familiar Scenario File and Map file. The map file contains information on the map, resources, mines, roads and possibly neutral units. A terrain database is associated with a map, and if there are neutral units, there will also be a unit database for it. The scenario file adds players, so that the units do not have to be neutrals to be saved.
There are still several features that I would like to insert into the editor, but most likely it will be during the beta period that this will happen. I have not yet implemented the ability to make symmetrical areas, nor have I put in a converter from 3.5 (EDIE) maps. The editor will include a tool to cut, rotate and paste areas on the map as well.
I have nothing to report on the weather situation for this report, except to say that it will most likely be resolved within the next two weeks. I think I am coming up with a viable plan for the implementation of weather, and I definitely want to put it in and let the play testers chew on it a bit before beta.
Also this week I plan on finishing up the implementation of making and breaking alliances between players. Player gifting has already been completed. Both of these are not instant processes in the game, in order to prevent player abuses. For gifting, units first are turned to neutral, then during the receiving player's turn, the units are "offered" to him. If he rejects them, he will not have another opportunity to take them. The offer expires at the end of his turn, so ignoring an offer is a choice to reject the offer. Units rejected will remain neutral or will optionally be removed from play.
In regard to alliances, a player will offer a treaty to another player. During the receiving player's turn, the offer must be either accepted or rejected. If accepted, the treaty goes into effect at the beginning of the turn of the player who first offered it.
Current treaties implemented are Spotting, Reveal units, Supply, Shared Exploration and Teams. It is possible that I will re-insert "Stacking", but this will not allow units to carry other units, but allow units to 'pass-through' others, like an aircraft flyover without combat.
Next week I plan to work on the editors for both the terrain and unit databases. With the editors, a user should be able to develop his own set of units to play with, or tweak the existing values of units. It has been a few weeks since new attributes have been added to the database, though I have a couple on a list to add, so the schema should be pretty solid when the game enters beta.
So, still busy, and still a great deal to be done. But the game is really growing legs, and hopefully soon will run great. I am sure at the next reporting period the report will be similar, "lot's has been done, and lot's left to do". It is encouraging to see the list of items to be done begin to shrink, a sure sign that the game is heading towards the next phase. In a relatively short period of time, it will be ready for the beta team. And after that, it will be ready for the world.
Update: March 29th, 2004 - Victory And Defeat
This week, Empire Deluxe Enhanced Edition is wrapping its third month of implementation. A great deal of code has been written, but a great deal still remains to be done. However, this is the first reporting period where I can state the "TO DO" list has gotten shorter instead of longer. Hopefully I will begin to approach the light of the tunnel known as beta, but that still a ways off.
Email Play has now been installed into the game. Email will be a little tricky for players, because unlike Network play, the unit and terrain databases and their associated images cannot be transferred on the fly as they could in a network game. Instead, the players of an email game will need to determine what databases they wish to play with, as well as AI DLL's they might want to use ahead of time…and synchronize their copies before starting play. The database data is started from the server and carried with the saved game, but the images most certainly are not. Players will be warned if there appear to be missing images for a game before they start.
Victory conditions have been installed as well. Now players can play through games under various conditions, such as Capital Kill, the capture of a percentage of cities from the map, regicide victories, and various statistical goals such as average or cumulative production efficiency. King of the Hill and Capture the Flag games have not yet been implemented, though they are close to becoming reality, as is the scenario file format for the game.
I find myself playing some rather long sessions of the game now, and there is still much discussion in the playtest group regarding the game. The issues with weather have not been addressed yet, though over the past week or two I have reaffirmed my desire to have a decent weather implementation in the game. The biggest problem with weather does not seem to be determining what effect should be applied. It is more an issue of playability and pleasure.
Let's see, weather by nature (pun intended) is an inhibitor of sorts. On clear days, you can see fine, and are free to move, going about your operations. But if the weather is not clear, it will most likely have a detrimental effect of your game.
This is part of the problem, because weather seems to offer a great deal of 'getting in your way', which is not really 'fun'. Add to that it may just get in your way and not your opponents' way, and it becomes even less fun.
Also, weather does have a level of predictability to it, but there is also a random element to when it will appear, move, and last. From discussions both in the play test group, and in the forum, I can see that players may have hopes that weather will move the way they want it to, and that way is always to their advantage.
So that is definitely an open issue that I am still working on.
Wydraz has delivered a good deal of terrain and unit artwork, some of which can be observed in the screenshots I put up on the forum last week. As you can tell from the images, a good deal of interface work is still needed. I had hesitated to show those shots because the interface has not yet scheduled to be beautified and consolidated. But as a game it is definitely coming together, and I wanted to show you folks some of what I am seeing. I will try to post a few more this week or next.
I am currently working on the implementation of something that will replace "movement paths" for the game. These are currently called "Order Points". Order points are essentially a set of orders assigned to a location. When a unit enters that location and has not further orders, it may end up acquiring a preset set of orders from an Order Point at that location. Obviously, this can include movement orders, and a great deal more.
This week I also plan to allow players to save sets of orders as order scripts, so that the use can reload the script at a later date or in another game, and with some data tweaks on some of the orders, units will be able to execute the orders in the script.
Also in the near term the plan is CTF and KOTH game play, as well as clocks for play, and a rudimentary Map and Scenario editor. Hopefully those will be completed before the next report.
I would say at this time an early May beta test is out, and the month of May might not see a beta at all. I will keep you posted as soon as I get a good feel for the beta and subsequent release.
So for now it's back to the grindstone. I know I have been pretty quiet in reporting and putting up news on the 'Buzz', but I have had much on my plate. Thankfully this report lets you know that I still have some sort of a pulse, and things are moving in the right direction. As always, feel free to mail me and post in the forums, and I will try my best to address it. EDEE is really shaping up, and it will be an awesome strategy game when it is finally released this summer.
Update: March 15th, 2004 - Vaporware Nevermore
I have evaluated where I am in the development of Empire Deluxe Enhanced Edition, and it appears that I have reached the half-way point. This is glass half empty/half full situation. While I have accomplished much, there is still a lot to do. The best think about the second half of development is that is when the momentum begins to build, because features slowly become finished and progress becomes much more visible.
I have installed the networking components for the game, as well as the components for loading and saving games. There are still some network issues that need to be implemented. I would like players to be able to disconnect from the server at anytime, and reconnect at a later time, without disrupting the game. This will enable servers to be set up and played by several players remotely over a longer period of time than your average network game time, as well as offer more stability for network games. The hope is that players with the resources to do so would host games that could be running for days or longer.
I have also been implementing how data was going to be transferred to start a game. Since the game is customizable, one cannot guarantee that they have the same unit and terrain database information on each client. All of this information must originate with the host. While the information itself is not too difficult to transfer quickly, the supporting images for the units and terrain are a slightly heavier bandwidth burden. A protocol has been setup to where the client first checks to see if the images are available locally, and if not, will request that they be downloaded from the server. This is done before the game begins, so it will slow down this process. It will still be recommended that players share and install the same database before connecting to save time.
Email play has not been installed yet, though that is essentially the next step in my plan. Players are now able to save and load maps, though there is not an editor component to the game yet. That is also on the list of things to be done soon. Scenarios cannot be save yet...again it is coming soon though, as well as a converter for 3.5 maps, to assist with testing.
There is a difference between the concepts of EDEE maps and scenarios and EDIE/ED. In EDIE, cities served both as a terrain type and a unit type. Now, cities are purely a unit type. So maps will have no cities on them. Scenarios will. Therefore, all 3.5 maps will be converted into EDEE scenarios. EDEE scenarios may fix the number of players available, or leave it open. Therefore, a scenario with just neutral cites is still valid, and the game will use either a special function or a specified DLL to provide placement for players in such a situation.
The installment of saved games and network play is news to the play testing group, for they have no received a delivery in the past 2 weeks. I had warned them it would be a while, as I put the networking piece in. Just when I think I am ready to deliver, I decide I want to install one more piece into the program. I do not see it as a big deal to them, for there have not been any game play changes implemented in the past couple of weeks. But soon I need to get them the ability to save games. I am sure they are looking forward to these features, as well as additional interface features which have yet to be put in.
They have been very busy though, commenting and debating various aspects of the game. The one feature which has encountered the most controversy at the moment is the current implementation of weather, and it has been put back on the drawing board. I definitely believe there is a place for weather in the game, and would be very interested in hearing your ideas on the subject either through email or in the forum.
Wydraz has sent me what I am calling the "classic" unit set. This is a unit set that closely resembles the way units were presented in previous versions of Empire. Again, his work is most impressive. I am most pleased with it and will be sharing some screen shots of it soon. I do believe he is working on another unit set as well, with a different look. As always, graphics will be customizable, so great sets such as Dietmar Varga's set as well as other graphics can be brought over from EDIE.
The scheduling for the beta and release are slowly moving towards the front of my mind. I still am not certain when beta can begin. It will be at least May, and possibly later, I am definitely trying to prepare for an early July release, which would demand an early May beta. However, I will not hesitate to delay this if I feel a few extra weeks will provide better quality and maintain the feature list. Such a decision has yet to be made. I would say in the next month or so this should become much clearer. As I said, there is much to be done…but I certainly do not consider the game vaporware anymore…
Update: March 1st, 2004 - And Work Continues
Development on Empire Deluxe Enhanced still continues to move forward. Another two weeks and a lot more features are in the game, and a couple of things are out. The play test group has held several discussions concerning a varied range of topics, and Wydraz has begun to produce some art.
All of the aspects of a single player game are in the current alpha build. All units can be produced, and used as they are intended to be used. In this first week of play testing four versions of the alpha have been delivered.
The game is not yet playable for entertainment to any great extent. There is only the minimum set of orders available to the user, mostly move, sentry, and production orders. However, some complex orders such as "Explore" have been added. Many more will be brought online before the beta. Also, various interface 'clues' that we sometimes take for granted, such as the loaded icon for a unit or the annotation of a unit's sentry status has not yet been implemented.
But the play testing group is now able to examine how artillery combat is behaving...and launching missiles and satellites, and how powerful should they be. There are able to build roads, perform nuclear strikes, setup anti-air defenses, digging-in, dropping units from an air transport, and suffering the effects of bad weather, to just name a few of the new capabilities. The group is definitely taking a good approach to the play test, and there are a lot of questions of the various aspects of many of units. It does appear the alpha has been playable enough and stable enough to allow them to explore some of these features. I am pleased with that.
The first computer opponent, whose DLL is appropriately named "ReallyDumb.dll", has made his debut. He's not too bright, focusing on the land war and sometimes not choosing the best target of opportunity. Hopefully, he will improve as the weeks roll by. Still, the game plays ok with three or four "ReallyDumbs" on a 50x50 map. If they find you, you will have trouble.
"Really Dumb" is really going to just be a test bed for various ideas in writing the AI for the game which will then be translated into various other AI DLLs. Again, each AI DLL interfaces with the game so that the player may choose as many of a particular type as he wishes, so if I have three AI dlls called A, B, and C, , I can have seven opponents in a game if I choose to, 2 from A.dll, 3 from B.dll, and 2 more from C.dll . This is a very exciting aspect of the game.
One big feature of the game has been cut so far, and that was the "simultaneous games" feature. This is something I wanted to add to EDEE very much, and I find the concept of bending the Empire game mechanics to work with simultaneous play very intriguing. However, it has become obvious that to do this would really mean writing two separate games, which would stretch the testing of both thinner than I would care to do, as well as impact the other features that have been proposed. It has been decided that this feature is far enough removed from regular Empire play that it would not be worth the time and risk. Hopefully, in a future game this can be examined. For those, who like me were in some way looking forward to it, I apologize, but it is best for the overall quality of the game.
There are several major features now missing from the game and will be added this month. One of them is the ability to save games. It will still be a while before this feature is added…the same goes for a map and scenario editor. The major feature that I am working on this week is network play, and I hope to have the game network playable by the end of this week, or close to it. With socket play in place, the scanning logic of the game can be fully tested, as well as the alliance/treaty aspects. I am sure socket play will be much easier to enter into than it was with the "Remote Slave".
And speaking of alliances, I had previously mentioned on the forum that players could enter into what I called a "Stacking Treaty". This feature has also been cut, due to the amount of information that would need to be shared amongst players, more than I preferred to do. If players want another player to transport units, they can workaround the absence of this treaty by "Gifting" the units to be transported to the other player and that player in turn "Gifting them back once they have been dropped off.
Other treaties are still available, and should not suffer the same fate as the Stacking Treaty. These are Shared Exploration, Shared Sightings, Shared Supply, Revealing of forces, and Shared Victory.
So it has been and will continue to be a busy time for the game, and much is still in flux. I suspect after this month it will really begin to settle down as I begin to set my sights on a beta period. Not sure when that will begin at this point, but it is now becoming apparent that the game is moving towards that time.
So the next two weeks will be pretty much like the last, more orders added, more features installed, more aspects of the game studied and debated. Hopefully, not too much else will be dropped - at the moment I don't anticipate it will be...Also, I feel it is getting near time for some alpha screen shots…I am only reluctant because most of the graphics are by my hand and not that of the talented Wydraz. My artistic abilities are arrested at the Pre-K level. But I will release a couple of screens shortly with that caveat.
Update: February 16th, 2004 - Fighting and Transition To Another Phase
It's really funny, but in these development stints time seems to stand still, yet move so fast. Making progress is a continual quest, and though and times seems to be so slow when issues must be worked out, when you step back and look at what has been done over the past two weeks or so, the game has made great strides.
With movement and spotting essentially done last time, it was time to tackle an important component of the game, combat. Combat is now in the game in various forms which I shall try to describe.
In the unit database, each individual unit type is assigned an attack type upon another unit type if it is allowed to engage that unit in some way. For example, Infantry Units Can "Move Kill" attack other Infantry, and "Bombard" certain ships.
Any student of Empire understands the classical combat types, moving to kill a unit, moving to capture a city, and bombing or bombarding other units. All of these offensive features are in the alpha build of the game, as well as Siege Combat/Capture, Range Fire, Defensive Fire, Mine Attacks and "Detonations".
Siege Combat/Capture is not unlike Move Kill/Capture Combat. Where it differs is units contained within the defending unit must be destroyed first before the kill or capture attack can be carried out. This attack is currently specified for ground units attacking a Fortress. An attack against the fortress is redirected to a Bombard-Like Attack against a unit in the fortress if a unit is there. If the attacking unit is victorious, it does not move in to the square, but expends movement points. Finally, if the attacker has managed to empty out the defender, the next winning attack will either Kill or Capture the empty defender, depending on the attack type specified in the database..
Range Fire is going to be a nice addition to the game and present some new strategic challenges. Units capable of and executing range fire will not move in any other way during their turn. The user will invoke the range-fire command, and select the square he wishes to pummel. Often, a range unit is able to fire farther than it can see. If a player can see the unit in the square in which he attacks, he can see the results of the combat, or he will just see an explosion and have to investigate at a later time…but he will not directly know during the game if he killed a unit there.
Defensive Fire is an extension of range fire for units specified as defensive-fire capable in the unit database. A unit does defensive fire when there is sighted enemy movement within its fire range, and it did not move or fire during its regular turn. The unit conducts range fire upon the moving unit, during the enemy's turn. Ground and air units cannot conduct defensive fire against orbital units and visa-versa. The exception to this is units in 're-entry' are vulnerable to fire from both.
Mine Attacks occur when an opponent has left a little surprise in the square that a hapless unit wanders into. The unit enters the square, and is attacked by the mine. Win or lose, currently the mine is destroyed. I have already discovered that mines can be quite devastating to tanks moving though rough -like terrain and becoming crippled via a mine. Not much left to do but dig in and call out the truck, or build a runway. ;>
Detonations happen when a missile reaches its final destination. The player orders the unit to detonate, and it attacks a ground or air unit in the square. Missiles only detonate in reentry. If you have the nasty nuclear missile, a successful detonation attack wipes out all ground and air units in the square, including a city.
There has been a good discussion regarding submarines on the forum, and it has prompted me to make some changes in the design. One thing I have seen about subs is there is no way to allow the sub - a sea unit - to be in the same square as an enemy aircraft through the current game mechanics. The sub is a noticeably a lesser used unit in the game because of its speed, expense and ability to not effectively hide. In the enhanced version I wanted to enable the sub to dive and be free from aircraft attacks. The swarm discussion and my thoughts on this have prompted me to add an additional "level" to the game, creating a Sub-Ground level, where the sub can lurk while in its deep state. It will still be vulnerable to movement attacks by Destroyers, but cannot be found by aircraft. This change is now in the build.
The game is still in alpha, but it is now reaching an important new stage in its development. I have assembled a small closed group of play testers who will soon be looking at the new rules introduced to the game. This group is different from alpha or beta testing because their main focus is to study how the game plays out, and comment on what does or does not work within the game.
And there is a lot of 'stuff' to look at. Already two units have not made the "cut", and those are the medium range missiles (regular and nuclear). That brings the total enhanced game unit count down to 33 units types, 3 times the number of types in the 'classic' advanced game. This number will most likely continue to decrease.
When I look over the set of new units, there are many units there, and there is some question as to whether or not they all will remain in the enhanced game. This does not mean after the game is released you will not be able to design such units. It just means they will not be part of the standard 'Enhanced Game' databases.
So play testers are another step as the game slowly creeps out of its vapor-ware status and becomes reality There is still a great deal to do, but the non-implemented rules list for the Round-Robin Engine is becoming very short. The Simultaneous engine will reuse much of the game engine code already constructed. There are some questions in regards to the simultaneous engine that are going to be investigated soon. There is some question in my mind as to whether or not this feature will be fun within the mechanic constraints of Empire.
So I still have plenty of work to do, but as you can tell, it is taking shape and that is very exciting. In regards to goals for the next report, I will have had the game in play testing for at least a week. I currently plan to get the remaining rules set for the Round Robin Game implemented, and may move towards the Simultaneous Engine, the AI components, the multiplayer aspects, or the interface. Like I mentioned, plenty of ground still to cover.
Update: February 2nd, 2004 - Moving On With Units
Everyday a new feature is added to the alpha build of the game. Everyday it makes the transition from vaporware to an awesome game. The road is still new and there is much, much work to be done, but already with the progress I have made so far I feel this is going to be a great game.
With the game setup essentially in place, except for the saving of the databases and current games, options, etc. (currently represented in the build as hard coded data), I have now proceeded to working on the meat of the game, which is served in three courses, sighting, movement and combat. In Empire, with range fire as the exception, one must have movement before combat. I am currently wrapping up movement and sighting, and about ready to enter combat.
Movement may sound easy enough to implement, with the click of the mouse or a key press to indicate where you want to go, but there is a great deal of effort going on under the hood with each attempted moved. Movement of units is what triggers scanning, and all of the scanning logic has been put into the game. Sightings will be represented differently in the client than in Empire Deluxe. The main difference is they will never disappear like they currently do unless you spot that square with a unit again. Each sighting will have an age, so you will know how long ago it was that you saw it. You will be able to hide sightings that are of a specified age or older.
An enemy unit can produce many sightings from a player's perspective, but only one may be the "here and now" or "eyes on". The enemy unit sighted will still have it's name, damage and other vitals statistics hidden from your view. This data is never passed to you from the server, so even the AI cannot cheat and track unit movements.
There are several new movement types introduced into the game. The biggest adjustment is the separation of the map vertically into three planes. These are the ground level plane, the over flight plane and the orbital plane.
The ground level plane is where the ground units and sea units exist. After much design reflection, the units in this level will not be able to pass through or stack with one another, except in situations like cities, forts or airbases holding units. One desired requested feature was to allow the equivalent of armor to pass through units like infantry, or destroyers past battleships. But upon studying the game I have observed that planning the maneuver of troops is an important aspect o the strategy behind the game, so it will remain as it has been.
That being said, the mechanics will be changed slightly with the "over flight" plane. This is where air units spend most of their time. You no longer will be required to move an air unit that is over flying another unit. (However, I plan to allow this restriction to be optionally triggered). A square can also allow two flying units in it if there is not a ground unit, just like before.
This change will cause an interesting new tactic, which will be stacking air units upon ground units (or two air units together), forcing an enemy to attack both units if he wishes to move into the square. Such combat would l occur by the attacking unit engaging the over flight unit first, then striking the ground (or under flight) unit. Obviously, this is something that is going to be vetted out during play testing, but it may give and opportunity for those fighters to protect that lone advancing infantry a little more.
One other movement concept for an air unit is the concept of take-offs and landing. Any air unit can "take off" from their carrier or city, which will allow it to begin over flight above this unit. Some units, like the helicopter, will be able to "land". Landing is different from touching down in your carrier or city. The unit can land in a designated open square, and not lose any more movement during the turns it is 'on the ground'. The unit will not be able to move like a ground unit, but will be able to take off and resume movement.
Of course the orbital plane is new to the Empire series. Essentially, this level is well above the fray below, so orbital units cannot engage units in the ground or over flight levels and can freely travel over ground and air units. They may spot areas on the ground, (satellites will be effective here), and be able to engage in combat situations with other units in the orbital plane. Units on the ground may be able to spot some orbital units, depending on the specification of the spotting unit.
To enter the orbital plane, a unit will have to be launched from a city or other unit with that capability. Once a unit goes orbital it will not come back down…well, not in a nice way. Some orbital units, such as missiles, will have the ability to invoke 're-entry' while in the orbital plane. When in reentry, the unit has a special limited range that enables it to try and seek out a target. If it reaches its target square, it can attack the unit in that square.
Many of the features listed here are going to be optional, or only available in a game when it is setup with units that take advantage of these features. There is still the focus of keeping the game simple, like the previous version, but also allowing for the evolutionary change of the game.
So there are some minor extra details and clean up I have to insert into the movement and spotting aspects of the game, then later this week I proceed with combat. By the next report, the units should be fighting it out, and I will hopefully provide some details on the combat aspects of the game.
Update: January 19th, 2004 - All Dressed Up And No Where To Go
Empire Deluxe Enhance Edition is now very heavily into the implementation phase. Lots of code is slung everyday. Everyday new components are added to the game. But it still has a long way to go, as the "TODO" list gets longer, not shorter, and at the moment it is not much of a game.
I have installed the DLL interface for the game, though I am certain changes will become apparent after it is put through the paces. As I have mentioned before, there will be one AI DLL per type of computer opponents available, with each DLL being able to support any number of opponents of that type. This is definitely going to be a thrilling aspect of the game.
With the AI interface in, the major architectural components yet to be installed are the Internet connectivity aspects of the game, as well as the management of email play. Both of these are not going to be difficult to add, for the abstraction of the architecture allows them to be easily added. It will be some time before I put these in.
I have been doing a lot of work on the User Interface for the game. I had originally intended to work on the game engine itself last week, but determined that some extra time on the interface would help in the play-testing phase. Also, the interface additions at this time will help Wydraz with his work. He has not yet started on any of the unit and terrain graphics, as he is waiting for me to deliver a build for him to work with. We have discussed much conceptually and technically in the way of graphics, and he has delivered a very cool draft splash screen for the game. I know he is ready to get drawing, and I hope to deliver him something he can work with by the end of the month.
So I have reshuffled the schedule slightly, putting back the engine work a week or so, so not much has been done there. The game currently consists of initialization of the selected options by the player, the construction of the map (though crude at the moment), and the initialization of all AI opponents. From there, each player is able to end their turn after it begins. So the game engine just processes whose turn is next for the moment. Not too exciting. But it makes a lot happen, and that's important.
What I do think is exciting is the changes of the interface from the original ED and EDIE. I am not ready to show any images of it yet, but I will describe it somewhat. Most of the changes to the interface center around the "information window". It is now less modal, and more of an active part of the game. The window itself is attached to the map window on the right side of the screen, very similar in appearance to the side game window in The Perfect General Internet Edition. But this window has much more functionality. It can be resized and it can be hidden to the right and brought back with a simple click of the mouse. It can also be detached from the map window and appear as a popup window, which can be hidden or minimized.
Along side of the Information window is a series of tabs, with each tab providing different information and functionality based on where the cursor is on the map.
One tab represents the terrain information for the hex. Another displays information about the top unit or active unit in the square.
One tab displays a tree view of your units and how they are stacked in the square. You are able to load and unload units by clicking and dragging in this view.
One tab leads you to the 'classic' production view, with buttons for units and the various times to production displayed. Another tab displays a similar construction view for units such as engineers that can build a unit.
There is a tab that has the command queue for the currently selected unit, with which the user can build or edit new commands. The ability for a user to get into the details of how many units and what types to produce, construct, or load will be possible here. There will also be an 'actions' tab for a user to quickly select certain instant moves such as "skip turn", "wait", or "unload all".
The map area itself still takes up most if not all of the screen, and zooming will be available as well as scrolling. I have also added the ability to scroll the map with the mouse wheel both N-S and W-E. I am already addicted to this feature!
The familiar status bar will still be at the top, ready to supply you with quick information bout events that occur, and there will be menu options and hot key available for various commands in the game. It will also indicate which turn it is, as always.
With an initial draft of the interface nearly complete, I will very shortly begin concentrating on implementation of the Game Engine. Then there will actually be a game behind the façade. And with that, I can move towards some real play testing, a beta, and eventually the final game. But that is way down the road…for now I will just lower my head and continue to code away. As I mentioned earlier, there are plenty of items on the "TODO" list yet to be done.
Update: January 5th, 2004 - Full Throttle Development with the DLLs
Well, the holidays have ended and now the work on Empire Deluxe Enhanced Edition kicks into high gear. I am now deep into coding the game…but it is not a game yet!
Design and prototyping on EDEE has been going on for some time now. Those who are just now discovering the status reports should read some of the latter entries in the "General Status Report" for some more details on EDEE.
I am still very much involved in the implementation of the setup of the beginning of the game. I have written the new "World Building" interface for programmatic DLL interfacing for EDEE. This interface will be different from the one used in EDIE, because there are more possibilities available in making a map, and the concepts of cities have changed slightly.
I realize that a good deal of the following report talks about some very exciting aspects of the game, basically the DLL interfaces. While this is an exciting aspect to all players, because it will mean more map making variety and new and challenging computer opponents, the technical details discussed below may only be exciting to nerds such as myself. So I have clearly marked the beginning and end of the DLL discussion for those who wish to stay out of it.
---START DLL DISCUSSION---
Previously, cities were implemented as terrain on a map, and as units when in combat. I have brought the cities all the way over to the 'units' side of the fence now. So a city is a unit type all the time, or rather, a city-type is an attribute of a unit.
What this means is on a "map", there are no cities, just terrain. So when a DLL is asked for a map, it returns one without cities. This DLL will also return a listing of resource locations and roads if so requested.
The DLL is then asked separately for it to provide "units", which commonly (but not necessarily) will be cities. The DLL is passed some player information, enabling it to decide the starting positions of the players as well.
Depending on the types of game conditions chosen, the DLL may have to provide other information if possible. For example, the World Build DLL needs to provide flag spawn locations if it is a Capture the Flag game, or the Region to designate the "King of the Hill". In games requiring a capital it needs to designate the city that is the capital for that player.
This does mean there are multiple calls to the DLL interface and it is setup slightly different than before. However, I plan to open source the world building code I use in the game as a DLL. This way, that code provided with the game can be used as a default to provide those features a DLL writer may not wish to cover. It will also serve as a base for programmers to build upon if they so desire.
The code is done in C++ and will be object-oriented for the most part. I also use the STL object containers (for you code-geek types). Visual Basic programmers should not fear, for as Fubster's VB DLL demonstrates with EDIE, this does not mean VB programmers are in the dark. He was able to write a C++ wrapper to his code, and the same will be possible here.
When a game is setup, a player will get to choose which DLL he wants to use for world building and unit construction. The method of DLL selection is advertised to all human players. There will be an option to use internal functions in the program as well. This would be done for game security reasons. That way, an opponent could not create a map using a special DLL that also outputs a map and starting positions for his secretive review. The code used in the internal program will be the same as the code released in my World Building DLL.
I am also working on the DLL interface for the AI player. Again, this will be C++ Object Oriented code. This interface will be much more complex than the one for World Building, and so I am not so sure if I can make any uplifting comments for the VB set on this one. Anything is possible though…
You can use several AI DLLs in a single game, but each AI DLL will only support one type of AI opponent. In each DLL, the programmer will be required to make and manage as many instances of this type of opponent as the player requests. The interface will help facilitate most of the management of unique players of the same AI type, but the programmer will have to keep this in mind.
Each AI opponent may also have one file associated with it for reading before the game begins, so if you choose to make "rules" for your AI opponent to read from a file, this is how you will do it.
The programmer may wait till his AI's turn to process events that have occurred before hand (like sightings and combat results), and then calculate what to do during his turn. He will be able to run a thread that will facilitate the "deep thinking" AI player whose wheels want to churn while the other players are doing their turn.
There is a great deal of power provided for the creative world building and artificial intelligence programmer within these DLLs, but with that power comes risk. Bad and crashing code in DLLs will behave, well, badly, and people will not want to use those DLLs if care is not taken when they are written. Also, DLLs that do a lot of 'thinking' may slow down a machine, and then those that consume a lot of memory may drain some systems. But the aspect of players being able to program their own AI's is very exciting, and I am anxious to see what the community will come up with. And yes it will be possible to set up a game with different AI's and watch them duke it out.
One other thing I would like to note is that there will be some libraries that will be needed to compile the DLL's. These will provide such support as internal database interfacing and base classes for the classes the programmer writes. I am unsure if I will provide all of this (source code and required libraries) with the distribution or as a separate download, but they will be made available at release time, not 'sometime' afterwards. I am sure at some point after release there will be changes made to the distributed libraries, so DLL authors be prepared to have to recompile and redistribute your DLL's occasionally.
--END OF DLL DISCUSSION-
Work will continue on the game setup for most of this week I'd imagine. Sooner or later I will begin to work on the interaction between the players and the game itself. Just like there was with the architecture aspects of the game, there is a good deal of code from the prototype that will be cleaned up and reused here. This part of the implementation, coding the actual game, will be a great deal of fun, and I am looking forward to it.
I am not sure at this point in time how playable the game should be by the next reporting period, but I would not be surprised if movement and combat have been put in the game to some extent.
As you can see from the description pages for EDEE, I plan on a "summer release", which is a pretty wide target date. I hesitate to name a more specific month as of yet, because there are still several important stages that must happen before Empire Deluxe Enhanced Edition is reality. I have a good deal of code to write. Play testing must begin on the new game aspects, to really prove the rules. Along with this alpha testing must take place. As soon as I reach a beta period, that will be a good sign, for it will be possible then that I will only be some 8-12 weeks or so from release.
As I have frequently done, and most likely will continue to do, I encourage all Empire fans to spread the word in forums and newsgroups. Definitely tell your friends and even strangers about it. That is the best way to get the word out that the next evolution of Empire is occurring now.
And I would also encourage you to post comments, suggestions and questions in the forum or send me an email and let me know what you think is cool, bad, or missing. As with EDIE and PGIE, I do listen to your comments and really would like to get as much of it in as I can. This game is being made for you. I can never make promises, but my prior record definitely shows I try to do what can be done.
So the announcement of EDEE is very exciting, and there will be more exciting news to come as this report grows. Until then, keep playing EDIE and if it gives you an idea, drop me a line. I have found it is a great source of inspiration.
.
© 2018 Killer Bee Software
|
