Packaging software is not easy
Now I understand bloatware
I have not written in a while, which is not good. But, I have been so busy between RL work and my software work that I just have not had the energy or time. When I am at home, I have been working on learning how to package my adventure game. It is not as easy as it looks. I would liked to have written this post as a mini-howto on packaging via jpackage, codeberg, and github. Yeah, it’s not happening yet.
I have the adventure game at a standstill until I can go forward with packaging. The game has four rooms, with objects to pick up and drop, as well as one chest to open. No, it’s not much, but the learning is in how to code a text adventure game engine rather than just the game. If you want to try it, you can either clone the repo, download just the jar file, or there is a debian package on the github. Look in the linux folder of the repo for the package.
No, that one package is not success. I need to be able to package the game into, at least, a debian pacakge, an rpm package, and a Microsoft msi installer before I succeed. And, preferably put them into the correct downloadable locations.
The reason I stopped here to learn this is because I have a play tester. My play tester uses only Windows and is not used to using any command line actions. So, I needed a way for them to easily download and run the game. They need an msi installer.
I’m not quite there yet for the msi as it requires something that runs on Windows for jpackage to do its job. That’s why I thought it would be easier to do so by creating linux packages first. Boy, was I fooled.
This path has led me to thinking about the age old problem we often see in software applications and even in operating systems; bloatware. Not always bloatware in size; though that is a consideration. But also, bloatware in contents. My adventure.jar is 25MB in size. The debian package I created on github is 223MB in size. The installed jpackage-d linux application to start and run the jar in a terminal still takes up 202MB. That increase in size is a factor of 10; almost.
Then you have to factor in the work of creating and testing the package scripts, which must be done for every different distribution or OS you want your users to have and it gets larger. I spent several hours Friday and most of Saturday and only ended up with one package out of three on just one platform. And, I have to look at this much work outside of software development because with that work, my game made not an inch of movement forward to the working game.
Yes, this is a lot. But, I am going to learn it and do it anyway. I like the challenge and I like seeing that someone gets something from the work of the final product. So, sorry for not writing. I also need to work on some way for folks to comment and respond. That’s been pushed to the side for financial reasons ( i.e. I don’t like paying money for what I am doing ). I pay for my domain each year and it’s about as much as I can afford right now. So, I have to find free methods or just wait.
I do have a plan forward for the game to get to v1.0. I stilll need to write a closeContainer( ) method to close chests and sacks. I also need to write the real game spec and add its features. I did decide on a way to end the game. I am going to write a special ContainerThing class ( chests, sacks, etc. ) with a limited number of spots ( fixed size ) and each spot must be filled by an exact item in order. Basically, it is a puzzle. It’s something I can write to give a challenge and not have to add a lot of other classes.
That’s enough for today. I still need to see if I can get this codeberg packaging to work. Happy coding!