The Difference Between Bing and Google

Bing has pretty pictures. Really pretty pictures. I can’t get enough of them. I tend to leave it as the default search provider in IE because of that fact. That and the little factoids are pretty interesting as well.

But Google gives me _useful _results.

grepping in windows

I came across this a long time ago, I don’t even remember where. Though I’m not such a huge fan of the powershell in general, it has served me well when I need it.

get-childitem c:windowssystem32 -include .txt -recurse | select-string -pattern “Microsoft” –casesensitive

man get-childitem and man select-string for more info on your options.

Slow Progress. But Progress.

I’ve made a bit more progress with BugCatch over the past week. Certainly nowhere near what I would have wanted, but it’s been quite a learning experience. Tonight I got some of the groundwork in place for moving objects around the screen, and randomly creating ‘bugs’.

It’s pretty clear I’m not going to meet the original goal of being done by end of October. In the end I can live with that. I’ve done a ton of research and feel pretty confident about my direction at this point. Now it’s just a matter of time and implementation.

Below is a quick video (mp4) of some blocks running across the screen ;). If you’re running chrome you can watch it inline. If not… here you go.

Eclipse from a Visual Studio Perspective

Last night I began by spending a little time trying to figure out gestures on Android, and got wildly distracted by the notion of workspaces in Eclipse. My development thus far has been mainly in OS X. I thought it might be quick to just pull from mercurial and start back up on my desktop (win7) for a while. Oops.

The notion of a Visual Studio solution is analogous to the Eclipse workspace. Well, kind of. The problem seems to be that a workspace doesn’t just contain information about a collection of projects, but additional metadata about the _environment _itself. For instance, it also contains pointers to the SDK in use (for Android) and I assume similar information for other project types.

I suppose this is a pretty flexible model for dealing with many projects with varying targets and dependencies. The more I think about it the more sense it makes if you’re looking at it from the vantage point of an open source developer that may be dealing with 5 different versions of 12 different projects. In my case all I really want to do is share my source between my two machines. My natural inclinations (coming from a Visual Studio background) failed me completely.

To compound that, the plethora of ways to create new projects and their various side effects, such as whether the project is copied or linked, is kind of mind boggling. Again, I’m in unfamiliar territory. And I’m a developer… so no, I didn’t RTFM.

I did seem to find a solution that gets me to where I want to go though. I created a directory similar to this:

  android
src
project1
project2

win
osx

where android is the root directory of my mercurial repository and contains everything related to the particular project. The actual projects reside in srcprojectname and can be shared across workspaces. the win and osx directories actually contain my workspaces for the respective operating system. It’s not ideal, but it keeps the workspaces from my Eclipse instance in osx and win7 from stomping on each other, and everything seems to be working well so far.

To actually get the projects into the workspace, I’m using the File -> Import menu. From the import dialog I select “Existing Projects into Workspace” under the “General” node, and select the project directory in the next step of the import wizard. Leave “copy projects into workspace” unchecked so the source stays where it is.

Some Skeleton Logic

The premise for BugCatch is pretty simple. Kids are presented with a virtual playing area many times the size of the phone’s screen. They are tasked with searching the landscape for certain bugs that they need to either catch or squish. A small HUD will give them access to a few implements to switch between (such as jars/nets/shoes/hands) to accomplish this. Scrolling will be done by swiping across the playing area. Catching or squishing is just a simple tap on the moving bug. Different bugs will move in different ways and be harder/easier to catch depending on type and difficulty level.

I jotted some notes this afternoon with some pseudo-code for some of the core methods in the game engine.

Init()
    clearInput()
    resetState()
    GameLoop()

resetState()
    if NEVER INITIALIZED then init
    setLevel()
    setGoals()
    createBugList()
    setBugListState()

GameLoop()
    getInput()
    updateActions()
    updateAI()
    updateGameState()

getInput()
    if INPUTS
        store action

updateActions()
    if SWIPE
        move background
    if TOUCH HUD
        hittest catcher
        hittest options
    if TOUCH PLAYAREA
        hittestBugs()

hittestBugs()
    foreach BUG
        if HIT
            goalCheck(bug)
            tagRemoveBug

