I've noticed that quite a few people keep development journals or blogs and I thought I'd try doing one to see if it helped keep me committed to my project. Rather than sign up for some site to make a dedicated page for this, I figured I'd just do it here.

So, my project...

I'm trying to recreate Miner 2049er a 1982 game for the Atari 800 that was also ported to several other systems available at the time. This was my favourite game as a child, and was the first computer game I completed.

The idea behind the game is that you are Bounty Bob, a Canadian Mountie who is searching for the notorious criminal Yukon Yohan in the radioactive Uranium mines belonging to a guy called Nuclear Ned.

To finish each level of the game, the player must step on every square in the level, which clears it, while avoiding contact with radioactive mutants who wander the mines. Along the way, you find items abandoned by previous miners, which when picked up give the player points and also make the mutants safe to walk into for a period of time (walking into them at this point destroys them). There is also a time limit for each level.

Progress so far:

I started with a C++ Allegro Template I created which takes care of timing, animation, Allegro initialization, and which also provides a Game class with a few common elements that can be extended for specific games.

I've also created a player class, which contains all the animations for Bounty Bob, plus functions for walking, falling and repositioning Bob, as well as floor and floor manager classes which take care of loading all the graphics for the various floor types (two types of regular tile, a cleared tile, and a un-clearable tile), and which also take care of checking if Bob is currently on (or in, since he moves at fractions of pixels) the floor and whether or not it therefore needs to be cleared.

Here's the latest screen-shot of the project:

