Jewel Rush - quasi-Boulder Dash clone

Everything about the modern clones and remakes.

Moderator: Admin

User avatar
rjm
Member
Posts: 16
Joined: Sun Mar 29, 2009 2:57 pm
Location: United Kingdom
Contact:

Jewel Rush - quasi-Boulder Dash clone

Post by rjm »

Hello,

Over 3 years after starting this project I've finally managed to get together enough time (and to stop rewriting the game engine every other week!) to finish an approximation of a game; which I've very imaginatively titled "Jewel Rush".

As far as an actual game goes, I'm quite pleased with the results. It needs a little more polish (and some custom graphics, at the moment I'm using Arno's set from Boulder Remake, and I don't like the sounds either (I *think* they are from GDash), I much prefer the Atari's version.

However, as a true Boulder Dash clone it's probably never going to get there. All the core principles are in place I believe, but it's the minutiae that I'm never going to reach - my main problem is scheduling as each Boulder Dash game on each platform seems to have it's own model, and I don't have enough information to try and emulate these. Even the one I did have the info on [BD1 on C64] I couldn't get quite right. So all caves currently use a hard coded scheduling system and there's no way to influence that. Another issue I'm having trouble with is the random number generator. I'm using the C64 version that I converted some time ago with the help of the folks on this site, and it works, but I did notice that Cave E on BD2 (the slime one) everything is falling to a different pattern than the one in an true Atari playthrough I saw on YouTube. So YMMV I guess. Probably something subtle I'm missing as all random levels are generated correctly.

It also doesn't scroll like the original games, but always tries to keep the player in the centre of the screen. I have the Atari "approach the edge of the screen and watch it catch up" implemented but it felt wrong so it's currently disabled. I'll go back to this once I implement smoother scrolling instead of jumping one block at a time.

A couple of ingame screenshots:

Image

Image

As the game has been coded in C#, it requires the Microsoft .NET runtime 4.0 to play. But, as it's using OpenGL and OpenAL, that means that in theory I can use Mono to port it to other platforms such as Linux, Mac and even Android. This is something I'll look into once I actually have a non-BD game built on top of this engine!

One note on sound - you need to install OpenAL. If it's not installed, the game will simply inform you that no audio devices are available and disable sound in the games options. Should still be fully playable though.

I've tested this on Windows 7 Pro, Windows 7 Home, and also on a Windows XP Pro VM and it seems to work quite nicely on all these.

The current build of the game can be downloaded here. Just extract the zip and run jwldash.exe, no need to install and it won't modify your system.
http://binaryrealms.co.uk/downloads/info/jwlrush.zip (2MB)

Sorry for the 5MB download size, currently this is mostly taken up by the WAV audio files. I was more concerned with the engine more than the audio component, I'll be looking at using an OGG encoder for future builds.