goalCheck(bug)
    foreach GOAL
        if GOAL +matches bug
            satisfyGoal()
        else
            exposeError()

updateAI()
    foreach BUG
        if TAG REMOVED
            removeBug
        else
            moveBug

updateGameState()
    updateTime
    checkForGoalsComplete
    checkForEndOfTime

    if GOALS COMPLETE
        winGame
    if END TIME
        loseGame

setLevel()
    setCompleteTime()
    setHitboxSize()

setGoals()
    createGoalsList(level)
        randomly select a set of goals, taking into account level
        select time limit based on level

setBugListState(level)
    inspect goals
    select bugs req'd for goals
    select additional bugs not required based on level.
    create random distribution based on level (lower level == greater percent bugs req'd for goal)
    populate bug array.

Getting Behind

The first week of October was the opposite of the kind of effort it’s going to take to actually finish an app by the end of the month. Lots of distractions kept me from doing much work on the challenge. Mind you, they were mostly my of my own creation. This weekend was terribly lazy and I probably could have gotten quite a bit done, though it was pretty great to spend some time with Matt and Sascha.

I find I do this a lot. When I’m starting a project, especially when I’m not completely clear on the direction I need to go. It seems like it’s easy to procrastinate and go back and forth with ideas and never get anything accomplished. I get this paralyzing dread whenever I think about whatever it is I should be doing. I start going through the list of questions that need answering and tasks to be done. The longer it gets, the more inclined I am to promptly turn on the TV. I’d be a lot more accomplished if I could figure out how to just get things done. The way out (and I’m well aware of this, but that fact doesn’t seem to help) is to just start in on one small thing at a time until they add up to something substantial.

The problem I was facing was that I hated what I had written. I didn’t feel like I was really understanding the way my drawing thread was interacting with the Activity. It was a complete mess. So I started from scratch tonight. I stripped out everything but the essentials and stared building up with a bit more rigor and style. Style is not to be overlooked when you’re writing code. Of the developers I’ve worked with over the years, the ones that really impressed me have this supernatural ability to format source in a clear and concise way that just makes it sexy. Unfortunately the profession tends to contain a lot more developers that appear to like to drink when they write their code. But I digress…

So back to general code cleanup and trying to reshape my understanding of how to put a good game loop together and tie it into the paradigm of Android development. A big stumbling block is how to decouple the drawing thread from the rest of the loop. I’m still not 100% on this, but I’m a little happier with what I wrote tonight. The big foggy right now is making sure I’m synchronizing between that and the logic thread appropriately. All the examples I’ve seen kind of mush that all together in a way that I’m skeptical about. Hopefully I’ll have that all figured out by tomorrow.

Off to test out some theories…

Bug Catch!

Tonight feels like the first night of actual coding. Although I’ve had the idea firmed up, picked a name, and had some very basic skeleton code for the project in mercurial for a few days, I finally feel like I’m starting to understand the basic structure of the game and how it’s all going to come together. I’ve been relying heavily on the SDK sample for lunar lander to get me pointed in the right direction. That seems to be one of the most common references in answers to “how to I write Android games?” questions.

The prevailing wisdom suggests keeping all of the rendering code for the game in its own thread separate from the rest of the game logic. Lunar Lander doesn’t go quite that far. It combines the rendering, game logic, and physics all in one thread, but separates that out from the main Activity. Following the same sort of organization I’ve been able to do some simple tests to get a background drawing, and to handle input events. Touch events (specifically ACTION_MOVE) don’t appear to be registering on the emulator. I’ll have to test it on a real device tomorrow to know whether it’s my code or just emulator madness. Additionally I was able to shim in a simple timer and a frame counter and rate target. Currently all my metrics are dumping to the log, so it would be nice to get those displaying to the screen along with a simple HUD for the game.

I’m at the point where I need to start breaking everything out into logical systems and organizing the code a bit better. More of a true game engine than the slop fest I’ve got going on right now. Now that I understand the basics it’s time to dig into the source of Replica Island a little more. It’s far more complex than anything I’ll need for Bug Catch, but it seems like a good code base to read to help me form a better picture of how all of the systems in a game need to be organized.