{"name":"600929","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/4\/f\/4fa058e1d0ecc4ce53fb00903c78d81d.png","w":646,"h":506,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/4\/f\/4fa058e1d0ecc4ce53fb00903c78d81d"}

To Do:

Next, I'm going to implement jumping, since at the moment, I have to postion Bob on clearable floor to test that the floor, falling and movement functions work correctly.

Once jumping has been implemented, I'll add ladders and climbing functions, then the rest of the gameplay factors from the later levels - chutes, moving platforms, transporters, a lift, pulverizers and the cannon.

Then I can add the mutants and I'll also make Bob killable at this point. Adding scoring and the clock will come after that, at which point the game is essentially complete.

Challenges so far:

I'm working from a Windows based emulator that the original author wrote, and which runs in the original resolution of 320x240. I had to take several screenshots while playing in order to get each frame of the animations from the game, though luckily, there aren't many.

I considered keeping the graphics in the original size, and then resizing as I drew the buffer to the screen for the final resolution, but instead decided to resize all the graphics myself to double their size and go with a 640x48 resolution. For this, I copied the sprites from the screenshots using Graphics Gale and saved them to a directory and then wrote a small program to load every bitmap from a directory, double their size and then resave them.

I also wrote a small program which creates the level file and writes the positions of all the floor tiles, as doing this by hand was going to be too time consuming (I hope to eventually write a graphical editor to take care of doing this, but don't ant to get sidetracked).

Not having the original code to work from, I'm having to guess at how fast to move everything. I've made a rough estimate for now, and I'll tweak these values later on, once more of the gameplay elements are in place.

So that's where I am for now. Hopefully I'll be able to report on more progress soon.

You could polish the game further. In fact there should be some difference between the game developed in 1982 and one that is being developed in 2010 .BTW where's the link to progress blog ?.

I forgot to mention that the purpose of this isn't just to recreate the original, but to also allow new levels to be created. I don't intend to improve the graphics, mostly because I have no drawing ability, but anyone else can replace them if they want to.

This is the development blog.

Get a dev journal on GameDev, or see if Matthew has any plans to incorporate an equivalent, or just go to Blogspot or start a LiveJournal or something. No need to put it here.

I just incorporate mine into my FaceBook page/albums.

I'm trying to see if feedback will help me keep motivated. I figure that since nobody outside of the Allegro community will be interested in this at all, that A.cc is the best place to do this.

But this thread will be closed quite a while from now.Will you start a new thread again ?

I don't intend this to take long enough for the thread to get closed.

You could have done that using the batch conversion function in XNView (which is a free image viewing/manipulation tool) to save you some time.

For that, why not just draw the levels in any paint tool which supports paletted images? In the simplest example, each palette index would be interpreted as a different tile-number. You'd save all the time needed to create that level editor, because it becomes unnecessary.

How is a thread here any different or less suitable than any other place?
In fact I think it would be much more convenient to skim through progress logs and to inspire more conversation and discussion if they're all contained on a single site instead of every Joe Shmoe running their own small blog that nobody ever reads.

Work faster so you can start playing DF.

Yea, I know. I do use XNview quite a bit as it handles PNM formats better than Irfanview. I like writing small programs like that though, and I keep them all together in a directory on my PATH so that I can call them any time from the command line.

That was my original idea. I've decided to make the game a lot more extensible than it seems, since then though. The game only uses a limited number of floor tiles and animations because that is all that is in the resource directory. I don't have to change any code to add more types, I just add extra images. So the map file is just a list of objects, and their properties, of which are their position, their floor tile number, whether or not they are clearable, and if so, which floor tile number to use when cleared.

When I do release this, I won't supply any graphics that I'm using in these images (though I will supply dummy bitmaps), unless I can get permission to. So people can easily make their own graphics to replace the existing ones, or make there own level files (which I'll give docs for) that use more floor tile types that they have created. Animation is handled the same way. I search a directory for .anm files, which contain the data for the animations - how many frames, time to display them, and the name of the animation. There is an 'animations' subdirectory of the 'gfx' directory which contains subdirectories each with the same name as the animation name. These contain a bitmap for each frame, numbered sequentially. This again makes it easy for people to add their own animations. They just need to make an .anm file (again I'll give docs), and create a directory with images in it.

I want to extend the level file to be more than just a list of items. For example, being able to specify a line of a certain tail type with a code sequence and the start and end position. Ladders and chutes will be stored this way anyway, probably.

Heh.

I went out for a while tonight, so haven't done a lot since. I got started on jumping before I left, but struck a bizarre bug in my animation class. There's one animation that if I don't declare before all the others will crash the game when first used. It didn't matter if I used a completely different set of graphics and .anm file, so it appears to be some weird memory bug. I'm avoiding it for now rather than fixing it by just declaring that animation first, but I'll need to fix it before I release this. I've used these same animation functions several times before though, without ever having an issue like this.

Your game will seem quite unfinished without a girl for the hero to get in the end, or other places.

It's funny to see the only complete game I've ever finished is my Xmas Hack entry. I think that you should put kind of a deadline for the project. You'll organise your time better, focus on what you think it's important, etc.

I can't talk too much about committing myself to a project though, since I haven't opened Code::Blocks for a week, but I think you're doing the right thing of choosing a thread as a personal log.

I did this once in another community for a project that took me 4 months. The thread got enough bumps to be alive that long. I don't think I'd have ever finished it if people hadn't given me so much positive feedback.

{"name":"600934","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/4\/04432831358b7371ecdf605ba0c034ed.jpg","w":640,"h":48,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/4\/04432831358b7371ecdf605ba0c034ed"}
Wow!

I'd say, once you get it finished, play with adding a "modern" mode. And give the ability to switch in-game from retro mode to the modern one(like Secret of Monkey Island SE did). You don't need to bother with making the graphics, just give some templates(a background, a foreground), and that could be the killer detail for the game.

Oops! Maybe I'll do that for an extra-challenge mode.

Yup, that's just one of a few ideas I have for when I get the remake done.

Now for a progress report... I've added jumping. It doesn't look 100% like in the original, but I'll fix that up later.

Bounty Bob takes a leap:

{"name":"600937","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/e\/0e2a2d5fa4f334ce0f501158f733bb5e.png","w":655,"h":517,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/e\/0e2a2d5fa4f334ce0f501158f733bb5e"}

I may have missed this but is it using Allegro 4 or 5?

Oh true, you said it here. I was a little tl; dr; .

My bet is on 4.

Yes, I'm using Allegro 4 for this. Mostly because that's what my template uses and also because it would probably take me longer to learn the new API than to code this project.

Good luck good sir!

Right, it's update time.

I was busy with other things for a couple of days, but resumed work last night. I instantly noticed that the code had started to get quite messy already, so I refactored everything, which has made it a lot easier to understand. I also redid a few of the existing functions to make them simpler and more flexible.

The only new feature I've added at this point is logging (a sample log file is attached).

If anyone wants to play around with this, I've attached a Windows binary as well as the source code, along with some dummy graphics that I made to go along with it. These are extremely ugly, but they get the job done.

As I've mentioned, I've designed this project to be extremely flexible with graphics, so you're more than welcome to make up your own. Because the original game only a had limited number of different floor tile types (two), that's all I've supplied, but the engine will work with however many types you want to add. Likewise with the animations. The original game only used either two or four frames per animation (and I treat the jumping sprite as a single frame animation), but you can add more frames than that, and the engine doesn't care.

The media directory that comes with the engine contains several *.anm files. These can't be renamed, but their contents can be edited. All they are is a number, which signifies how many frames in that animation, and then a list of numbers (one for each frame), which is how many ticks to display the frame for before updating the animation. Inside the media/gfx/anim directory is a set of directories with names corresponding to the *.anm file names. These contain the bitmaps for each frame of the animation. So for the bbleft.anm file (which has data for four frames), there is a media/gfx/anim/bbleft directory containing four bitmaps (named bbleft_0.bmp to bbleft_3.bmp).

One constraint on the bitmaps is that they must all be the same size across all the animations.

The media directory also contains a file named player.inf. This contains the following data: The width of the player in pixels, followed by the height (these must be the same as the width and height of the graphics); the direction the player faces (0 for left, 1 for right); the speeds of the different movements (these are also in pixels, but are floats) - walking speed, falling speed, climbing speed, jumping speed; and the height that the player can jump (also a float).

The last file in the media directory of importance is the level1.inf file. This contains all the data for the level. The first two values are the x and y values of the player's start position. This is followed by the number of floor tiles in the level. Then comes the data for each tile on the map - the x position, the y position, which image to use to for it when it's uncleared, which to use for it when it's cleared and finally the tile type (0 for unclearable, 1 for normal).

For the values for the images, these will be an integer value, corresponding to the floor_#.bmp and clear_#.bmp files in the media/gfx/static directory. Trying to set these to use a bitmap that doesn't exist isn't a good idea as I haven't added a graceful way to exit the program when this happens.

If anyone wants to contribute any graphics, they'd be very much appreciated.

I cannot open both of them,the binary and source.I have 7z installed BTW.

I've attached them in .rar format.

edit: this version will also need ladder.bmp in the media/gfx/static directory. The ladders aren't functional at this point however.

I need alld42.dll.

Oops, I incorrectly assumed most people here would already have it.

It's attached.

Update:

I've finished the code for the ladders, so they can now be used. The level1.inf file now has the ladder data immediately after the tile data. This consists of an integer, which represents the number of ladders on the level, and then for each ladder - an x position (leftmost), a y position (topmost) and the height. The width doesn't need to be specified as this is determined from the ladder.bmp bitmap.

If you want to edit this bitmap, keep in mind that for each ladder on the map, I created a unique bitmap at runtime, the height of which is the height of the ladder in the .inf file, and the width of which is the same as the ladder.bmp file. The ladder.bmp image is then tiled vertically to fill the new image, which is the one drawn to the screen.

I've attached new binary (this time I remembered to make a release version) and source archives to this post.

And a new screenshot:

{"name":"601008","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/8\/9\/898a6a5c4f4ed4169caf47cf63c5e49c.png","w":646,"h":506,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/8\/9\/898a6a5c4f4ed4169caf47cf63c5e49c"}

{"name":"601010","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/d\/3\/d3131e97fbe0565b8a01adb4b3b778aa.jpg","w":640,"h":480,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/d\/3\/d3131e97fbe0565b8a01adb4b3b778aa"}
The character is not displayed properly.I have never played this game before.How do you clear the level.

The graphics I'm using in my screenshots are copyrighted, so I'm not supplying them with the game (with the exception of the ladder and cleared floor graphics, which IMO are too generic to worry about). The graphics in your screenshot are the dummy graphics that I provided for testing.

At the moment, you can't (or rather you can, but nothing happens). When the game is finished, a level is considered clear when all the floor pieces have been walked on (i.e. their graphics changes to the solid colour).

There will also be items to pick up and enemies to avoid and/or kill.

Here's a screenshot from the original Atari 800 version:

{"name":"level1.GIF","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/7\/b\/7bcb3ad95753eb22085bd6193d5d3148.gif","w":320,"h":240,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/7\/b\/7bcb3ad95753eb22085bd6193d5d3148"}

Would it be hard to add support for alpha-blended sprites and .pngs?

I would really like to put this fella.
601012

EDIT: Oh true, I have the source code. Heck, it's a long time since I used Allegro 4, but I'd like to see this guy in action.

I'll probably add PNG and alpha blending later on in the project. It would be a fairly trivial thing to do, since everything is done with blitting.

I did already. >_< Open source FTW.

<offtopic>
@Dario ff:From what I have observed(Elven revolution and the animation demo) you are excellent at art work.You learnt that by yourselves or what.
</offtopic>

Dario, That looks great.

I'm currently rewriting the ladder manager to allow for multiple ladder types as well.

Thanks.

There's one little bug though(or a bug in the original game that you wanted to recreate?): If you try to walk against the borders of the screen, the player gets limited because of its width(15 on the left, and 624 on the right). However, if I jump facing those sides, I can bypass that limit and it turns into 0 for the left and 639 for the right.

Setting the proper limits in void game::check_jumping() fixed it.

Oops, I'd just never noticed that happening. I've fixed it here, so it will be taken care of in future releases.

update: I converted the code and graphics to PNG with alpha support. It probably took longer to convert the graphics over than it did to modify the code.

Just in time I was going to report something. Here's a screen:
{"name":"601017","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/1\/6\/16d9d0081cd8266e5d28be872b977058.jpg","w":250,"h":110,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/1\/6\/16d9d0081cd8266e5d28be872b977058"}

As you can see, I can't go down in the ladder on the left side because of the 2 pixels. This would be solved by making the stair 2 pixels taller?

EDIT: I was just about to post this when you posted the update.

Ah yes, I'm still deciding exactly what I'm going to do in that situation. If I make the ladder go higher, then it will be visible at the top of the floor tile, which never happens in the original.

I'm toying with the idea of altering the on_ladder(x, y) routine so that its tolerance is two pixels less, but then if there's a map that has a three pixel difference in such a situation, it still won't register. This is still the most likely solution I'll use however, and the onus will be on level designers to not span the top of a ladder between two tiles where the y positions are too far apart.

Another solution is to check when somebody presses down if they're on top of a tile, and if so, to check if that tile overlaps a ladder.

Next update:

I've added support for the chutes (slides):

{"name":"601031","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/a\/9aa54af605c282494730b5a76a869f93.png","w":656,"h":517,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/a\/9aa54af605c282494730b5a76a869f93"}

I need to go back and play the original game to see if they used the jumping sprite for the sliding as well, which I suspect they did.

I also modified the code so that if you jump and land so that you're standing on two tiles, both get cleared, instead of just one of them. There were probably a few other revisions I made, but that was last night, and I've forgotten already.

Sounds cool. Just in case, did you notice a bug where the player might go through a diagonal platform while jumping? I have been able to reproduce it, here's a pair of coordinates:

When you get to that exact position(1 x less or 1 x more won't work) do this:

• Jump in position. (Do this so you get more time to press the left key without moving the character).

• While in the air, hold the SPACE key and the LEFT key.

• If you did it right, you will jump and pass through the floor.

How to get to that exact position? Move with pixel-perfection, or hack the position, you're the coder after all.

Yeah, I know about that bug too. It happens infrequently enough that I haven't bothered to fix it yet, though I'm pretty certain I know what's causing it.

For small bugs like this, I'm going to wait until I have all the gameplay elements done before I go back and fix them. It's only major bugs that I'm fixing as I go along.

Update:

I've been working a lot the last couple of days, but managed to get some time in today to work on the enemies. At the moment, they are created when their data is read from the level file. There is an enemy_manager class that takes care of initializing, moving and drawing the enemies. Again, I've tried for flexibility, and have extended the class capabilities beyond the original game. In the original, ever monster in the game was identical, and all of them could be switched from a dangerous to safe mode. In BBE, you can specify different properties for every enemy as well as making them either only dangerous or only safe.

I still have to implement the collision detection between the player and the enemies, and when I do that I will also implement player death.

I've made a short video to show how the engine is looking so far:

The state changing from dangerous to safe, or vice versa, is implemented but is triggered when the player picks up an item, so isn't visible yet.

I'll make the next code release when I've implemented the collision detection and player death.

That looks good Lenny.

What kind of enemy is that? Some kind of walking squid? It's hard to recognise with only some big pixels from a little video. Just looking to make a custom sprite for it.

Nice progress BTW.

They're supposed to be radioactive mutants, apparently. This is what they look like in the safe mode, which is when you can walk into them to collect points:

{"name":"601059","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/0\/00cff4723c83972183545ee01baecf1b.png","w":646,"h":506,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/0\/00cff4723c83972183545ee01baecf1b"}

edit:

Here's some comparative screenshot of the original game and my engine about 5 seconds into the level. The positioning of the enemies is a little off as I have to tweak the starting positions and movement speed a little more.

Original:

{"name":"601060","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/e\/7\/e758b8cd07d82609ef3335efac07b9c3.png","w":694,"h":622,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/e\/7\/e758b8cd07d82609ef3335efac07b9c3"}

Remake:

{"name":"601062","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/6\/5\/655fd4b5709e9be4b7ce57b1cbead1bf.png","w":640,"h":480,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/6\/5\/655fd4b5709e9be4b7ce57b1cbead1bf"}

Kind of like eating ghosts in Pacman? I guess I'll probably let my imagination fly and see if I can get a good sprite for it.

They're supposed to be kind of short aren't they? They seem like they walk with four legs like an animal.

Yup. just like that. And, like in Pac-Man, there's only a limited time to get them while they're safe.

They need to be short enough that you can jump over them. You can create multiple animation sets, as the engine supports them.

Ok, I had some fun with this.

A random critter I drew. It's a mutated lizard, capable of walking in two legs. Random yellow stains for decoration.
601073

He turns into "safe" mode:
601072

While in safe mode, he's scared:
601071

It might be a bit overloaded though, and I tried with another lighter model:
601074

BTW, why are small images turned into links? Is there any way to override it?

Those look great.

I loved "The Castles of Dr. Creep" on C64. It was similar, but with Frankensteins to avoid and electricity, switches and keys. There was a two player mode with two joysticks, both player must work together to solve the problems. My favorite game on C64! And there was "Loderunner" too. This one later appeared on PC - with so much levels...

Thanks, I really thought the scared lizard one was pretty funny. Do they stay in the place while in "safe" mode or they run around like in Pacman?

They continue to move.

Hi LennyLen.

I've added a new video now that I've added collision detection and level respawning:

The collision detection works by first doing a bounding box collision check, and if that returns true, it then does a pixel-perfect check using the alpha channel of the images.

I reworked the level loading routines. Previously, when play started, all of the data was read directly from the level file. Now I've split this into two steps, the first of which loads from the file to a struct that holds the level for the data, and the second which builds the level from the struct. This way, when I reset the level on death, I only have to reload from memory, not from disk.

The level reset function gets passed three flags, one to say whether to reset the floor pieces, one for resetting the enemies, and one for resetting level items. In the original, these all get reset, so I'm passing true for all of these, but these options can be reconfigured to create new games.

I've also spent a bit of work improving communication between game elements.

Looks really good. I may want to play this when it's done.

I've just created some item graphics, so I can get to work on the item management now. Once this is done, all the gameplay elements for the first two levels will be complete so the first two levels will technically be playable. There's a bit of polish missing still (no death animations or sound), mostly because these are the areas that get me away from the IDE.

I have a pretty busy weekend ahead, but I should be able to find time to get the item management done at least.

edit:

I just made and uploaded a video of the same engine, but using Dario's gfx:

The enemies are a little big at this point, which actually makes it impossible to jump over them without hitting them, but it gives an idea of what's possible.

Looks cool. Is the point of the game to step on every spot in the map?

Yup. I think the idea is that you have to step on each floor tile to show that you've looked everywhere on the level for Yukon Yohan.

I've added the item-management code now, which means I just have to add the level count-down timer, and the basic level-playing routines are complete.

Here's the latest video, showing a full level clear of the first level (nothing actually happens yet when you finish the level):

UPDATE:

I've added the code for displaying the countdown timer as well as the score and number of lives remaining. Again, I've tried to make this as flexible and configurable as possible.

For the countdown, you use a bitmap called countdown_back.png and a font named countdown_fnt.png. You also specify in the .inf file whether the score is to be printed left- or right-justified or centered onto the background. The .inf file also contains the x and y position to draw the final rendering at.

For the score and lives remaining display, there is a similarly named background image and font, but also a bitmap called lives_pip.png. Again, you specify an x, y, and justification setting as well as the distance from the score to the first remaining life icon and the spacing between each icon.

In this first video, using the original graphics set, the countdown, score and lives remaining are displayed 100% faithfully to the original Atari 800 version.

In the second video, all the gameplay elements are identical to the first video, but it uses Dario's graphics set and has the UI is positioned differently. All of these changes can be made without altering a single line of code.

I've attached a Windows Binary and the source code for anyone who wants to play around with it.

Before I work on any more features, I need to do some code maintenance. A few of the source files are getting far too big and I want to move several functions to their own source files and break them into smaller pieces. I also need to standardize the way I do things across different classes. As I was adding each new game element class, I kept coming up with better ways of doing things, but didn't go back and apply them to the earlier classes, or I'd hobble them on and end up duplicating values and functionality.

Once that's done, I'm going to work on the way assets are loaded, so that the routines don't rely on the current naming patterns. After that, I can start adding more levels to the game.

Sounds to me you're going to do some OOP and inheritance.

I like the result so far. I'm not really convinced by the size of the lizard though. I'll probably have to remake it so it fits more of to the size it's supposed to be. Right now it looks barely understandable because of the Photoshop resizing. Some pixel art will fix it though.

Also, I've looked at some original artwork for Bounty Bob(ads, posters), so I guess I'll try to make the sprite again and make him come out more as a though guy. He looks kind of cute now.

The items fit in nicely after all. I wonder what the original author meant to represent with some of them.

Sadly, I can't help with sounds or music though.^[1] I don't know if the original game featured music, but will you give the option to support it? (MIDI and OGG are fine for me).

Also, I recall having some framerate problems in my computer, but not on my sister's one with the last version you sent me. I can't try out this new version right now, but is there anything that might be causing this? I recall having close to 50 FPS for some weird reason.

Lenny, you're doing an excellent job! Watched the video, and although I've never played it on the Atari, or even heard of this game before coming here, I love what I see.

Keep up the good work, you're inspiring me to keep working on mine =D

Shit, I found a nasty one Lenny. Nasty in the sense it breaks the gameplay, but surely it's easy to fix.

Remember the last problem with the stairs being two pixels taller?

Try to stand here:
{"name":"601099","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/f\/9\/f90b71813bbb67dd443979c35855ae3d.jpg","w":642,"h":483,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/f\/9\/f90b71813bbb67dd443979c35855ae3d"}
Now press up. And that's it. You're stuck and you can't move.

Ah yes, that's due to it thinking it's at the top of the ladder. I'm currently rewriting that part of the code, so hopefully that won't happen again.

UPDATE:

I've done a lot of reworking on the code to make it consistent. At the same time, I managed to streamline it down a bit, and improve some of the logic. The ladder bugs and jumping/falling through tiles bug have all been fixed as well.

The other major changes I've made don't affect the gameplay, but make it much easier for people to make their own BBE games. Now, instead of identifying objects by number, you can identify them by name. I've also removed the need for the .inf files that told the engine how many of each gameplay element type there were. The engine instead now scans the directories for media, and loads what it finds. If you specify an item in a level file that did not exist, the engine will give you a message saying what media could not be located before it exits.

The media file structure looks like this now:

media
  |
  +--- audio
  |
  +--- fonts
  |
  +--- gfx
        |
        +--- static
        |      |
        |      +--- chutes
        |      |
        |      +--- floor tiles
        |      |         |
        |      |         +--- cleared
        |      |         |
        |      |         +--- normal
        |      |
        |      +--- items
        |      |
        |      +--- ladders
        |
        +--- anim
              |
              +--- enemy
              |
              +--- player

For each of the subdirectories of the gfx/static directory, the engine will simply search for .png files, which will be loaded by the appropriate element manager. The name for this object is the filename (without the extension).

For enemies, the engine searches the gfx/anim/enemy directory for .nme files. These files contain a list of animation files which bundled together make up all the animations for an enemy sprite object. The animation files can be in the same directory as the .nme files, or in a subdirectory. For instance, the lizard.nme file that comes with the engine looks like this:

anm_files/lizleft
anm_files/lizright
anm_files/lizpassiveleft
anm_files/lizpassiveright

So it will look for the four .anm files in the anm_files subdirectory of the enemy directory. The first value in the .anm directory is the name of the subdirectory of the enemy folder to look in for the frames of the animation. The lizleft.anm file specified in the above .nme file looks like this:

lizard/lizleft 9 30 30 30 30 30 30 30 30 30

So the engine will look for the frames of the animation in gfx/anim/enemy/lizard/lizleft. The frames of all animations are now just sequentially numbered from 0. So the lizleft animation is nine images - 0.png, 1.png ... 8.png.

Binary and source attached.

edit: I'd forgotten to add death by falling. That's now been added, and I updated the attached archives.

That's cool, the naming scheme seems much better now. And cheers for the corrected bugs too.

There's one funny typo in the credits.txt file:

All I can say is I'm waiting expectantly for sound support.

Done!

All I need now is some death animation graphics and I can add those too. I can't release the current version yet as I only have the sounds from the original game. I need to go find some public domain samples I can use for a release version.

So are you saying those graphics are not from the original game?

Edit: 'sfxr' is a good tool for creating these type of sound effects.

The ones in that video are the original graphics. I also have graphics that Dario made that I distribute with the game. I have emailed the original author asking for permission to use the original assets, but haven't heard back yet.

Thanks, I'll look into it.

[UPDATE]

I've finished creating the level file for Level Two. This is the first level that features slides, which feature in a few of the later levels as well.

Here's a preview:

Snazzy.

Sounds good now. Do you need another graphic for the slide before making another release? What's the size of the original bitmap?

Yeah, that would be good. The slide bitmap is 32 x 4 pixels. The way the slide bets created is by layering these on top off each other with each new layer being offset by dx pixels. The dx value is the fourth number in each section of chute/slide data in the level file.

If you could do some more item graphics, that would be cool too. I can just re-use the ones from the first level though.

Damn, PS keeps crashing on this computer(not enough RAM), and I don't know if I'll be able to use mine for some time.

Don't hold a new release waiting for the slide graphic though. I'll send them to you whenever I have the chance to make them.

And no, I'm not going to do them in Paint.

I still haven't looked for sounds yet, which is why I haven't made a new release.

At the moment, I'm adding some cheats for easier play testing.

[UPDATE]

I took the weekend off coding, to return to a somewhat sense of normality. However, I did find some sounds to go with Dario's graphics, so I can make a new release now. I also created another level file. It's actually level four of the original game, but I have to add some more code to do level three, which has a teleporter in it.

This looks like a pretty simple level, and it probably actually is, but it took me about 20 attempts to complete it so that I could make a video. I also had to re-tweak the jump distances and the height you can fall so that the level behaved exactly the same as it did in the original. Some of the jumps are only just possible, so you have to be careful where you jump from.

So here's the video:

And here's the Windows binary and source code

Is there sound on that video? I don't hear any.

No there isn't. I probably forgot to tell CamStudio to record audio.

edit:

I've made a new video of the level, using the alternate graphics/sound set:

[UPDATE]

I coded the teleporters, and have made up the level file for the third level of the game. I'm going to put a temporary hold on development now, while I work on a level editor. As soon as I have new graphics for the teleporters and items on the third level, I'll make another release, with the first four levels.

Once I've finished with the level editor, I'll go back to adding polish to the game as well as adding the final gameplay elements.

For now, here's Level Three: The Teleporters

edit:

I got the new graphics from Dario, so here's the video:

I've attached the Binary and source for the first four levels.

Is that a super mario bros jumping sound? I can't tell.

You'll have to ask Dario ff.

The other one was horrible. I don't know if that sound is copyrighted though.

Trent Gamblin wins a cookie for 20 years old sound guessing

EDIT: Oh yeah, it's from Super Mario World actually.

I played that game enough that it' etched into my memory!

I can not recognise it as a Mario jump sound. That sound is not in my memory ... I may have played the game it's from a little, but not enough to make the sounds stick.

I've add a few flags for items in the game. These are - animated, fatal, persistent, mutant-trigger. The first one is pretty obvious, it's used to denote if an item is animated or just has a static image. If the fatal flag is set to true, then the player will die on contact with the item. The persistent flag is used to stipulate whether or not to remove the item once the player has come into contact with it, and the mutant-trigger flag denotes whether or not touching the item will make the mutants switch form dangerous to safe mode.

Edit:

I just checked to see if everything compiles ok on linux, and with the exception of a few warnings (edit: these were due to going from GCC 3.4.5 (MinGW)to 4.4.3 (ubuntu). I've update MinGW now to GCC 4.4), it compiled fine.

{"name":"linux.jpg","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/d\/5\/d569fe52cad5786d901b4d10c6544d1e.jpg","w":1680,"h":1050,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/d\/5\/d569fe52cad5786d901b4d10c6544d1e"}

Update (13-05-10):

I had a bit of spare time today, so I finished off the code for the death animations. I've decided to keep the format they use in the original game which is to have a set (left and right) of animations for falling, a set for jumping, and a set for when you come into contact with anything toxic. The reason for having different animations for falling and jumping is that in the original, when Bob falls, he keeps his hands by his sides and his legs together. However, on the downward part of a jump, he has his arms and legs extended outwards. The way they, and hence I, have animated the deaths is to have Bob collapse, vertically, two pixels at a time into the floor. Since Bob would look different at the start of the death sequence depending on whether he fell or jumped, it required two different animation sequences (Actually, I assume they don't use animation sequences, but just modify the sprite between screen redraws. Since I want people to be able to customize how their death animations look, it's best to allow the user to provide each frame of the animation).

I also finished working on the code for the moving platforms. Now that I have those, I can recreate seven of the original ten levels. I've made a short video that shows Bob jumping and falling to his death, and which also shows the moving platforms:

I've tidied up the code a lot through use of class inheritance and have also refactored a lot of the code to make simpler, though more numerous, functions. There's a couple of things I still want to do with it, and then I'll make another release (hopefully with three new levels). I also standardized the way I did things across different parts of the program, rather than updating them to the latest method when needed to, which has made it much easier to add functionality.

Recent discussion about friend classes has made me reconsider how I use one in this project (which is the first time I've ever used them), though I'm still certain I have a good reason for using it in this instance. For each type of entity-derived object in the game (except for the player), there is an equivalent entity_manager-derived class, which contains a vector of the the entity type, as well as specific methods for that type of entity collection. Because the entity types are so simple (and because the game never manipulates entities directly but instead gets the appropriate manager to do so, I made them structs.

The enemy object is a lot more complicated however, with several methods that are only ever called internally, so I made it a class rather than a struct. Because I wanted to make the enemy_manager class aware of the internals of the enemy class, but not provide any access to some of them to any other parts of the program, I made the enemy_manager class a friend of the enemy class.

Is this what would be considered an apt use of friend classes?

Update (14-05-10):

I got the new animation graphics back from Dario, so I made a similar video to the last, but with the new graphics.

http://www.youtube.com/watch?v=mNjxTz642yo

I just realised that the animations I sent you had some horrible problem with the sprites flipped in the wrong direction. Sorry, I was in a hurry and didn't see that(the PS batch didn't work too well apparently).

Anyway... are you using by any chance the "death hit" animation in the first fall? The rest looked pretty well, but the first one was weird.

It's the left jumping animation. I think it looks a little odd as the animation has him falling backwards to the right, yet he's been travelling leftwards as he hits the ground.

Calling it a "Bounty Bob Engine", and mentioning all the things you want to implement to be able to recreate the original game, makes me wonder whether you have planned some additional features? Have you got ideas for some extra stages?
If there is an emulator available, why do you even want to make this? Are you planning an editor? Why do you avoid using copyrighted images and sound, if the game itself would be much more incriminating should somebody ever wish to take legal actions (to the max)? Do you mind me asking this many questions?

Oh yes, I have loads of ideas for things that can be done with this that go beyond what could be done in the original.

Originally, because I've been meaning to do this for the last 25 years. Now it's because I want to be able to build a tool that others can use to make games with.

Yes. An editing suite, eventually.

With the exception of the name, nothing about the base engine itself infringes copyright, and that could be changed in one second. I also see it as a moral difference, if not a legal one. I didn't create their graphics, and so do not want to distribute them without any permission, whereas I did all the work on the engine myself, and so don't feel bad distributing that (it also doesn't really do what the original game does, so I don't think it would be considered a derivative work.

Not at all.