Category Archives: Weirdo Game

Posts involving my side scroller game, Weirdo in a Weird Land

Weirdo mythology

I was considering the mythology of the Weirdo a moment and thought it might be fun to flesh out the character as a little kid.

It’s basically the start of 90% of all little kid stories.  You have a little kid who has an overactive imagination and next thing you know, all hell breaks loose.

I’m not really interested in coming up with a original story here, just a fun one… so starting with a cliche such as the weirdo being a little kid who happens to have a toy helmet is a safe premise to build from.

I find it unlikely any of the concept art stuff like the image to the left will ever actually make it into the game, but I need the drawing practice… and I wanted things fleshed out.

 

 

The Weirdo

After sketching out a few different characters, I think that this is the overall shape that the Weirdo will take.

Yeah he kind of looks like Marvin the Martian, but meh. He’s easy to draw and that’s pretty important for me.

 

Terrain Tiles

The challenge here is, What is the minimal set of terrain tile types to be able to build arbitrary terrain in a side scroller?  In theory, you don’t need minimal sets of anything if your blocks fit exactly into a square.  You see that all over; especially in the older Nintendo classics.  I want to be able to use a more diverse set of borders though… and I *think* the above image represents a complete set.

That’s not to say that each type of tile won’t have many distinct tilesets… Hopefully I will have quite a few distinct tilesets for this game.

Building for Windows!

Download the Windows Version!

It took me a while to get there, but I’ve finally gotten a Windows build of the Weirdo in a Weird Land bootstrap project!

My first attempt at building one involved grabbing Visual Studio 10 Express but it really wasn’t meant to be used from the command line… at least not easily…

The successful strategy was to use the Minimalist GNU for Windows toolchain.  This lead to some heartache which began with linker issues… but working with the SDL FAQ, I got things mostly working.  Of all the problems, the most surprising to me was the fact that including libraries in gcc is significant.  Specifically… the following did not work:

$(CC) -o $(BUILDDIR)/$(EXETARGET) $(BUILDDIR)/main.o \
    $(BUILDDIR)/Level.o $(BUILDDIR)/SDLAppMain.o \
    -L$(SDLDIR)/lib -L$(SDLIMAGEDIR)/lib/$(ARCH) \
    -lSDLmain -lSDL -lSDL_image -lmingw32 -mwindows

but THIS did!

$(CC) -o $(BUILDDIR)/$(EXETARGET) $(BUILDDIR)/main.o \
    $(BUILDDIR)/Level.o $(BUILDDIR)/SDLAppMain.o \
    -L$(SDLDIR)/lib -L$(SDLIMAGEDIR)/lib/$(ARCH) \
    -lmingw32 -lSDLmain -lSDL -lSDL_image -mwindows

The significant part here is the -lmingw32 being first.  Without that, I got the following linker issue…

Undefined reference to 'WinMain@16'

Which is discussed in the FAQ… but the answer did not point out that the ordering of the libraries was significant!

Now i just need to create a proper Makefile that will switch easily between the two architectures…. then it’s time to actually write the game!

UPDATE: The original zip that I uploaded seemed to be missing a few necessary files… specifically two DLLs: libgcc_s_dw2-1.dll and libstdc++-6.dll both of which are now part of the distribution.

Weirdo in a Weird Land

Weirdo in a Weird Land is the working title for the slowly progressing game.

It took a while to actually get the application bundle squared away.

Click Image to Download v0.0.1!

One of the more irritating parts of creating the bundle was referencing the image resources.  Mac Applications are supposed to keep their data in a Contents/Resources but using the provided SDLMain, your application’s working directory is the PARENT of the resource bundle… so you’d have to make the assumption that the end user didn’t rename the application bundle on you and build your path including what you think your resource bundle is named.

I modified the SDLMain a little bit, putting the working directory at the top level of the Application Bundle.  This allows me to reference my image files as: Contents/Resources/Images/ which is still a little ugly, but probably more reliable.  The “correct” thing to do would be to have SDLMain expose a method which allows me to retrieve the path of individual resources.  That’s probably a much later change though.

My most recent efforts are to get a Windows build going.  I’d like to do the up front work to make this game cross platform.  This way, I can release builds for both Mac and PC/Win32 relatively easily in the future.  My first attempt at creating a Win32 build was using Visual Studio 2010 Express, but I ran into a lot of strange linking issues.  The compilation process was tough too.  cl.exe command line compiler had radically different invocations than gcc… so it’s unlikely that I’d be able to reuse the same Makefile. There has to be an easier way to build a windows app than this…

The SDL Tutorial suggests using mingw32 which is a minimalist windows toolchain built on top of all GNU tools.  This means that I *SHOULD* be able to reuse my Makefile and if it’s part of the tutorial… I shouldn’t run into weird issues.  We’ll see how that pans out.  Hopefully by Thursday I’ll have a slightly expanded build that runs on both Windows and OSX!

