So I put everything I have together yesterday and obtained a zipped package that at least on my system (Win 7, JRE 7) runs and shows something. It is avaiable via Download.
Some thoughts about it:
- The blog (project home) just yesterday broke a bit when the service provider updated its php version and policy (more strict). I am kind of repairing it, but couldn't post any news, only edit the Download page.
- Putting the credits or help on so many different pages (blog, forum, ingame help) is tedious. We must reduce it.
- We have two Issues systems (or three if the contact form is included): googlecode Issue tracker and Forum subsection. I would prefer to reduce this to the forum subsection for now.
- The chancelog also is either a forum thread or a document in the distribution. Probably better to just have it as a forum thread.
- I expect to get some feedback in the next time, at least from my fellow forum members.
- Advertisement in the outside world has to follow.
Apart from that work can continue as usual. I updated the road map and the task board. Programming will be reduced. For now I need to design the scenario data structure (how terrain, units, nations, provinces, ... are linked together). I cannot do this finally but better than it is for now. I spent much time in the last four weeks to get the project from zero code lines to this state (with the help of a library I had assembled before) - in the next weeks I will probably not have the same amount, but ... progress will be more steady I guess.
Dev Blog - Trilarion
Forum rules
Posted relevant content can be used under GPL or GFDL (http://www.gnu.org/) for the project. Thanks!
Posted relevant content can be used under GPL or GFDL (http://www.gnu.org/) for the project. Thanks!
Rejected or not?
I received this email telling me that my application to the Imp_List on yahoo was rejected.
Right after I searched for a way to contact the owner of the group and explain (one last try) ... and I found I am a member of the group.
So my guess is now that Yahoo is playing cruel games.
And I felt.. well like everybody who is rejected and feels like he got it undeserved.Your request to join the Imp_list group was not approved.
The moderator of each Yahoo! group chooses whether to restrict
membership in the group. Moderators who choose to restrict
membership also choose whom to admit.
Please note that this decision is final and that Yahoo! Groups
does not control group membership.
Right after I searched for a way to contact the owner of the group and explain (one last try) ... and I found I am a member of the group.
So my guess is now that Yahoo is playing cruel games.
Re: Dev Blog - Trilarion
Yes I have found Yahoo's Groups system to be horridly outdated and buggy. Some days I can't access files, some days it can't log me in, some days it can't remember that there are new posts for me to look at.
VI - Network in progress
An image tells more than a thousand words ... so just have a look at what I am doing currently. Goal for next release is a somehow existent main screen and some basic network starting/joining/exiting a game from different users. So I evaluated several network libraries and finally settled with one I have so far nothing to complain about.
Now the communication between the clients (actually always through something called server first) is via small messages (I need this, here you have that, do that, don't do that, you forgot this, thank you, you're welcome, ...) and I am testing them. It looks like this:
Now the communication between the clients (actually always through something called server first) is via small messages (I need this, here you have that, do that, don't do that, you forgot this, thank you, you're welcome, ...) and I am testing them. It looks like this:
VII - Small things
So what's going on lately? Well many small things. Fixing Linux, especially the maximization (full screen doesn't seem to work under Ubuntu). Simplifying the code structure. Using another library for layout of the user interface. More on Network and Server communication. ...
Visually one doesn't see much of it, but just as a teaser here the current main screen. I abolished the floating window idea and now have a conventional controls area at the right side (can be switched to left side if wished).
Visually one doesn't see much of it, but just as a teaser here the current main screen. I abolished the floating window idea and now have a conventional controls area at the right side (can be switched to left side if wished).
Re: Dev Blog - Trilarion
Keep up the good work!
VIII - Under the hood
No image today. However I don't want you thinking there is nothing going on. There is. The source code is now 13K lines of code. Seems like a lot for what it does so far but most of it is framework - that is code that loads and savea stuff or displays stuff or plays music. Many future elements will reuse it and they rely on this stuff working as expected. I haven't invented everything of it in the last two months. The larger part I had already collected and programmed in the past.
So a typical action is that I change the way something works internally, for example instead of each screen having its own frame, having only one frame and copying the content of each old frame into the new frame - don't ask why this is better. Now at the end of the day I hopefully arrive at a state again where everything runs (it doesn't in the middle when the new code parts aren't completed and the old parts are already broken) but visually you'll see no difference. On one side this is satisfying because it was exactly the aim - on the other side users will just think that nothing was done at all, because they don't see a difference. However in the long run programming will be much easier because of such actions. They're a must.
One example is full screen windows on Linux and Windows. Here Java actually behaves quite differently. On Windows you can cover the taskbar with your window, but only if it is undecorated, on Linux you can't. On Windows you can use the full screen exclusive mode, on Linux you can't, although Java says it can, but it can't. Linux even shifts the window outside of the visible area in this case instead. On Windows you can initially maximize a window and make it not resizable, but only if it is undecorated, on Linux you can't. On Windows you can shift windows out of the visible area, on Linux you can partly (only outside of the bottom). However if you try, Linux will give window coordinates which are outside, but just doesn't display the window outside the visible area. All in all, the graphical Java support of Linux is suboptimal, less good than on Windows and plainly irritating sometimes.
Well, after a lot of testing and finding this out, I hope I found a solution that looks well on both systems. And Mac? Well when the first Mac user tests the new version I will be curious to see a screenshot but I have a good feeling now.
So a typical action is that I change the way something works internally, for example instead of each screen having its own frame, having only one frame and copying the content of each old frame into the new frame - don't ask why this is better. Now at the end of the day I hopefully arrive at a state again where everything runs (it doesn't in the middle when the new code parts aren't completed and the old parts are already broken) but visually you'll see no difference. On one side this is satisfying because it was exactly the aim - on the other side users will just think that nothing was done at all, because they don't see a difference. However in the long run programming will be much easier because of such actions. They're a must.
One example is full screen windows on Linux and Windows. Here Java actually behaves quite differently. On Windows you can cover the taskbar with your window, but only if it is undecorated, on Linux you can't. On Windows you can use the full screen exclusive mode, on Linux you can't, although Java says it can, but it can't. Linux even shifts the window outside of the visible area in this case instead. On Windows you can initially maximize a window and make it not resizable, but only if it is undecorated, on Linux you can't. On Windows you can shift windows out of the visible area, on Linux you can partly (only outside of the bottom). However if you try, Linux will give window coordinates which are outside, but just doesn't display the window outside the visible area. All in all, the graphical Java support of Linux is suboptimal, less good than on Windows and plainly irritating sometimes.
Well, after a lot of testing and finding this out, I hope I found a solution that looks well on both systems. And Mac? Well when the first Mac user tests the new version I will be curious to see a screenshot but I have a good feeling now.
IX - Network and Scenario Files
Just another update.
With the User Interface I am satisfied for the moment. Now one goal is simple network interactions. However network is everything but simple. Messages can arrive in any timely order and disconnects are always possible. I help myself with defining states: Unregistered, Registered, InPlay, ... and then I can more easily avoid the problem that eg. a Registered client might want to register again in case a "register" message from the server comes late.
The other goal is scenario/save game storage. Thanks to the work of tyggermeltdown the structure of the Imperialism map files is more or less known. There data was stored with quite some overhead. So for each tile the country was stored twice, then a province number and then province borders. One can save a lot there. Province borders can be computed from changing province numbers and simply storing a list of which provinces belong to which nation saves to store the nation for each tile. Instead of 36 bytes per tile I calculate I do not need more than 5 bytes per tile. However it still is tricky. First one has to decide what is a good structure and second there is some conversion from bit streams to strings, to save them in XML. It wil work but it will also take some time.
Uh, and from now until the end of the year, posting could become sparse. This will not affect the release schedule.
With the User Interface I am satisfied for the moment. Now one goal is simple network interactions. However network is everything but simple. Messages can arrive in any timely order and disconnects are always possible. I help myself with defining states: Unregistered, Registered, InPlay, ... and then I can more easily avoid the problem that eg. a Registered client might want to register again in case a "register" message from the server comes late.
The other goal is scenario/save game storage. Thanks to the work of tyggermeltdown the structure of the Imperialism map files is more or less known. There data was stored with quite some overhead. So for each tile the country was stored twice, then a province number and then province borders. One can save a lot there. Province borders can be computed from changing province numbers and simply storing a list of which provinces belong to which nation saves to store the nation for each tile. Instead of 36 bytes per tile I calculate I do not need more than 5 bytes per tile. However it still is tricky. First one has to decide what is a good structure and second there is some conversion from bit streams to strings, to save them in XML. It wil work but it will also take some time.
Uh, and from now until the end of the year, posting could become sparse. This will not affect the release schedule.
X - Provinces and Tile Borders
Just a quick update, already the 10th update. It might be the last for this year.
I am working on incoporating provinces (and nations) in the data model and also displaying the borders between provinces and nations on the map. It is not yet the case, but also not so far away. Basically it's just a number of smaller steps, but you need them all before it works.
I am working on incoporating provinces (and nations) in the data model and also displaying the borders between provinces and nations on the map. It is not yet the case, but also not so far away. Basically it's just a number of smaller steps, but you need them all before it works.
XI - Almost there
Finally, after two rather extended night sessions, its done!! All the features I wanted to have are incorporated. This includes:
- Terrain and resources are shown.
- Every tile additional belongs to a province.
- Province borders are drawn.
- Every province belongs to a nation.
- Every province has a province town.