Projects

Everything posted by modemancer

A few weeks ago I threw up a quick example about dynamically building Expandable Lists, using a simple app called TopicNotes. While it is simple, I like to tinker with it here and there to test features I'm unfamiliar with. About a week ago I was playing with TopicNotes and decided pretty quickly that it needed an autocomplete feature for entering Topics to help avoid unintentional multiple versions of the same topic (I found I had a 'Study hall' topic and a 'Study Hall' topic). I could have done a variety of string checks to avoid this, but decided that adding an AutoCompleteTextView would be the most straightforward way to go. There are a number of good tutorials and examples of using AutoCompleteTextView readily available online. It is very easy to implement in any typical Activity. However, when you use it in a dialog box, you have to explicitly tie it to the desired dialog in a way that isn't immediately evident (at least to me) in the available tutorials. My dialog box crashed time after time, and I had narrowed my problem down to the ArrayAdapter initially. As it turned out, it was a domino effect: the ArrayAdapter was crashing because the app was apparently confused about who owned the findViewById that was taking the dialog layout that was getting the AutoCompleteTextView. Anyway, here's the code that works, in case anyone else finds themselves in this situation. [source lang= "java"] @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.main); // topicnotes database topic_notes_data = new TopicNotesData(this); // The button to add new notes final Button btnAddTopicNote = (Button) findViewById(R.id.Button_AddTopicNote); btnAddTopicNote.setOnClickListener(new View.OnClickListener() { // Here's where the custom dialog is created @Override public void onClick(View v) { // custom dialog final Dialog dialog = new Dialog(context); dialog.setContentView(R.layout.addtopicnotedlg); dialog.setTitle("Add Topic Note"); // this is where we need to have dialog explicitly call findViewById final AutoCompleteTextView topicText = (AutoCompleteTextView) dialog.findViewById(R.id.AutoCompleteTopic); ArrayAdapter adapter = new ArrayAdapter(context,R.layout.list_item,getAllTopics()); topicText.setAdapter(adapter); Button saveButton = (Button)dialog.findViewById(R.id.Button_SaveTopicNote); saveButton.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { if(topicText.getText() != null){ String strTopic = topicText.getText().toString(); EditText noteText = (EditText)dialog.findViewById(R.id.EditText_Note); String strNote = noteText.getText().toString(); } dialog.dismiss(); } }); Button cancelButton = (Button)dialog.findViewById(R.id.Button_CancelTopicNote); cancelButton.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { dialog.dismiss(); } }); dialog.show(); } }); } [/source]

I just wrote an entry in my blog about stumbling across an old space shooter game that I had started in some long forgotten directories on my 5-year old laptop. After I wrote it, it occurred to me that I still had a an old Dell Dimension 4400 tucked under my desk in my study that dates back 10 years (40 GB Hard drive, 1.60GHz Pentium 4 chip, 256 MB RAM!). I fired it up, and lo and behold, I had access to all kinds of old programs (probably enough for an entire new blog entry), many of them the results of learning exercises and attempts to master certain fundamentals.
Anyway, I thought I'd ask the question to anyone who's been developing games for a while: anyone have any screenshots of early efforts--like when you were still learning the trade? Not necessarily stuff that may have come by following instructions in a book, but genuine early efforts where you were creating nearly everything, that may look strange or amusing to you now or even surprise you when you look back at them?
Here's (one of) mine: this is an early attempt I made at writing an isometric graphics engine--this was in 2002, probably a year or so after I had given some serious effort to learning C++. Hoo boy, is it hard on the eyes, but I got real kick out of watching it play again today. They're hard to see, but the sprites are vikings and skeletons that were animated in Poser, exported as an .avi, then imported to Animation Shop 3.0, then cut and pasted into a single bitmap image in Paint Shop Pro 7.0. Not very efficient, but it worked. While you couldn't click on a viking, you could toggle through them, and click on a skeleton. Once you clicked on a skeleton, the viking that was highlighted would walk over to him and start wailing on him. The pathfinding was primitive, and the collision detection a little off. And don't get me started about the horrible (lack of) anti-aliasing.

I remember all too well ignoring all the warnings about hard-coding variables--always seemed expedient (told myself 'temporary') at the time, but almost always overlooked one that would cause hair-ripping bugs.
That said, I'm a huge fan of rogue-style games. I really like the rendered dungeon with the ascii characters twist. And incomprehensible codebase or not, those are some sweet images for Golem!

So I've been plugging away on the same laptop (Toshiba Satellite with Windows Vista) since about 2007. Yes, it's 5 years old, and has far outstripped the longevity of any other windows machine I've owned. That point aside, like a digital archaeologist, I came across some long forgotten directories, and found a game I had started programming back in 2008--a simple arcade style spaceship shooter. I stopped working on it because real life happened, and my attention simply had to be elsewhere. In the main directory was a short video clip I had put together using Anim8or and Bryce that I was going to use for the game intro. Here are some screenshots. INVASION! The Saucers Approach Earth! Here are some shots of the prototype game screen. Just an image of Earth, with wave after wave of saucers flying past. After each pass, the saucers would get smaller as they get nearer to the planet. I here were rockets that you fire after the invaders, but the animation and explosions were fairly crude. After I stumbled across this program, I suddenly remembered how much I enjoyed working it. Maybe I'll have to try and reanimate the project as an Android game. Source

Very nicely done--didn't notice any significant bugs on a few first passes, though the persistent cursor on the screen should probably go away. The controls took a little getting used to--combat against multiple adversaries was certainly difficult, but that's not necessarily a criticism. I thought the equipment menu was a bit confusing, but overall a solid start. I tried it both on my phone (Droid Bionic) and my Xoom. Played well on both, didn't experience any force closes or notice any lag.
Good job, looking forward to updates!

I've been programming as a hobby off and on for over 10 years. To this day, I consider myself an "advanced beginner." My gateway into programming began with C++ and a copy of Ian Parberry's Learn Computer Game Programming with DirectX 7.0 (a very, very good book in my opinion). When I started to think that I'd really like to pursue game programming, I also got my hands on Game Design: Secrets of the Sages, edited by Marc Salzman. It was an interesting book, but the part that I remember even today is mainly the game pre-production part of the book, which emphasized the importance of design documents, story boarding, and the like. Unfortunately, I promptly ignored the advice as not applicable to small projects like mine. I wish I hadn't ignored it. When it comes to games, I used to have a rather annoying self-defeating approach to development, in that my simple idea would quickly be overcome by feature creep. Lack of focus and direction is, I'm willing to bet, the biggest obstacle to single-person and small team game development. Lack of focus on a design can drag development out insufferably. A personal example of this is my first attempt at a true video game--it was a board game inspired by the game of Checkers called KingMe! What started out as a simple one-or-two player game idea soon morphed into a monstrosity, complete with 8 different game variations and chat-enabled multiplayer support. It looked great in my head, and in my head it remained. I soon realized that development was grinding to a halt, so I broke the concept into three game versions: a "Granite" (simple version, freeware), and "Iron" version (same as Granite, but with networked multiplayer support, and a "Gold" version (everything else). Fortunately, I was able to finish my "KingMe! Iron" version in 2003, but it took 2 to 3 times as long as it should have. The Iron and Gold versions were never completed. Screenshot of the KingMe! Granite game--my first game that barely made it out of a bog of feature creep. Fast forward several years to the present day and my current project, Titan Trivia. When I decided to go ahead with Titan, my old habit paid a visit with all kinds of cool ideas, but I was on to it. I decided I needed something to focus on, a document that would keep me tuned to my original game design. That's not to say that changes haven't been made, but even now I'm surprised how well this document has kept me focused. In fact, I found that contrary to my original attitude toward design documents (that they would inhibit creativity), my Titan Triva document in fact gave me a consistent starting point for more relevant inspiration. It's not a complicated or sophisticated document--it's simply a few slides I threw together in OpenOffice that outlines the basics of design and function ideas, but I referred to it often in the initial days of putting together the pieces of the game. I'll wrap this up here, but below are a few comparisons of my original design document concepts beside the more-or-less final versions of the interface. The "Load Databases" button is a convenience button for me as I add trivia questions. It won't be on the actual release version. Source

One of the GUI elements I wanted for Titan Trivia was an expandable list for the Trivia question categories and subcategories. Easy enough to do, or so I thought. All the example code that I found online and in my texts were filled with pre-defined data. In other words, you had to know beforehand what your parent and child elements were going to be and hard code them in. I needed something a little more flexible, because my parent and child elements were changing regularly. After more consternation over the code than I'd care to admit, I finally got my expandable lists reading and displaying the trivia question categories and subcategories without me having to hard code ahead of time. Figuring out how to do that was frustrating at times, but of course satisfying when I finished. I decided to put together a quick 'how to' in case there are others who find they may want to do the same thing. I have no doubt there are more elegant ways of implementing what I have here, but at the very least I know this code works. Instead of pulling out the code I've implemented in Titan Trivia, yesterday I sat down and put together a quick app that demonstrates the functionality. The app is called "TopicNotes", and it does what it sounds like. It lets you write a note with a topic. If you write another note with the same Topic, it will file that note under the same Parent list header, as in this screenshot: The interface is simple. Just a single button and an expandable list below it. When you click the button, you get a dialog box: When you click OK, the topic you just entered a note for goes to the top of your list on the main screen: Yes, I know this isn't pretty, and there are some glaring omissions in the app (for example, there's no delete function). I may add to it over time, but for now, I just want to demo the dynamic expandable list code. First, you'll need to override the BaseExpandableListAdapter. Depending on your skill level, this may sound intimidating (I admit I was a bit put off when someone casually suggested it), but it's not that hard for what we're doing here (there are several variations of this to be found online, but if you want to see the code I used for this example, you can find it here: http://numberedmount...overriding.html). I may write a comprehensive tutorial to cover this part as well if there's interest, but for now I'll stay focused. So, into the main Activity file (TopicNotesActivity.java) I write a function to return an instance of the modified adapter. Note that it calls two additional methods: getAllTopics() and getAllTopicNotes() that return a String array and a 2-dimensional String array respectively. These arrays are required by the ModifiedExpandableListAdapter instance. The Topics and Notes are saved away in a SQLite3 database table. [source lang="java"] [size=2] private ModifiedExpandableListAdapter getAllTopicNotes(){ String[] topics=getAllTopics(); String[][] contents = getAllNotes(topics); ModifiedExpandableListAdapter adapter=new ModifiedExpandableListAdapter(this,topics,contents); return adapter; } private String[] getAllTopics(){ String[] topics=null; int index=0; int size=0; SQLiteDatabase db = topic_notes_data.getReadableDatabase(); Cursor cursor = db.query(TOPICNOTES_TABLE, FROM, null, null, TOPIC, null, ORDER_BY); size = cursor.getCount(); topics = new String[size]; while(cursor.moveToNext()){ if(cursor.getString(1).length()>0){ topics[index]=cursor.getString(1); index++; } } cursor.close(); return topics; } private String[][] getAllNotes(String[] topics){ String[] temp={}; String[][] notes=null; int index=0; //int size=topics.length; notes = new String[topics.length][]; SQLiteDatabase db = topic_notes_data.getReadableDatabase(); for(int i=0;i

