FreeGameDev

Source: http://files.wasted.ch/software/termina ... rce.tar.gz
Linux: http://files.wasted.ch/software/termina ... x32.tar.gz
Windows: http://files.wasted.ch/software/termina ... -win32.zip

What's new? -> https://github.com/fr1tz/terminal-overl ... /game/NEWS

will try it later today... could you explain what:

-Simplify disc controls.
- ETH mode: Each class only has one type of offensive disc.

entails in more detail?

Edit: nice new menu graphics! oh and switching disc types should probably give some gui feedback. I also think one button to cycle them should be sufficient. I also think that switching weapons could maybe be put on a more standard button by default (in addition?), i.e. number buttons or mouse-wheel scroll.

I noticed the following with this release:

• The background of the main menu has a weird flickering of yellow pixels. Intentional or bug?
• The “cavern rooms” in ETH3 are now both blue, always. I find this very confusing, why not using the team color as before?
• Also I find the zone coloring of ETH3 to be pretty unlucky. The color is too subtle in my opinion.
• I like the now jump mechanic (charged jumps) a lot. Too bad that with current maps, you basically don’t need those high jumps. Maybe future maps should make more use of this mechanic
• You can open and close the pause menu again while the options window is open ingame. I would expect to have simply the options window closed when pressing Escape.

Boom! AppImage updated.

Julius {l Wrote}:will try it later today... could you explain what:

-Simplify disc controls.
- ETH mode: Each class only has one type of offensive disc.

entails in more detail?

Sure, I went back to using one-button ROTC-style disc controls. Meaning by default the right mouse button is both used to attack enemy CATs with discs and to deflect incoming discs.
I also got rid of the problem how to chose the type of offensive disc to be fired by simply giving each class only one type of disc in ETH mode.

Julius {l Wrote}: switching disc types should probably give some gui feedback. I also think one button to cycle them should be sufficient

Don't worry, switching disc types will be visible on the HUD, but I'd prefer a selection system where the same pattern of buttons always leads to the same disc type regardless of what types you actually have available.

Julius {l Wrote}:switching weapons could maybe be put on a more standard button by default (in addition?), i.e. number buttons or mouse-wheel scroll.

Mouse wheel is pretty much reserved for changing zoom level. I know some people have argued of getting rid of zoom alltogether but I couldn't live without it.
Besides, mouse wheel is currently broken under Linux :/

Wuzzy {l Wrote}:The background of the main menu has a weird flickering of yellow pixels. Intentional or bug?

Noise over the background image is intentional, but should not be yellow

Wuzzy {l Wrote}:

• The “cavern rooms” in ETH3 are now both blue, always. I find this very confusing, why not using the team color as before?
• Also I find the zone coloring of ETH3 to be pretty unlucky. The color is too subtle in my opinion.

ETH3 needs a bunch of fixes, I played with the idea of simply removing ETH3 from this release, but instead chose to simply not have any servers that run it.

Wuzzy {l Wrote}:You can open and close the pause menu again while the options window is open ingame. I would expect to have simply the options window closed when pressing Escape.

Put this on the TODO list.

RazZziel {l Wrote}:Boom! AppImage updated.

Nice Is terminal-overload.org allowed to link to that URL?

fr1tz {l Wrote}:Is terminal-overload.org allowed to link to that URL?

o_O What kind of question is that?
You don’t need permission to link to anything.

And this is a good thing. If you would require permission for that, it would break the entire web. Just imagine being forced to get permission for every link you make. This would be crazy.

Sorry, should've made myself more clear, I was just wondering if RazZziel would be okay with a link to that page or preferred a link to the portablelinuxgames homepage.

fr1tz {l Wrote}:

RazZziel {l Wrote}:Boom! AppImage updated.

Nice Is terminal-overload.org allowed to link to that URL?

Sure thing! You may link the home page, the terminal-overload node, the AppImage itself on SF, download the AppImage and serve it yourself, modify it, improve it, whatever you want

By the way: Terminal Overload wants to write on the application directory itself instead of directing all the writes to somewhere like ~/.terminal-overload, but AppImages are read-only (more or less like if you have the game installed in /usr/share/ or somewhere only root can write), so I need to perform a dirty trick with symlinks to make the whole thing work inside an AppImage. Is there any way to do that more cleanly?

I don't remember right now exactly what writes I had problems with, I think it was shader compilation temporal files.

Ah crap, totally forgot about this issue.

ROTC used the following approach. When reading/writing file x/y/z, it would first try $HOME/.rotc-ethernet-ver/x/y/z before trying reading/writing from the installation dir. The problem with this is that it can get really confusing, because you often end up with two versions of the same file.

TOL needs to find an approach that's clean *and* straightforward.

