Page 13 of 13
LXXXIII - Implementing features
Posted: Wed Nov 09, 2016 3:59 pm
.. mostly within the editor. It's going slowly and there are several parts that need to be rewored/re-designed later on. Especially the tile map display where I still wanted to do many experiments on.
However, this won't be ready for the next release. I will continue implementing content until the end of next week and then it's only making an install package and updating help/release information. Then at the beginning of December there will be a release and then I will make a new plan of what to do in which order.
LXXXIV - Frustration
Posted: Tue Nov 15, 2016 10:08 am
I work on this project in my free time which means an hour here and there, mostly in the evenings. The last commit to the github repository combined the work of two evenings, roughly three hours of work, searching for bugs and small improvements and the result is: 100 lines of code added, 70 lines of code deleted, so the code base effectively grew by only 30 lines of code.
Yes I know that this is not a very meaningful measure and I could easily produce more lines not improving the project at all. That's not the point. The point here is that since two months I'm kind of as active on the project as I want to be and still progress is slow. Given this speed it will take many years to finish the project.
On the one hand I know that this doesn't mean I'm a particular slow programmer, that's just how programming is. And of course my time budget is much, much smaller than if I would do this full time. And I'm currently the only programmer. It's just tiny little bit depressing to realize the truth, that making such a game (and I only talk about the programming side) takes so long.
What can and should be improved? More programmers for the project. I estimate that around five programmers like me would be optimal to have the game going in only a couple of years instead of many, many years. So the idea is to continue of my own and by showing the potential attracting others which then speed up the process.
However, if this doesn't happen, what then? Well, I intend to finish this project. I'm still young. I will continue at least until 2020.
LXXXV - Windows Executable
Posted: Thu Dec 01, 2016 1:24 pm
I wanted to make a release and create a Windows executable but it turns out, pyinstaller, the Python windows executable manager has big problems with PyQt5.7 and still cannot wrap it. Manually copying lots of files from the site-packages folder of my Python installation may fix the problem, however not for me. I have strange issues starting the game from the created executable.
So, should I release only a wheel on PyPi instead? I guess for the current stage of the project this should be enough and so I can give the pyinstaller people more time to come up with a solution. They already know about the problem.
edit: Just found pyqtdeploy
. Will give it a chance.
LXXXVI - PyPi package
Posted: Mon Dec 05, 2016 5:29 pm
Pyqtdeploy unfortunately didn't work right out of the box either, it even exited without warning when I wanted to start the build. I also didn't understand what's the advantage over pyinstaller - obviously there is an additional compiling step in the middle but does this increase execution speed? I gave up on that one.
The remaining thing is making a PyPi package (a wheel). Therefore I wrote a setup.py script only to discover that it really, really wants a named top level package (otherwise the resulting modules will be thrown directly into the site-packages folder of your Python distribution). This just required some renaming (I didn't want to give up having a "source" folder). Second is that script entry points need to call a method, not just execute a module (my preferred way of starting the game so far), so a bit of writing around that was needed too. But the strangest thing I encountered was that all files specified as data files are zipped and put into an egg file with no apparent control over the whole process, even with specifying the option zip_safe to false. Consequence: my app doesn't find it's data anymore.
So I may have to move the data folder into the source package folder, just to be able to have some data files readable placed with the app. And I'm currently in this process but it already took two evenings.
LXXXVII - PyPi package 2
Posted: Wed Dec 07, 2016 1:42 pm
I did more research on how to package data with your PyPi package. There are some constraints I'm not so happy with but I guess I can make it work.
Data files are deployed as egg (zipped) which make them effectively read-only and I still wonder (since there are already the scenarios as zipped files) if reading zip files from within zip files would break the existing code.
Package data files have to reside in the package folder, so I may use them, however this probably means I will use a symbolic link (Git has some inconveniences with symbolic links on Windows).
Executable, frozen Python, PyQt applications are currently not working since pyinstaller 3.2 and PyQt5.7 do not work well together.
Anyway, Andretting commented on the missing tiles and missing original scenario (original as in our own work), so I will delay a potential release now and instead think about the tile issue and get a better original (our own work) scenario.
Stay tuned for updates on these.
LXXXVIII - PyPi and Windows installer
Posted: Mon Dec 12, 2016 1:32 pm
Finally I got it working. Installing the latest version is as easy as "pip install imperialism_remake" and starting it as easy as typing "imperialism_remake_start" in a console everywhere on Windows, Linux or Mac (I hope). I will advertise this prominently when there is time for a new release (i.e. a few more features before).
Also I discovered an alternative to pyinstaller, pynsist
, which unlike the former produces working installers on Windows. They bundle Python and the required packages and create executables and start menu entries. Works like a charm.