Adventure and Interactive Story games--my all time favorite being Grim Fandango (hence my Avatar image). Creating a game that combines a great story, great art, cool characters, and complex puzzles together is something I've always wanted to do.

Several years ago, when I first started to explore the idea of game programming, I picked up a copy of Real Time Strategy Game Programming Using Direct X 6.0, by Mickey Kawick. I was fairly new to programming, and at the time RTSGP was a bit advanced for me in places, though I did pick up some really good pointers about game creation as a whole. I believe that was the first book I had read that mentioned the idea of creating a utility program to help with the more meticulous tasks of game creation. In the case of my current project, Titan Trivia, it became apparent soon after I began writing the first questions that the game required more than just question-answer pairs. I needed to track categories, sub-categories, answer tags, difficulty ratings, and many other pieces of data that I hadn't at first considered. Writing them into a flat file wasn't an option, and using a spreadsheet wasn't that much more appealing. I probably could've used a database program of some kind, but in the I decided to write up a custom program to do the job myself. That way I could be sure it did everything I wanted it to do. I used Visual C# 2008, and ended up having almost as fun writing it as I did writing the game itself. Anyway, I wrote the program to save to a the data to a SQL table. I'm not overly savvy with databases, and needed the questions ultimately dumped to the sqlite3 database for an Android game. Instead of doing any converting, I chose to export the table to an XML file, and in turn import the XML (on a one-time basis) into the sqlite3 database for the game. No doubt there are other, better ways to do this, but it was fun putting it together, and I learned a lot. Now, to get to the real task at hand, and start writing trivia questions! Source