The game currently only handles .BD files, but it doesn't support every single available option (for example one of the Firefox levels I was testing had dummies in it - whatever these are, they aren't supported). At this stage, only elements from BD1 and BD2 are supported. Such elements will be simply ignored and the cave will play as best it can. (Anything like this is logged into a log file in the executable's directory)

At this point, I'm not sure how much further I'll be taking the Boulder Dash aspects. I enjoy the game, and I'm really pleased with how the engine's progressing. But I'm pretty annoyed at the fact that I can't get it closer to a true Boulder Dash clone, therefore it's more likely that while I'll retain all the BDCFF support, I'll start taking it in a different direction and coming up with my own elements to make it a more stand alone game.

The only bug I'm currently aware of is if it's run on a read only device, it will crash on exit when it tries to update the config file. But, it hasn't been widely tested and so no doubt more bugs exist.

Well, I think that covers just about everything I wanted cover, if you got this far... well done!

On a final note, I'd like to thank Arno for having this site in the first place and the help years ago with the initial random number generator issues I was having, without that this project never would have progressed past where I had it! And this is quite a nice milestone for me, it's the first game I've actually wrote since leaving DOS behind in 1994 and probably the best one I've done besides.

Image
Last edited by rjm on Sun Sep 23, 2012 3:41 pm, edited 4 times in total.
User avatar
Piter
Member
Posts: 41
Joined: Mon May 26, 2008 8:53 pm
Location: Poland

Post by Piter »

Hi!

I wanted to test your game, but I cannot start it. I get following error:
<?xml version="1.0" encoding="utf-16" standalone="yes"?>
<cyotek.exceptionreport>
<message>Input string was not in a correct format.</message>
<timestamp>5246379514062495325</timestamp>
<data><![CDATA[System.FormatException: Input string was not in a correct format.
at System.Number.ParseSingle(String value, NumberStyles options, NumberFormatInfo numfmt)
at System.Convert.ToSingle(String value)
at d.zg(XmlNode a, String a, Double a)
at BinaryRealms.Engine.AnimationSequence.Read(String fileName, XmlNode reader, IAsset parent)
at BinaryRealms.Engine.AnimationSequence.c(String a, XmlNode a, IAsset a)
at BinaryRealms.Engine.AnimationSequenceCollection.Read(String fileName, XmlNode reader, IAsset parent)
at BinaryRealms.Engine.AnimationSequenceCollection.c(String a, XmlNode a, IAsset a)
at BinaryRealms.JewelRush.JewelRushGame.LoadConfiguration(String fileName)
at g.OnPreLoad()
at BinaryRealms.Engine.Scenes.LoadingScene.Update(Double elapsedTime)
at BinaryRealms.Engine.SceneManager.Update(Double elapsedTime)
at BinaryRealms.Engine.Game.Update()
at BinaryRealms.Engine.OpenGL.OpenGLGameRunner.OnUpdateFrame(FrameEventArgs e)
at OpenTK.GameWindow.RaiseUpdateFrame(Stopwatch update_watch, Double& next_update, FrameEventArgs update_args)
at OpenTK.GameWindow.Run(Double updates_per_second, Double frames_per_second)
at h.Main()]]></data>
<stack><![CDATA[ at System.Number.ParseSingle(String value, NumberStyles options, NumberFormatInfo numfmt)
at System.Convert.ToSingle(String value)
at d.zg(XmlNode a, String a, Double a)
at BinaryRealms.Engine.AnimationSequence.Read(String fileName, XmlNode reader, IAsset parent)
at BinaryRealms.Engine.AnimationSequence.c(String a, XmlNode a, IAsset a)
at BinaryRealms.Engine.AnimationSequenceCollection.Read(String fileName, XmlNode reader, IAsset parent)
at BinaryRealms.Engine.AnimationSequenceCollection.c(String a, XmlNode a, IAsset a)
at BinaryRealms.JewelRush.JewelRushGame.LoadConfiguration(String fileName)
at g.OnPreLoad()
at BinaryRealms.Engine.Scenes.LoadingScene.Update(Double elapsedTime)
at BinaryRealms.Engine.SceneManager.Update(Double elapsedTime)
at BinaryRealms.Engine.Game.Update()
at BinaryRealms.Engine.OpenGL.OpenGLGameRunner.OnUpdateFrame(FrameEventArgs e)
at OpenTK.GameWindow.RaiseUpdateFrame(Stopwatch update_watch, Double& next_update, FrameEventArgs update_args)
at OpenTK.GameWindow.Run(Double updates_per_second, Double frames_per_second)
at h.Main()]]></stack>
<product name="Jewel Rush" version="0.0.0.0" />
<assemblies>
<assembly>mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</assembly>
<assembly>jwlrush, Version=0.0.0.0, Culture=neutral, PublicKeyToken=9d164292f52c48c9</assembly>
<assembly>BinaryRealms.Engine.OpenGL, Version=1.0.0.0, Culture=neutral, PublicKeyToken=9d164292f52c48c9</assembly>
<assembly>OpenTK, Version=1.1.0.0, Culture=neutral, PublicKeyToken=bad199fe84eb3df4</assembly>
<assembly>BinaryRealms.Engine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=9d164292f52c48c9</assembly>
<assembly>System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</assembly>
<assembly>System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a</assembly>
<assembly>Cyotek.ExceptionHandler, Version=1.0.1.2, Culture=neutral, PublicKeyToken=9d164292f52c48c9</assembly>
<assembly>System.Xml, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</assembly>
<assembly>System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</assembly>
<assembly>BinaryRealms.JewelRush, Version=1.0.0.0, Culture=neutral, PublicKeyToken=9d164292f52c48c9</assembly>
<assembly>BinaryRealms.Engine.OpenAL, Version=1.0.0.0, Culture=neutral, PublicKeyToken=9d164292f52c48c9</assembly>
<assembly>System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</assembly>
<assembly>System.Configuration, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a</assembly>
</assemblies>
<system>
<operatingSystem platform="Win32NT" version="6.1.7601.65536" servicePack="Service Pack 1" />
</system>
</cyotek.exceptionreport>
Do you have any idea what might be wrong? I am running Win7 Ultimate...

Best, Peter
User avatar
rjm
Member
Posts: 16
Joined: Sun Mar 29, 2009 2:57 pm
Location: United Kingdom
Contact:

Post by rjm »

Hello,

Thanks for the bug report. It seems to be an internationalization issue, I didn't think to test this on non-English locales. I changed my XP VM to Polish and confirmed the crash.

I'll get this fixed and a new build uploaded today, but until then there's a simple workaround. If you open up game.xml in a text editor of your choice you see a bunch of nodes named animationSequence, each with a speed attribute. This is what is causing your crash as I've defined the floating point speeds as 0.06, 0.20 etc whereas your locale is expecting 0,06 and 0,20. If you do a search and replace to replace all instances of "0." to "0," (without quotes!) then this should allow the game to start and play normally.

There does seem to be a side effect in text screens where text isn't drawing properly but this doesn't affect the game itself. I'll look into that today as well.

Again, thanks for the bug report.

Regards;
Richard Moss

Edit: New build posted which should fix the conversion issues. There's still a missing color on text screens but that doesn't crash the program so I'll look at that one later on today.
User avatar
Piter
Member
Posts: 41
Joined: Mon May 26, 2008 8:53 pm
Location: Poland

Post by Piter »

Hello!

I've downloaded the updated version and I confirm that now it works. I've played it for several minutes and it seems to work Ok. I like it. I'll test it more later and maybe give you more feedback.

One question for the time being - do you have any plans to randomizing cave colors? I believe you're using indexed 8-bit color mode (correct me if I'm wrong), so it should be quite easy to do it then. I think that it'd be nice feature.