This is probably not the most appropriate thread to keep going on about this, but just programmer curiosity: what makes you need to end up with two version of the same file? Do you need to modify your assets? I'd expect a traditional game to be composed of:
- Read-only bin/libs (/usr/bin/game, /usr/lib/deps.so)
- Read-only assets (/usr/share/game)
- Read-write config (~/.config/game/)
- Read-write cache (~/.cache/game/)

Note that on Debian and Mageia/Fedora/OpenSUSE games assets and binaries are meant to be in:
/usr/games
/usr/share/games/terminal-overload

Using /usr/bin and /usr/share/terminal-overload is fine too, but the former way is preferred.

Another using path to know is XDG_DATA_HOME/terminal-overload (~/.local/share/terminal-overload) which can be used as a writeable directory for user content (e.g. mods or additional maps that could be downloaded in-game, when /usr/share/games/terminal-overload is read-only).

Some details about this here: http://standards.freedesktop.org/basedi ... atest.html

One of the problems is that ultimately, the game will automatically download needed content that should go somewhere into /usr/share. Then again the whole reasoning behind the basic unix directory structure does not really apply today anymore, so in terms of effort it makes more sense that each user has their own game directory with full read/write access.

Hm, I think the unix directory structure very much applies today, otherwise it's impossible to pack a game/application on a distro package manager. There's tons of games that download assets as needed, and they just write them on ~/.local/share as Akien said. Even Windows adopted this philosophy on Windows 7.

The reasoning was to save disk space, which was very limited back then. If I remember correctly the whole /bin /usr/bin dichotomy was the result of adding another storage medium to the system and union-directories not existing back then (well they are also barely used today, except for Plan9 and Inferno). Splitting files between /usr/share and ~/.local/share will make things more complicated while not actually saving much space (as the content makes up the bulk of the files and will be in ~/.local/share).

hmm, maybe I am missing something, but isn't it rather about having all your customizations (downloaded maps etc) and configs in your personal home directory, while the basic game files are shared between all users and should be read-only?

Edit: well even if most gaming systems are single user and people also put the basic game files in their home directory somewhere, it still makes sense to have all the customizations and configs at a common & standardized place outside of the game directory for easy upgrading the game or reinstalling the system, switching distributions etc. (& never loose your samegames even when deleting the game etc.).

I don't think splitting content between /ur/share and ~/.local/share is meant to save any space at all. The only thing that is meant to save space is not shipping libraries with the apps, but leave the distro handle them, but that introduces third party app distribution problems so I'll happily ignore that and ship ALL the libraries with the app.

/ur/share and ~/.local/share is mostly about permissions and separating different user resources. The core media of the app, handled by the package manager, will go into /ur/share and no other than root will be able to modify that. All the data managed by the app by your user will go into ~/.local/share.

In the Windows >7 world (I think it's actually >Vista, but that version didn't actually exist), I think /usr/share is %ProgramFiles% and ~/.local/share + ~/.config is %APPDATA%, but I'm not that familiar with that system

Anyway, I don't really care about /usr/share, the point for me is that AppImages are read-only ISO files, and the data there can't be modified, so it adapts well to applications that are designed the modern way (the UNIX and Windows 7 way, separate read-only and read-write directories), and not so well to apps designed the old way (the Windows XP way, one single read-write directory)

I'd hesitate to call the UNIX filesystem hierarchy "modern" (interesting read: http://lists.busybox.net/pipermail/busy ... 74114.html)
I'm not really familiar with how portablelinuxgames work, would it be possible to just copy the data from the ISO to the user's home directory and run it from there?

fr1tz {l Wrote}:I'd hesitate to call the UNIX filesystem hierarchy "modern" (interesting read: http://lists.busybox.net/pipermail/busy ... 74114.html)

That link refers to the FHS, which is indeed mostly outdated crap and AppImage wants to depart from that. What is modern (compared to the Windows XP era) is the concept of separating app and user data IMHO.

EDIT: Well not always outdated crap. It makes sense for system-level and server stuff, but little for user-level everyday apps and games.

fr1tz {l Wrote}:I'm not really familiar with how portablelinuxgames work, would it be possible to just copy the data from the ISO to the user's home directory and run it from there?

Yep, it's possible, and really slow, even for a 80MB package. And I don't want to try it with games like Planet Explorers, that take up 2GB.
Copying 80MB, the first run of the app would take tens of seconds, while I the user expects to be up and running in one or two seconds (AppImage wants to avoid any kind of installation, you just download and play). For instance, the 2GB Planet Explorers demo is running in 1 second after you click the downloaded file. No installation, no copy, just run the read-only data, and let the game write in the user directory if it needs to.
Right now, instead of copying, I'm symlinking all the resources from the ISO into ~/.local/share/, which is much faster, but it's still pretty slow (around 6 seconds) because the 80M are composed of many little files. There's an alternative, which is using union mounts, but I prefer to avoid that because it may involve portability problems.