Finally almost finished with Titan Trivia--the first stab at an Android game. The concept of the game was easy to come up with--it was something I really wanted for myself, and couldn't find an Android trivia game out there that offered what I wanted. I even put together a design document to gather my thoughts and ideas, and I largely stuck to it. I've had a great time programming it, and after some polish, minor features, and bug fixes, should be ready to release a beta in short order. Until then, here are some images from the latest version of the game. Source

I know I'm not the first person to make this comparison, but game design is very much like writing a book. You go through drafts, and in the beginning it's more important to focus on function than it is on presentation. Placeholder art can be invaluable even if it looks strange at the time. I was just going over my old screenshots and had fun retracing the design evolution of my Titan Trivia question screens. First attempt at a simple question-answer screen. Decided later that it needed a nice background. All the Titan Trivia question pages now have an iconic background. Latest version. I don't anticipate many more changes from this one. Source

After several months of on-again, off-again programming, I'm nearly finished with my first Android game--Titan Trivia. Titan Trivia started as a learning exercise--I had never programmed in Java before, and a trivia game seemed simple enough. Thankfully Java is similar enough to C++ that the transition was pretty painless. Within a few weeks I had more or less accomplished the simple question-and-answer format game, but decided that I wanted to take it further. I decided to make a game that I wanted to play--not just in general, but for specific occasions. On road trips my wife and I like to pass the time trying to answer trivia questions, and there aren't that many good trivia game apps out there. Even the decent ones lacked features I wanted--so I decided to and created a design document for trivia game I thought sounded pretty fun. Now, at (somewhat) long last, I'm nearly finished. I have a few features to finish, some interface polish to do, and a few bugs to hunt and kill, but the primary game is essentially finished. In fact, the biggest challenge now is building the database of trivia questions.