Best, Peter

P.S. You may also want to test my BD-alike clone, which topic can be found here => http://www.boulderdash.nl/forum/viewtopic.php?t=369
User avatar
rjm
Member
Posts: 16
Joined: Sun Mar 29, 2009 2:57 pm
Location: United Kingdom
Contact:

Post by rjm »

I had thought about it on several occasions actually, because they all look a bit bland with the same tile repeated all the time on each level. But it'll end up as one of those "rainy day" options probably. At the moment my engine only supports recolouring as a single value, not the multiple colours that BD uses. I also thought about reimplementing something similar to Boulder Remake where it used different graphics for the same tiles which is quite effective and which was present in my original GDI implementation but that got dropped during one of the numerous engine rewrites into DirectX then OpenGL.

Aside from Boulder Remake, I've avoided looking at other clones as I didn't want to get sidetracked by spotting something another game was doing and then trying to implement that. I'll probably start paying more attention to them now that the bulk of my own game is done ;) I'll let you know any of my own comments on yours when I take a peek at it!

PS: The indexed colours will just be from optimizing the graphics to be as small as possible, it wasn't a deliberate choice :wink:
User avatar
rjm
Member
Posts: 16
Joined: Sun Mar 29, 2009 2:57 pm
Location: United Kingdom
Contact:

Post by rjm »

Posted a new (delayed!) update which adds support for gamepads/joysticks. Probably going to pause development on the game itself to tinker with the engine... the lack of smooth scrolling is becoming quite an annoyance (which is also something I noticed with your game Peter) and probably look at colour cycling.
subotai
Member
Posts: 251
Joined: Sun Jan 25, 2009 4:19 pm

