In this update, changes have been made to the jobs system so that less resource locking and stalling occurs, as well as fixed a few bugs associated with distributing the same job to more than one dwarf. Also, there is a shadow system (based on localized ambient occlusion) that better shows the world’s volume and depth for the user.
Finally, I want to thank our new artist in developing a few new art-assets (completely re-done dwarves)! You can learn more about Programgamer on his YouTube channel: youtube.com/programgamer
I wrote a little space-flight over this past weekend. I wanted to learn more about Java, LWJGL (an OpenGL java bindings library), and most importantly: how a slow processor-side run-time affect graphical performance.
I’ve mentioned in a previous post that Java, and other byte-code languages, actually use a JIT (Just-in-Time) compilation technique to really speed up execution. Still, even with such technologies, the run-times are not as fast as native-languages (i.e. compiled into native code, like C or C++), yet what I learned was that it doesn’t (or shouldn’t, if you know what you’re doing) matter!
Game development is complex, and really requires a big effort to distinguish between processor-side computing and graphics-side computing. In the end, even if Java wasn’t JIT-based, a simple video game shouldn’t require heavy processor-side computing, as much of your work really should be pushed onto the graphics card. Though my game is tiny and requires little processing, I can see why people would used managed languages & environments for programming games: the tools and easier, you can develop faster, and all of the built-in libraries really help enormously!
Above is the video game I worked on. There is no story or premise: again, the whole point was to see if I could prototype a game very quickly. Not mentioned in the video was that I had to re-learn quaternions and use that to help with ship control and rotations, rather than directly use Euler-based pitch/yaw.
Interested in reading the source, or executing the game yourself? Grab it here! Be warned: I butchered the source code for the sake of experimentation, and this is very far from any professional code I would write on a real-world project.
Update:Â The project is now up on GitHub. This was done to allow easier forking and experimentation by the fantastic Reddit community.
A while back I wrote about a well written web-application security course developed and hosted by Google, called Gruyere. Since then, I’ve been wanting to learn more about system security and classic exploits like buffer-overflows or malicious shellcode. Though I’ve done wargames in the past, I’ve recently rediscovered the fun of breaking into systems that have clear-cut exploits to take advantage of. If you don’t know, a “wargame” (not simply “just” hacking), is a challenge related to computer and to exploit a given vulnerability. Generally wargames are deployed on systems specifically built within sandboxes for each user with multiple levels. The goal is to eventually reach the last level, accessing a file, text, or whatever it is to prove your skills and share your success. What’s particularly nice about the game is how educationally powerful it is. The games run in simple environments, without much changes over time, and disallow other hackers playing the game from tripping you up by manipulating your own progress.
  Â
I’m a big believer in “learning through doing” (don’t theory is critically important!), and wargames fit that philosophy very well. The two wargames I played recently were the Stripe CTF Wargame and the Smash The Stack games. The first is much more formal and direct, but overall as challenging as the later. If you truly want to learn how to “hack”, but more correctly how to write more secure code, go through the first game. The second is great, but less “user friendly” for you to progress through.
Overall, even if you are a young developer new to the field, you should really sit down and take a day to try and go through a couple of levels. The amount you learn and the scope of the challenges are critical to a solid background in software development security. Learning about buffer-overflows by name and definition alone are not enough; one really has to go above and beyond to master such a complex subject.
