Lessons Learned Porting Adventron to Java

Screenshot of my work in progress

(Update: See the discussion on the reddit thread for more information related to unit testing and all of /r/learnprogramming’s input!)

I’m currently porting an old game I made when I was 14 to Java. I called it Adventron and it was originally coded in a poor man’s C/C++ hybrid (blame the 24 hours series.) I used the Windows API to make a 2D top-down adventure game with an ASCII block representing the main character. It ran slow and doesn’t compile today, so I decided I’d port it over to Java as an exercise. I’ve also been learning how to use Git on my own on the way, so there’s a mixture of lessons learned. It’s been a little over a week since I really started diving in and I’ve learned that:

• Getting comfortable with Git comes with time, and more specifically, will only come after you’ve figured out how to set it up. I’ve finally got it happy on my Linode, my Windows box, and my little iBook.
• Porting across languages is less tough than porting bad code to good code. Adventron was my first long project, and while it worked, it was clear to me that it needed to be rewritten after I finished. Time passed, and now I’m porting bad code to a new language — a deadly combo! Every time I put a new feature in, I realize I was doing something poorly way back, or I realize that I could have done it x times better.
• Java doesn’t let you read local files easily as an applet. At first, I was outraged and a little confused as to why you need to sign your applet before Java lets you read local system files. My level files are stored in text files that I read in. I played with making the jarsigner happy, but ended up opting to make the level files accessible on the webserver, and reading the URL. No scary applet signature warnings, and it makes cross-platform development easy — no changing file paths when I develop on Windows.
• Profiling your code is too important to skip (otherwise read as, “Time procrastinating on reddit isn’t always wasted!”) I found this article on “Overlooked Essentials for Optimizing Code” while I was procrastinating and realized I had been forgetting to profile my code. I downloaded Eclipse’s TPTP profiler and instantly saw where I was spending too much time. Three lines of code made a huge performance change and helped me think past my (bad) old design.
• Social Coding/Peer Pressure will make you code better. Of course I want my code to be the best I can be — that’s why I’m rewriting it. However, there’s something to be said for the first commit you make when you push to GitHub. I was pushing to the git repository on my server when I decided I should have a public presence on GitHub. Immediately after pushing I started thinking of the ugly pieces I was pushing to the side. I still have a lot to change, but it’s the thought that anonymous others will see what I made that’s forcing me to code better. It’s a good thing!

I’ve still got a long way to go before the game is playable, and there’s a million other things I’ve thought of along the way. It’s important to remember that besides  what I’ve learned above, the best thing I did was start. I didn’t have an itch to work on this until I started, and it’s been over a week of long coding sessions since I started back on it.

You can find my GitHub account here, and take a look at a very crude version of the port on my newly-made projects page.