Post by subotai »

I can't test your game, because I don't want to install the NET framework.
rjm wrote:I'm having trouble with is the random number generator. I'm using the C64 version that I converted some time ago with the help of the folks on this site, and it works, but I did notice that Cave E on BD2 (the slime one) everything is falling to a different pattern than the one in an true Atari playthrough I saw on YouTube.
You must not reset the initial seed values after placing the random elements. There exists a thread about implementing the slime permeability and adjusting the PLCK-values in this forum.
rjm wrote:But I'm pretty annoyed at the fact that I can't get it closer to a true Boulder Dash clone, therefore it's more likely that while I'll retain all the BDCFF support.
There is one big problem with BDCFF. There doesn't exist a flawless C64 to BDCFF converter. In my opinion it is better to directly support C64 memory dumps (I don't know how this works with Atari). As long as the games are not hacked, you have a very good chance to get a good compatiblity for these games. And it is much easier than writing a BDCFF parser.

Good luck with your game.
User avatar
rjm
Member
Posts: 16
Joined: Sun Mar 29, 2009 2:57 pm
Location: United Kingdom
Contact:

Post by rjm »

Thanks for the feedback!

Lack of .NET can't be helped, but as version 3.5 is generally preinstalled on all modern Windows O/S then I should probably compile against that instead of 4 as I'm not actually using any functionality of 4. But there will always be that dependency, C# is my language of choice and so I'll stick with it ;)

In regards to the seeding, I did find that seed was reset after the cave was filled. Resolved that so the random seed is never set except when first initialized. Falling pattern still doesn't match, I'll hunt around here for the slime permeability topic you referred to, hopefully it's just a silly mistake in the calculations which is easily fixed.

Your comment re reading the C64 dumps makes sense, but at the end of the day it doesn't really matter how I load my caves, be it raw memory or BDCFF files - if the underlying engine isn't running at the correct speeds expected by those caves (not so much level 1 I guess, but any harder difficulty levels) then the game will be either too easy or too hard/impossible. I do have some information on the format so it's likely I'll look into this sooner or later, but more probably much later.

Thanks again for your comments!

Regards;
Richard Moss
subotai
Member
Posts: 251
Joined: Sun Jan 25, 2009 4:19 pm

Post by subotai »

You are welcome!

If the placement of the random elements works good then you're code should be correct. Here are the correct seed values:

Initial seed values for caves with no random elements (PLCK-games for example):
seed1 = $1E; seed2 = $00;

Seed values after placing the random elements in Bd2 cave E:
seed1 = $E5; seed2 = $21
rjm wrote:Your comment re reading the C64 dumps makes sense, but at the end of the day it doesn't really matter how I load my caves, be it raw memory or BDCFF files
Well, then you should take care when testing your engine with these BDCFF-files. I never saw a PLCK game in BDCFF with the correct slime pemeability for example. And in some converters, the starting directions of the elements are not always set correctly! If there are "bugs" in the BDCFF-files, you can get the intention that your engine doesn't work accurate. I made the same mistake when using the Boulder Remake levelsets as a reference. The best reference is the C64 or Atari memory dump!
rjm wrote:if the underlying engine isn't running at the correct speeds expected by those caves (not so much level 1 I guess, but any harder difficulty levels) then the game will be either too easy or too hard/impossible.
The game speed depends on the number of animated elements in a cave and on the game engine. In my remake, I just adjust the timer speed, the game speed remains always the same (and this works pretty good).

There is also a thread on how to handle the different game speeds.
User avatar
rjm
Member
Posts: 16
Joined: Sun Mar 29, 2009 2:57 pm
Location: United Kingdom
Contact:

Post by rjm »

Subotai,

Wow... what can I say. Now my implementation of BD2 Cave E mirrors the falling of C64/Atari video's on you tube. The seed values you provided in conjunction with the "slime permeability and BDCFF" topic gave the answer of where I was going wrong.

