LinkinLand Reviews

At first, the readme file indicates how to run the game but the creator should read the files within the JAR instead of asking the end user to extract the "lib" directory, it would be better especially for non technical users who don't want to use Java in command line. When this directory is absent, a NullPointerException is thrown, the creator should check whether the directory exists and displays a more understandable error message when it doesn't. Secondly, most of the code is undocumented, almost all public methods have no Java documentation and some classes (including the "Texture" class) don't fully respect Java code conventions. It drastically reduces the interest of this project for pedagogical purposes but there are a few text files that explain how this project works. Thirdly, this game doesn't handle auto-repeat key events correctly. As a consequence, the walk sound doesn't work very well under GNU Linux. Instead of fully playing the sound sample, it starts it and stops it almost immediately. Fourthly, the weapon goes through the wall when you get very close to it. Disabling depth test when drawing it would fix it. Fifthly, the frame rate is extremely low and the memory footprint is very high for such a rudimentary first person shooter. I only get about 5 frames per second in windowed mode (in a small window) with a dual core CPU bought in 2007 (Intel Core 2 duo). This is not very surprising as the creator uses software rendering which is only suitable to display extremely simple meshes in low resolution (even though it becomes less "unusable" as the speed of the CPU increases as time goes by). Sixthly, the customizability of the game is quite limited even with the editor as there is no way of importing a mesh stored into a file in an "open" or widely known format. "the player can build and set everything at will" is currently plain wrong. Finally, this project is a good example of the anti-pattern "Not invented here". The creator reinvents the wheel which could be very interesting if the source code was good for learning purposes or at least if it brought something algorithmically new but it's not the case. Software rendering in Java is already implemented in the open source web engine 3DzzD which goes further and is better documented than LinkinLand. "the developer has the full knowledge and control of the game rendering" is plain wrong as the source code isn't documented enough and using third party libraries isn't a crime. The time exclusively spent in programming an engine isn't spent in programming a game. If a developer wants to focus on programming a game, it should use some libraries as creating a full featured engine can take years of work for several programmers. d3caster is a similar project under GPL, it uses no library and I learned a lot by reading its source code. A Java programmer should learn how the class path and the Java library path work. Some tool kits would fix some limitations of this game. For example, NEWT (JOGL) indicates which event is an auto-repeat event unlike AWT. JOAL (Java binding for OpenAL/OpenAL-Soft) works better under GNU Linux with OpenJDK than the Java Sound API. JOGL is hugely faster than the software rendering implemented in LinkinLand, using it would drive this game a lot more playable especially in full screen mode in high resolution. I don't want to discourage the creator of this game but if he really wants other developers to use his project, he will have to drive it a lot more appealing and reusable as even d3caster was used in only one publicly known free software as far as I know. There is no shame in using the right tool(s) for the right job. Both Java3D and JOGL are open source, using them doesn't mean that the developer doesn't have the "full knowledge" of anything, they can't be compared to black boxes, proprietary technologies. I don't criticize the graphics as programming and computer graphics require distinct skills. I see that the creator of this game has worked on it since (at least) 2012, I wish him good luck.