Dev Blog - Trilarion

Discussion of ongoing programming work.
Forum rules
Posted relevant content can be used under GPL or GFDL (http://www.gnu.org/) for the project. Thanks!
User avatar
Trilarion
Founder
Posts: 829
Joined: Thu Jan 12, 2012 9:27 pm
Location: Central germany

LV - Rivers functional but not beautiful

Post by Trilarion » Tue Sep 23, 2014 10:05 pm

Rivers are now integrated again. However they look currently not very natural, since they are only lines connecting centers of tiles.
Clipboard01.jpg
Clipboard01.jpg (60.35 KiB) Viewed 16065 times
Well that is exactly what they are gameplay wise (a bunch of tiles which influence transport network connections and maybe railroad prices. The exact form doesn't play a role for the game rules. That's way I move on to other stuff now and clean this up later.

Of course nicer looking rivers (I want to procedurally generate nicely swinging rivers and I think I can do this.) are desired and so there is a new task about it.

User avatar
Trilarion
Founder
Posts: 829
Joined: Thu Jan 12, 2012 9:27 pm
Location: Central germany

LVI - Many small things

Post by Trilarion » Fri Oct 03, 2014 10:02 pm

Programming GUIs takes a while. It is a lot of work. Defining all the elements, wiring them, adding actions, making the underlying model fit... And that's why simply displaying the terrain and other interesting information under the mouse tile and other minor things can take a day or two.
Clipboard01.jpg
Clipboard01.jpg (24.69 KiB) Viewed 16030 times

User avatar
Trilarion
Founder
Posts: 829
Joined: Thu Jan 12, 2012 9:27 pm
Location: Central germany

LVII - Random thoughts

Post by Trilarion » Mon Oct 06, 2014 1:13 pm

I advanced a bit more. My aim is to get the editor to an intermediate state, before switching to the game lobby and the main game screen which can reuse quite some code from the editor for display. Just recently while sending Earymgn instructions for how to get started programming I felt like there are quite some things to master in order to contribute programming. You have to know Python at least on more than introductory levels. You have to install quite a few programms. (You don't have to but would be nice to know about version control with Git.) Finally there is probably an IDE that you want to use. Take all this together and you see why there are so few programmers at the project. It's a pitty partly because now I have enough programming tasks (battle prototype, trade prototype, server-client communication) to give work to 3-4 programmers. Developing speed would then be faster for sure.

So if anyone knows a Python programmer (community) full of unoccupied Python programmers... I would like to make some advertisement.

User avatar
Trilarion
Founder
Posts: 829
Joined: Thu Jan 12, 2012 9:27 pm
Location: Central germany

LVIII - Network code

Post by Trilarion » Fri Oct 10, 2014 2:41 pm

So what have I done in the last days? I worked on network code and I hope within some days more it will be in workable shape. This is not the editor where I was working on, but it is another essential part and I was more curious about it. It is basically needed for starting a game. I envision the next release to have kind of an editor and kind of a start game screen. There is no real image to show yet, the scenario selection screen still looks mostly empty.

I probably should have added a task to the tasklist and assign it to me, but I skipped bureaucracy and just worked on it since I'm the only active programmer at the moment.

User avatar
Trilarion
Founder
Posts: 829
Joined: Thu Jan 12, 2012 9:27 pm
Location: Central germany

LIX - Legal stuff

Post by Trilarion » Mon Oct 20, 2014 10:38 pm

I had to change the installer for Windows to incorporate the following: Our project bundles part of Python on Windows to run on any computer. Python itself depends on the Visual C Runtime 2010 from Microsoft. For some reason this runtime is not installed on every Windows computer although that would surely make things a bit easier. Therefore our freezing programm (cx_freeze) copies the needed part of the runtime. This is likely not legal. You aren't allowed to copy it, instead you must bundle the official installer. It doesn't cost a dime, but tweaking the installer (Inno Setup) so that another installer is executed if needed is not straightforward but can be done thanks to a nice answer on StackOverflow. I got it to work.

In the end nothing changed much, except the size of the installer went up by 4 Mb.

User avatar
Trilarion
Founder
Posts: 829
Joined: Thu Jan 12, 2012 9:27 pm
Location: Central germany

LX - A single line of display and the story behind it

Post by Trilarion » Tue Nov 04, 2014 10:50 pm

Clipboard01.jpg
Clipboard01.jpg (16.98 KiB) Viewed 15903 times
It's time for an update. Currently I work on the network code. Today I added a negative number of lines of code to the project. This means I reworked some code I had written earlier which did not work very well and wrote it so that it works better and achieved this with fewer lines. The classical example why quality is always much more important than quantity. Also the improvement was mainly making things easier. It turned out that all my previous thoughts were just to difficult and cumbersome. Now I have a simple and hopefully workable solution.

Still for just displaying a single line of text (title of an available scenario in a list selection) a lot of steps must be taken. Especially if there are potentially two computers and the second computer delivers the list of scenarios (as it's the case with multiplayer).

Just for fun and for those interested here a list of steps that take place internally to get to this result:

1. Create empty list view
2. Register this list view as destination of any network messages with a certain ID (number)
3. Send a certain request (specified by an ID) to the server asking for scenario titles
3.a Serialize this request and all attached data to a unicode string (json, pickle, xml, ..)
3.b Encode this unicode string into bytes
3.c Compress this byte sequence (zip, gzip, ..)
3.d Wrape this byte sequence in a Qt ByteArray (just keeps the length and can be sent as a whole)
3.e Send over TCP
4. Receive a request on the server side
4.a Obtain a Qt ByteArray
4.b Uncompress the byte sequence
4.c Decode into unicode string
4.d Deserialize into Python object
5. Look up table (in Python a dictionary) to find service associated with the ID and call this service
6. Service looks up all scenario files in the save games directory
7. Service reads all scenario files and memorizes scenario titles and file names
8. Service composes a Python object (response message) including this data
9. Server sends response message back to Client (see 3.a to 3.e)
10. Client receives response message (see 4.a to 4.d)
11. Client sends response message according to its ID to the list view (which had itself registered for it in step 2)
12. List view updates itself and shows scenario titles
13. List view deregisters itself (there won't be another message of this type coming)
14. User can see and select scenario titles
15. If user select a specific scenario client sends again message asking for more details and registers itself to obtain the answer for this new case
...

I hope this give a good insight into how you do such things programmatically. Fortunately for us in Python each of these steps is only a few lines of code (sometimes only one). In Java or C++ programming all this would probably take much, much more time.

User avatar
Trilarion
Founder
Posts: 829
Joined: Thu Jan 12, 2012 9:27 pm
Location: Central germany

LXI - A bit of very nerdy stuff

Post by Trilarion » Mon Nov 17, 2014 11:22 pm

Or from JSON via pickle to Yaml and what all these words mean.
Or all about data serialization in the remake.

Data serialization is used for loading and storing preferences, save and load games (scenario files) and sending game messages over the network. There are many libraries for this and so far we used JSON.

The big advantage of JSON is that the output in the middle is human readable (and it is fully supported by Python and many others). That way one can inspect and modify savegames or preferences much more easily.

Unfortunately there are also two disadvantages. One cannot store complex Python objects and I have the need for that now (Enums for example). And the keys of dictionaries must be strings (because apparently this is the case in Javascript where json comes from). Both means extra code and logic in the reading and writing routines which is potentially cumbersome. Over time I became quite unsatisfied with this approach.

But Python fully support another serialization library: pickle. It does not suffer from the drawbacks of json but has disadvantages of its own: only a binary intermediate format and potential security risks because part of the message is executed.

Well it seems the best serialization library for our project is finally YAML. YAML is human readable output and serializes Python objects as well. One can use it via PyYAML. The security risks of pickle are partly mitigated because I can scan the human readable messages and reject every suspicious message. It is slower (at least without the c libraries) than JSON or pickle (which are about equally fast) but still fast enough.

So by switching from JSON to YAML we kind of trade a security risk for simpler and faster coding.

Just a few more words about the security risk: It's not that big. It's a widespread technique and one would need a specialized hacker attack carefully intercepting and exchanging the network traffic in multiplayer games. So while there is this issue it is very probably much less important than having nice code soon.

User avatar
Trilarion
Founder
Posts: 829
Joined: Thu Jan 12, 2012 9:27 pm
Location: Central germany

LXII - Lazy December, busy January

Post by Trilarion » Mon Jan 05, 2015 11:42 am

Clipboard01.jpg
Clipboard01.jpg (14.56 KiB) Viewed 11811 times
This is an activity trace, i.e. the number of source code changes (commits to the project source code) by me over the last nine months. Note that the number of commits, even the number of changed lines is not a very good tracker of progress. So this is more a fun post for the new year. One can see steady activity from April to June, holidays in August, heavy activity in September and a lazy December. However in the last week I again worked on the project and maybe/probably a busy January will follow.

Given that the latest release was in September (0.2.0) I guess that very soon I can release 0.2.1 (in January or early February) if only to show that there is progress.

And there is progress. I'm currently working on the single player scenario selection screen and it goes well so far. But more on that in another post.

User avatar
Trilarion
Founder
Posts: 829
Joined: Thu Jan 12, 2012 9:27 pm
Location: Central germany

LXIII - A bit progress

Post by Trilarion » Sun Jan 11, 2015 11:07 pm

Attached is a look of the current single player scenario selection screen. It' still pretty simple and not very stylish. Just a list of nations and a map (which is even not cutout correctly). It's the result of this weekend and is the first move towards a simple game screen which might or might no be part of version 0.2.1. And it won't be anything fancy though, just to have something.
Clipboard01.jpg
Clipboard01.jpg (44.53 KiB) Viewed 10585 times

Veneteaou
Posts: 280
Joined: Sat Aug 25, 2012 4:23 am

Re: Dev Blog - Trilarion

Post by Veneteaou » Wed Jan 28, 2015 2:01 am

Simple is good. A simple-looking game that functions is better than a non-functioning collection of good looking things.

I have more tiles coming when I get back from vacation.

Post Reply