SDL side scroller takes shape

 In my previous post on SDL, I talked a little bit about layering bitmaps to create a simple side scroller.

Here, I’ve actually gotten bitmap layering to work.  I’ve used the rough bitmaps that I drew for the last blog post and built some code around it.   I haven’t gotten to the point where I can built a distributable binary yet, but I’m hoping that it won’t be too tough.  I’m hoping to NOT have to involve xcode… but all literature I’ve found on building apple distributables seem to center around that tool.

Here’s a screenshot of the resulting app.  Doesn’t look very different from my mockup… but that’s probably a good thing.

The way this ended up being implemented was through a Level class.  The Level class has an array of Layers and a current position (x axis).  Each layer has a coefficient that describes its motion relative to the Level’s x position. Foreground objects have a coefficient of > 1 and objects further in the background have coefficients less than one.

Each Layer has an array of LayerObjects. Each LayerObject which includes a bitmap and a coordinate. They’re arranged in the Array in increasing order of x.

I captured the SDLK_LEFT and SDLK_RIGHT key events.  When SDLK_RIGHT is pushed, I’d increment the level’s x position until the key was released.  Similarly for the SDLK_LEFT button except the position is decremented.

 

 

 

 

Layers of Detail with Blitting in SDL

Continuing with my efforts to learn SDL, I’ve drawn kind of a silly set of bitmaps that will be sewn together to form a landscape.

To the left you see a composite of 11 distinct images.  Each image falls into one of 4 layers, Foreground, Middleground, Background, Clouds, and Horizon.

The point of having multiple layers is to simulate depth in a simple side-scroller.  The “closer” the layer is to the user, the faster it’ll slide across the screen.  In the case of the “Clouds” layer, it has a slow but constant motion of its own.  In my simple tileset, I imagine the player to be somewhere in between the “Foreground” represented by the green/orange things stuck to the bottom of the screen and the “Middleground” which are the bent looking rectangular structures in the middle of the image.

For the programming part of this exercise, I’ve been simply following this SDL Tutorial.  That tutorial basically gets you a class that manages the lifecycle of your game along with the main() method.  I had a little bit of trouble getting this to work in OSX, but it turned out that I simply needed to RTFM.  If you’re trying this on a Mac, be sure to copy SDLMain.h and SDLMain.m from the “Extras” folder in the .dmg.

The lion’s share of the work in this SDL_BlitSurface(). This method is well described in the second SDL TutorialBlitting is really just the act of drawing one bitmap on top of another.

To implement layers as described above, I’ll create a class called an ImageLayer which takes an array of SDL_Surface objects (images) and an array of coordinates representing the upper left corner of each instance of the image sorted by X coordinates.  As the layer gets scrolled left or right, it’s a simple matter of keeping track of which image instances represent the extreme edges of what’s visible. All images in between these extremes get rendered.

With multiple ImageLayers populated with images and where they are, you render each layer from furthest to nearest.

screw this noise, libsdl to the rescue!

I’d spent the last week beating my head trying to learn the dark arts of programming for the OS X.  I had basically gotten a window to open up… but that was it.  Did i really want to learn this? or was this simply a means to an end?  I’m guessing it’s the latter… there has to be a better solution than this. Turns out there is… libsdl.

It had all but skipped my mind… the Simple Directmedia Layer.  It’s basically a platform abstraction library that lets you write media-rich native apps without worrying about what the underlying architecture is.

I first tried using it about 5 years ago and was fairly impressed.  It’s easy to use and has a whole mess of language bindings.   I think I’ll be doing more of my n-body stuff using this lib as the front end instead of trying to learn all of the cocoa specifics.

Hopefully, this time next week I’ll have something that’s downloadable, runnable, and interactive!

Objective C, C++ and OpenGL

I started working on converting my N-Body simulation code over to C/C++ and realized that I had no idea how I’d actually display the results.  So… it was time to learn a little about displaying stuff in OS X.

One thing that struck me as ungainly was having to use XCode when really all I wanted to do was get myself a window and draw to it. This lead me to this awesome blog post showing a very minimalist Cocoa app.

With that start, I thought that I’d try to do most of my work in C++ instead of Objective C… so how does one do THAT in OS X?? There seems to be a bunch of literature about how to make C++ calls from Objective C… but not the other way around, which is really what I want to do… I want my C++ code to be the driver of the application and use Objective C to pass events and display results… It was stackoverflow to the rescue with this article: http://stackoverflow.com/questions/1061005/calling-objective-c-method-from-c-method

Essentially, you write yourself a C header with some forward declarations for methods that are later declared in a .mm file.  Assuming that you’re coding in C++ instead of C, compile with g++ or you’ll get a lot of strange missing symbols at link-time if you use plain old gcc.

Once I have things going smoothly, I’ll post the skeleton code up on github!