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!
Re: Dev Blog - Trilarion
I started with Java Swing and now I'm working with the Eclipse WindowBuilder for the first time. Creates unmaintainable code but is't just a prototype, isn't it? Unfortunately even this simple prototype needs a somewhat complex UI to let a player discover an economic model's influence on gameplay...
Don't repeat yourself. (DRY)
Keep it simple, stupid. (KISS)
You ain't gonna need it. (YAGNI)
http://www.clean-code-developer.de/
Keep it simple, stupid. (KISS)
You ain't gonna need it. (YAGNI)
http://www.clean-code-developer.de/
Re: Dev Blog - Trilarion
Very good to hear you already started! You might want to have your own Dev Blog.
XXI Continuous Tiles
Well after falling ill and diverse other things I continued with the tools. I think I can finish continuous tiles soon, however still need one important step, that is cutting the tiles in pieces and stitching them back together. I am currently investigating what is the best method for that. Possibilities include making copies and setting pixels to transparent or defining masks by some polygons or something more sophisticated.
XXII Continuous Tiles to come
So the continuous tile generation and display has progressed so far that I am sure they will be available soon.
In the test below you can see that I can cut a tile in six parts of triangular shape each and can set them together according the fact there in the six neighboring tiles of each tile there is the same or a different terrain.
The cutting and assembling seems to work. So test is passed. Now we need the integration.
In the test below you can see that I can cut a tile in six parts of triangular shape each and can set them together according the fact there in the six neighboring tiles of each tile there is the same or a different terrain.
The cutting and assembling seems to work. So test is passed. Now we need the integration.
Re: Dev Blog - Trilarion
Excellent news. I'm looking forward to this for testing. Once I have the ability to make sure my creation process is producing usable tiles, I should make short work of the continuous set work.
XXIII Network
Now that continuous tiles are done I want to go into another topic before fully concentrating on the game rules discussion. You might think that I don't get the priorities right, and that might be true, but it just makes more fun to me this way around. And fun is a very important thing, right.
So I want to make the network communication functional. The basic concept is that the client and the server communicate by sending messages between each other. The difficult part is that the communication is unreliable: timing can vary, order is not guaranteed and maybe even the whole connection breaks down. Fortunately a turn based strategy game is very relaxed about timing. But anyway I don't want a very inefficient design. Performance might matter at some point.
The most simple and probably not very clever way is to have a single list of listeners for incoming messages that all get new incoming messages forwarded and do something with them. The problem is that usually only about one listener of them will really work on the message, although all listeners will see them. That might induce a kind of overhead that scales unfavorably with progressing development.
My first idea was to build a tree of listeners where a message can flow through the tree until it is consumed. Additionally this tree could modify itself according to current game situation demands. Additionally messages could be altered before propagating them, they could even be re-injected somewhere earlier in the tree. This would surely be a very time efficient and mighty structure. However they design and implementation also proved quite complex. I decided that it was overkill.
So now I try the following: Each message has a channel (number) attached and only listeners that subscribed to that channel will be asked to process it. It is considerably simpler as a tree, but in case we would have a unique channel (number) for each message and store the relation of channels to listeners in a HashMap, it kind of uses a tree under the hood. We loose the ability of modifying or re-injecting messages and broadcasting messages to different channels could be included but probably won't unless I see a neccessity for it. All in all I believe it is a good compromise.
With this in mind I start to modify the network part and code, so that at least turns can be done in the main screen. And meanwhile I also have to push that game rules discussion.
So I want to make the network communication functional. The basic concept is that the client and the server communicate by sending messages between each other. The difficult part is that the communication is unreliable: timing can vary, order is not guaranteed and maybe even the whole connection breaks down. Fortunately a turn based strategy game is very relaxed about timing. But anyway I don't want a very inefficient design. Performance might matter at some point.
The most simple and probably not very clever way is to have a single list of listeners for incoming messages that all get new incoming messages forwarded and do something with them. The problem is that usually only about one listener of them will really work on the message, although all listeners will see them. That might induce a kind of overhead that scales unfavorably with progressing development.
My first idea was to build a tree of listeners where a message can flow through the tree until it is consumed. Additionally this tree could modify itself according to current game situation demands. Additionally messages could be altered before propagating them, they could even be re-injected somewhere earlier in the tree. This would surely be a very time efficient and mighty structure. However they design and implementation also proved quite complex. I decided that it was overkill.
So now I try the following: Each message has a channel (number) attached and only listeners that subscribed to that channel will be asked to process it. It is considerably simpler as a tree, but in case we would have a unique channel (number) for each message and store the relation of channels to listeners in a HashMap, it kind of uses a tree under the hood. We loose the ability of modifying or re-injecting messages and broadcasting messages to different channels could be included but probably won't unless I see a neccessity for it. All in all I believe it is a good compromise.
With this in mind I start to modify the network part and code, so that at least turns can be done in the main screen. And meanwhile I also have to push that game rules discussion.
XXIV Working Network
So after having implemented the Channel solution I decided that I suffer from trying to optimize prematurely which is not a good thing and removed the feature again. And somehow this helped me thinking about the real network problems (collecting the information about the states, concurrency, interaction with GUI) and now I did a big move forward. Basically I am now confident that all arising problem during game development can be solved, even if the number of programmers involved will not increase. Just a matter of time.
XXV Good progress
A new entry in the dev diary/blog says it all. The last three days I was obsessed with coding and I made a good piece of progress. That means I got a server running, I got a client running, I got them communicating, I got them exchanging simple messages, I got the server sorting this messages to different entitties called (server)clients, I got the client displaying some of the messages sent back. In short, an important part of the programm is now kind of functional.
The drawbacks: You actually do not see much of it when starting the client, it mostly looks as before. And there is still so much to do, everything is far from finished.
But I come closer to my goal of having at least some parts of this essential piece together.
The drawbacks: You actually do not see much of it when starting the client, it mostly looks as before. And there is still so much to do, everything is far from finished.
But I come closer to my goal of having at least some parts of this essential piece together.
Re: Dev Blog - Trilarion
This is good news. Once networking is out of the way, we can focus on the mechanics of the main 4 screens, and ending turns. At that point we will have the game in a playable state.