Spent some time getting to know SQLite a bit better tonight. I have code that reads an xml file and drops the data into a sqlite database. That works fine, but what I needed was to be able to 1. Create the database from the XML prior to distribution (wasteful to send xml with the program only to be written into the db), and 2. install the database during the initial use of the program. Did some digging around online and found some great resources on stackoverflow.com. The main issue I need to work out now is when I want to update the database in the future, meaning add additional tables, I need to be able to do that without blowing away other tables. I think I'll just start with a base db file, say database1, and when I want to update, i'll call it database2. During installation, maybe I can have the software copy database2 onto the device, open it, compare with database1 tables, and copy over any tables not already present, then delete database2.

Just curious how many Android game programmers here have started working with the Android 3.0 SDK? Personally, I'm still working on Android 2.1 and 2.2--haven't downloaded either the 2.3 or 3.0 SDKs yet.

[quote name='modemancer' timestamp='1300842213' post='4789347']
Just curious how many Android game programmers here have started working with the Android 3.0 SDK? Personally, I'm still working on Android 2.1 and 2.2--haven't downloaded either the 2.3 or 3.0 SDKs yet.
[/quote]
Er...I meant Android 3.0 Honeycomb, but Gingerbread is good too.

Just got a copy of the Lucasarts classic game Grim Fandango, one of my favorite PC games. Interesting that a game that was built in the days of 386/486 processors (in fact, computers with a CPU Speed of 400 MHz had to download a special patch for some of the puzzles to run correctly) can be found selling on Amazon for $89.99 for a new copy and $25.99 for a used one (I spent considerably less on Ebay for a used copy). Vista doesn't like to run it (running it in Windows 95/98 Compatibility Mode seems to offer the most stability), but it's worth the occasional crashes to play this excellent game.

[quote name='Kevin Hawkins' timestamp='1300911491' post='4789640']
Grim is one of my all-time favorite games. I've held onto the original discs since its release in 1998 and have played through about once every 3-4 years. I had no idea it's been almost 13 years.. this post might motivate me to install it and give it another round.
[/quote]
definitely worth it. I've played it through a few times over the years, and the gameplay, art, and plot never lose their ability to draw you in. Incredible achievement, really.

[quote name='GameCreator' timestamp='1300732958' post='4788750']
Definitely one of the best adventure games ever made. What made you get it now?
[/quote]
Actually, I was looking through some old boxes in my closet and came across the B disc. I searched for hours and couldn't find the A disc. By that point, I had caught the fever again and went to find it online. I was shocked at the going price, especially since I remember going into Best Buy a few years back and buying it for $5 bucks a copy for gifts for friends. Oh, well, I'm nearly through Year 2 now and it was worth the price (I think I paid $25 for it).