In the first case, where a default seed was not specified I wasn't using 30 instead. And in the second case, my random level fill was processing the full height of the map whereas according to a couple of comments in the other topic I need to skip top and bottom rows. As soon as I did that, the seeds in the generator after rendering the level matched the ones you gave above, and everything is falling correctly.

Thanks for the pointers and especially for those raw numbers, they made it spot on easy to test... I'm pretty pleased that this problem is solved :)

I'll do some more digging for the speed thread you refer to, would be pretty nice to lay that one to rest too.

Regards;
Richard Moss
User avatar
rjm
Member
Posts: 16
Joined: Sun Mar 29, 2009 2:57 pm
Location: United Kingdom
Contact:

Post by rjm »

Updated the build with the fixes for the predictive randomization as discussed above and somewhat better timings for the different game scheduling options. I also added mouse support for menus and support for per tile animations independent of tile type allowing the diamond birth sequence to be used. Finally, I fixed a number of bugs I found.

Also changed the audio system to support OGG decoding instead of WAV, this reduces the download size by 3MB.

Although I didn't include them in this build, I've started working on my own custom graphics. I tested this new graphic with palette switching to allow the caves to be recoloured according to their colour values, this is working nicely and should hopefully be in the next build. I also started putting the groundwork in for smooth scrolling and transitions which is going to be a pain probably.

Still compiled against .NET 4 though forgot about looking at that until after I'd uploaded it.
User avatar
rjm
Member
Posts: 16
Joined: Sun Mar 29, 2009 2:57 pm
Location: United Kingdom
Contact:

Post by rjm »

Posted an update to Jewel Rush today. No game play changes as such, I added a couple of BDCFF types I came across in a test level, and added support for generating mazes. Smooth scrolling is implemented but is too unstable to enable by default, sometimes it's perfect and sometimes it goes nuts and jumps around briefly.

Most of my time this update was spent drawing (and redrawing and redrawing!) graphics as I'm not really happy distributing someone else's work as is. I'm still using Arno's player character sprites for the moment but I've redone all other active graphics. I'm mostly happy with them but they still need more work, and I need to decide on a final style. Apart from the base dirt, boulder and wall graphics, none of the rest really lend themselves to colour changing, so I need to rethink that too.

I really wish I had the Atari sounds rather than the C64 ones. I don't think I have the patience to try and record them in an emulator though so I might try and replace the entire set completely.

I may have broken the game from running on Windows XP, on the VM I tested on, some of the alpha blended graphics weren't working. Not sure if that is the VM or if my code is at fault (it's more likely the latter!). Runs fine on Windows 7 which is the only physical machine I have left.

A couple of screenshots of the new graphics:

Image

Image
User avatar
Piter
Member
Posts: 41
Joined: Mon May 26, 2008 8:53 pm
Location: Poland

Post by Piter »

rjm wrote:I really wish I had the Atari sounds rather than the C64 ones. I don't think I have the patience to try and record them in an emulator though so I might try and replace the entire set completely.
Hi! Please PM me your e-mail. I've got most of Atari sounds prepared for my project - I'll gladly share them with you. Maybe it'll help.
User avatar
paul_nicholls
Member
Posts: 108
Joined: Sun Dec 12, 2010 6:16 am
Location: Tasmania, Australia

Post by paul_nicholls »

@rjm: looks great mate :)
I will try it out maybe tonight on my Vista machine at home...

cheers,
Paul
User avatar
rjm
Member
Posts: 16
Joined: Sun Mar 29, 2009 2:57 pm
Location: United Kingdom
Contact:

Post by rjm »

Posted a new build... as usual currently it doesn't really include any changes to the game, but rather the engine. This time it fixes problems with textures not loading correctly on certain OpenGL implementations (my XP VM for example!)

Thanks to Piotr, I've also replaced most sounds in the game with the Atari versions he sent me. They are rather quiet though, I've had to reduce the volume of the remaining (C64?) sounds to compensate, but there's probably still more tinkering I could do there.

At the moment I'm working on a new game so it's unlikely I'll be making any major changes to Jewel Rush for the time being (except to make sure it still works as I change the engine!), although I still need to finish off the new graphics so I should probably do that sooner rather than later.
Post Reply