Jump to content

HTML5 Rock Raiders Remake


risingstar64
 Share

Recommended Posts

Hey guys,

 

I've been a member of this forum and a fan of rock raiders for some time, but I don't recall posting anything up until now. Anyway, I'm in the process of remaking rock raiders in html5 as a way to examine the limitations of and expand upon an html5/javascript port of a game engine I wrote last year building off of pygame. I know that 98% of fan projects and remakes die off shortly after being started so I do not want to get anyone's hopes up to be disappointed. However, I do have quite a bit of game development experience (including some minor programming additions to http://scpcbgame.com/ a game of which I am a big supporter) and I intend to work on this project at my own pace, and see it through to completion, since the amount of content in the original rock raiders game is not that ambitious. 

 

Since the game is being made for html5 and all of the source code is in javascript, everything is completely open source. As this is a solo project I'm not using any sort of source control that you could pull and make branches of (sorry about that!) but whenever I make a significant change and find that it hasn't broken any game elements I update the files on my site with the most recent file versions, so you should be able to find the most recent version of the game at any time at [link outdated: see below to play] (although this is my own personal site it was made hastily using a bootstrap theme to demonstrate basic html and javascript knowledge for an internship application some time ago and showcases old projects of mine, so please ignore everything aside from the rock raiders page I linked to). For now, the remake is going to be in a 2d overhead view as this requires the least amount of messing with art assets. Later down the line, however, I would be happy to modify things to use 3d models instead (probably using webgl or some three.js trickery or something). 

 

In closing, the main purpose of this thread is to share this project with those who are interested in keeping up with its development. Of course, things are still quite basic as I only recently started this project, and many of the things that need to be changed I am already aware of and just have not gotten to yet, but please feel free to let me know your thoughts, suggestions, or anything else! If you have any questions regarding the way anything is being implemented (raider ai, pathfinding, level data storage, etc..) those are also welcome, and you can explore the code for yourself as well if you'd prefer by selecting a file from the index [link outdated: see below for source]. I love this game and its modding community and hope to get to know all of you over the course of this project's development :)

 

------------------------------------------------------------------------------------------------------------------------------------------------------------------

 

To keep things organized, the most recent version of the game is now located at http://rystills.github.io/rock-raiders-remake/
The source code is available at https://github.com/rystills/rock-raiders-remake

Link to comment
Share on other sites

I really like the SCP games, they are so well put together! I hope you can manage to keep working on this project, I will check it out from time to time! 

Link to comment
Share on other sites

It's hard for me to give regular updates right now because most of what I'm doing is boring engine related work. The last few things involved:

-fixing up the movement code so that if only part of a raider's movespeed is used to get to a destination in one frame, the raider will use the rest of that speed to start towards his next destination, rather than having 1 frame where he moves less than his maximum movement amount

-adding in sprites from the original game

-adding in rubble, and with it, restructuring the way the tile class handles rubble, buildings, powerpaths, etc.. to remove unnecessary object creation

-adding support for image rotation to the engine in an efficient manner

-adding task completion speeds so that raiders complete different tasks (such as picking up an object or drilling a wall) at different speeds depending on the tasktype

 

and the next few things will involve:

-adding support for collision rectangle rotation to the engine to match image rotation

-adding noncentered rotation so that an object in the hands of a raider stays in the hands of the raider regardless of in what direction he is facing

-restructuring the rock raider update method to use several submethods for large chunks of code to avoid repeat code and improve readability and scalability

 

once those things are done I plan to move on to implementing more core gameplay features including:

-power paths

-more building types

-rubble being sweepable

-rubble revealing ore when swept depending on the rubble type

-rubble appearing when a wall has been drilled

 

after enough core features have been fleshed out I will start building test levels and disable the raider AI's ability to choose tasks without being directed

eventually I will move onto things like the level editor and save files, but I don't want to start working on these types of things until most of the engine is finished

 

EDIT: after working through a few collision detection bugs / inaccuracies I am now beginning work on user interactivity with the game objects

 

EDIT: Implemented a standard point in polygon collision method for detecting collisions with mouse clicks and moved the generation of rect bounding points into its own method to keep things clean. With mouse interactivity now being possible I have tweaked the raider ai a bit so that tasks are only allowed to be added to the active task list automatically if the task is one that raiders are allowed to do without the user's permission (ex. sweep some rubble). Tasks that require user permission to be performed (ex. drill some loose rock) need to be moved to the active task list by the user via clicking the wall to be drilled. The next step is to add an additional attribute to task objects that manages task priority. This is because raiders currently choose a new active task based on how far away from them the task is, and because of this, tasks that the user adds manually may be ignored unless they are given some sort of special priority. Eventually I will get to implementing the side GUI so that the player can actually choose an option to perform on a selected object (such as whether to drill, reinforce, or cancel drilling on a selected wall). 

 

- I can never seem to find the time to upload the most recent version of the project to my site because more often then not I leave things broken due to changes / partially implemented features, but things are moving along nicely. I will try to keep the version on the site more current soon

 

EDIT: I haven't given an update in awhile so I thought I'd mention a few things that have changed. I have now implemented 'building site' as a space type which comes with a variable dictating the required amounts of each resource in the form of essentially a hashtable (the same variable type used to indicate resources that the player has collected). In introducing building sites I had to make some substantial additions to the raider ai so that they can go to the nearest toolstore and grab a resource that is required by the building site, take a resource that they pick up off of the ground and take it to the site, etc.. Overall the game is still progressing, so feel free to check out the latest version on my site!

Edited by risingstar64
Link to comment
Share on other sites

  • 6 months later...
risingstar64

I haven't given an update in awhile, so I decided to do so in a fresh post rather than an additional edit. I've taken a break from this project for the past few months to work on a few different projects of mine, but recently I returned to make some additional progress. I finally got around to fixing the few bugs that I have observed in the raider AI, and am confident that the code is now more robust, albeit still more than a little messy. I also split large classes into their own JS files, since the game code was becoming difficult to navigate. The latest version of the game has been updated on my site, and the last remnants of lazy file pathing have been fixed in the asset loader and html file, which means running the game locally should now be as easy as downloading the "rygame" directory and then double clicking the html file inside the "rock raiders" folder (for now to maintain parity with the site file structure the rygame folder needs to be the root folder when running the game locally, but I'll probably look into a more elegant solution later in development).

 

I am currently starting to recreate the original rock raiders levels in my game's level file structure. Could anyone point me in the right direction to find the level data in the original game's files? I have already unpacked the rock raiders WAD file in order to copy textures from the game, however I have not yet had a chance to look into where or how level data is stored.

Link to comment
Share on other sites

sheepandshepherd

The levels are stored in LegoRR0.wad, each with its own folder in \Levels\GameLevels\. They're made up of multiple binary map files, 1 for each aspect of the map (Surf_##.map for the terrain, High_##.map for floor height, etc)... the formats were fully decoded and documented on the wiki, I think, but it's gone. Maybe someone has a backup of those pages?

  • Like 1
Link to comment
Share on other sites

 the formats were fully decoded and documented on the wiki, I think, but it's gone. Maybe someone has a backup of those pages?

The wiki still exists, it's just... hidden. It can be found here.

  • Like 3
Link to comment
Share on other sites

sheepandshepherd

 the formats were fully decoded and documented on the wiki, I think, but it's gone. Maybe someone has a backup of those pages?

The wiki still exists, it's just... hidden. It can be found here.

Thanks :) In that case, here is the page describing the map files.

  • Like 1
Link to comment
Share on other sites

risingstar64

Thank you! The .MAP info page is just what I was looking for. It looks like converting the levels to my own format will just be a matter of pairing up each meaningful hex value to a corresponding value in my engine. I'll start working on a converter some time soon, starting with the terrain map.

 

EDIT: Small update. added a few quick methods to the engine to simplify text drawing a bit, and added some additional debug info to the game showing the internal name of whatever task a raider is currently performing over its head, and labeling the row+column of each Space in small red text. This stuff should come in handy as I improve the raider AI a bit and work on getting the basic level converter working.

bZSNTW4.png

 

EDIT: Another small update, but a meaningful one since it addresses something that I've been meaning to get to for some time; 'reserving' resources from the toolstore. My explanation is pretty long and specific, so read at your own risk.

Previously there was a flaw with the raider AI; when choosing a task, if a raider chose the "build" task, which involves taking a resource from a toolstore and bringing it to a building site, that raider would first check if there was at least one resource of the chosen type currently available in the toolstore. If there was at least one resource, great! The raider stuck with the build task and went on his way to reach the toolstore. Once he arrived, he would check again if there was a resource available of the chosen type. Chances were, there would be, and he would decrease that resource number by one, generate a resource of that type, and start on his way to the building site. But there was the possibility that another raider had already gone to the toolstore and taken the last resource of the chosen type from the toolstore, and so when our original raider arrived he would find that there were no resources of the chosen type available anymore, and he would simply drop the task and choose another one from the available queue (He may happen to choose the "build" task again, but this time the initial resource check would fail for the chosen type, and if no other type passed the check, that build task would be moved to the unavailable queue until another resource was added back to the toolstore). This wasn't really a problem, and the raider AI had a few bugs when I was still finishing the AI code for the build task type, so I just left it the way it was. But now that all of the AI bugs have been fixed and I still had this on my todo list, I decided to go back and implement a "reserved resource" dictionary which works side by side with the collectedResources dictionary to avoid problems like this. If a raider chooses a task which requires it to take a resource from the toolstore, the raider now reserves a single resource of the chosen type as soon as it chooses the task, and that tells any other raiders that go to take a resource of the same type from the toolstore that there is effectively 1 less of that resource type. The result is that another raider can no longer "steal" the last resource of a type that another raider is already en route to pick up. I already had such a system in place for resources put down at building sites, so that raiders would not try to bring resources to a building site, only to find that the site had enough of that resource type already, but that happened to be a bit easier to implement since it didn't require me to go back and edit any already existing logic. This change is not necessarily a direct improvement to raider efficiency; there are times when a raider being able to steal a reserved resource from another raider may actually cause the raiders to be more productive in the long run. However, I would argue that in most cases this is an improvement, and is also more similar to how raiders in the original game functioned. Another interesting thing to note; just because a raider has reserved a resource at the toolstore, doesn't mean that raider will end up making use of the resource. If a raider reaches the toolstore, and finds that where he is trying to bring that resource (say a building site) no longer requires that resource, he will drop the reservation and choose a new task. This is because the raider reserves the resource as soon as it chooses a task, but does not reserve a spot where it is bringing the resource until it begins to pick up that resource. I am still considering whether or not this aspect of the raider AI is justifiable, but I would argue for it since it avoids situations where a site is left incomplete because a raider across the map has reserved a spot, but needs to walk all the way to the toolstore to pickup a resource, and then all the way to the building site to drop that resource off. To be fair, similar situations CAN occur if a raider across the map picks up a resource either from the ground or from a far away toolstore, and reserves a spot at a building site for that resource, but the alternative logic (the raider walks all the way to the building site only to find that another raider beat him to it, so then he has to walk all the way back to the nearest toolstore which is very far away) has the potential to be just as inefficient, meaning to my knowledge there is no easy way to guarantee that such situations do not end up happening unless raiders check what each other are doing and how close each other are to their objectives at each step of the way, which would be pretty taxing for the game's performance.

Anyway, with that finally out of the way, progress can continue to be made :)

Edited by risingstar64
Link to comment
Share on other sites

  • 4 weeks later...

Hey, nice to see this isn't abandoned! :)
Something game-engine wise that's a major point really with the map, 

1x1 blocks of stone can't exist, it crumbles away, for example the following can't exist in the game:

(# = dirt, 0 = wall, + = wall that will break if put into such a position)

0##

0+#

0##

----

####

#+##

#++#   say if you had a 2x2 block and one is removed creating an L shape

####

-----

###

#+#

###

----

example, This CAN exist:

####

#00#

#00#

####

 

Just a heads-up :)

Also, does your version there have support for building and such? How do we do it? I noticed there's 2 test levels in the files, can we load the other? 

Link to comment
Share on other sites

Hey, nice to see this isn't abandoned! :)
Something game-engine wise that's a major point really with the map, 

1x1 blocks of stone can't exist, it crumbles away, for example the following can't exist in the game:

Hidden Content

example, This CAN exist:

Hidden Content

 

Just a heads-up :)

Also, does your version there have support for building and such? How do we do it? I noticed there's 2 test levels in the files, can we load the other? 

Hey, thanks for the feedback!

Walls crumbling when there are not enough surrounding walls is something I had not yet gotten to as of the last update. I have since implemented this, so you'll see it in the next update, which should be released very soon :) I appreciate the diagrams though, they really helped me to recall the functionality of walls in the original game. 

As for buildings, the game does support buildings, however there is not currently much of a UI. this is the biggest point that I am focusing on right now, as in the next update I would like any implemented functionality to be able to be used by the player in a way that is familiar to the original game, as opposed to the current, very basic system of left clicking tasks to set them to high-priority (aka. to be performed by the next free raider). 

Finally, with regards to levels, the other test level is not particularly interesting, but the level file converter that I am writing will be included with the rest of the project in future uploads, so you can convert or modify your own level files at any time, although of course not all level functionality will work properly as the project is still in development.

 

On a separate note, I recently have run into a question that I would like to pose to the forum, as it has left me a bit stumped. in the first level, the very starting area before any drilling looks like this

3DOvKzJ.png

 However, I cannot seem to figure out why the dirt wall in the left-center part of the screen exists. According to the terrain map for level 1 (Surf_01.map) The map should actually look like this

axmgM4i.png

As you can see, according to the map file, the relevant section of wall should be:

4 3 1

5 5 3

but in the game it appears to be:

4 3 1

4 5 3

where 4 is dirt, 3 is loose rock, 1 is solid rock, and 5 is ground

If anyone has any idea where this dirt wall may be coming from, please let me know, as whatever the reason may be it should be added to my remake in order to maintain consistency :)

Edited by risingstar64
Link to comment
Share on other sites

You need to go ahead and put this thing on GitHub so I can help you out. :P (Bonus: we can host the game on GitHub too since it's all static content. We could set it up where the GitHub Pages site is the dev, could-possibly-be-broken-but-always-up-to-date site, while your site is the more stable version.)

  • Like 1
Link to comment
Share on other sites

With a little help from Le I moved this project onto GitHub. The most recent version of the project can now be found at any time at https://github.com/rystills/rock-raiders-remake Note that as Le pointed out this is essentially a dev version of the project, which means it may be unstable / non-functional at times.

As per Le's recommendation, I will also be configuring the project to work with GitHub Pages in the near future for those who don't wish to download the entire project and run it locally just to run the most recent version every time there is a change, so keep an eye out for that.

Additionally, due to minor project structure changes the URL to find the stable version of the project on my personal site will almost certainly be a bit different with the next update as well, but I'll be sure to adjust any links accordingly to avoid any confusion. 

Finally, my previous question still stands, should anybody happen to know the cause ;)

Edited by risingstar64
Link to comment
Share on other sites

You also have to look at the dugg map. It contains information whether the tile is a wall or not. If it says the tile is a wall, but the surf-file says it's ground then the actual tile is a dirt wall. I think it also works the other way round, meaning the dugg file can also erase walls.

Oh, and just played your game. It starts to look prety good, but could you please make it fullscreen instead of this tiny window?

Edited by Yellowkey
  • Like 1
Link to comment
Share on other sites

sheepandshepherd

Yeah, as mentioned, the dugg map tells you what's ground. To clarify: the dugg map has higher "priority" than the surf map. And the wiki page for the surf map is slightly confusing, I think, because the numbers it uses for "ground" are irrelevant. (Or maybe we should just say LRR's map formats are confusing :P). It works something like this (in ugly pseudocode):

if dugg==3 or dugg==4:
    slimy slug hole
else if dugg==1 or dugg==2:
    if surf==6:
        lava
    else if surf==9:
        water
    else:
        ground
else if dugg==0:
    (whatever the surf map says)

 

And a surf map value of 5 still means dirt if the dugg map is 0 (wall). 4 and 5 are both dirt in that case, not ground. Anything turns into ground if the dugg map is 1-4.

  • Like 1
Link to comment
Share on other sites

Thank you, Yellowkey and SheepAndShepherd. My engine already reads in the dugg map, but you are both correct in that I didn't realize its priority over surf.map, so I just have to rearrange the code a little bit. Also, your pseudocode is perfect; easy to read and removes any ambiguity I might have had :) Everyone here has been a tremendous help in the development of this project so far.

With regards to the screen size, i was put in a tricky situation when developing the game since I'm making the game in a 2d overhead perspective. If you press F, you should get a black border surrounding the canvas, removing any other elements on the page, and (depending on your browser) you will also be zoomed in, or can zoom in manually using Ctrl +. This of course isn't true upscaling, but it works well enough. Eventually, depending on how things progress, I have some intention of redoing the graphics in proper 3d with the original models + highpoly mods (which also means actual upscaling will be possible) but that won't be until after the game is a bit more fleshed out.

Finally, please don't read into the current release on my site too much. It was uploaded somewhat hastily, and a lot of the missing gameplay elements and bugs in that version have already been addressed in the most recent dev version. I'm very excited about the next stable release, which should hopefully be ready in just a few more days :D

Edited by risingstar64
Link to comment
Share on other sites

Hurray! I was useful :) Glad I could be, however little, I'm also glad to see this developing further! 

I'll have a look at this on mobile,see how that goes. Back in few. 

UPDATE:

"Press enter to begin"

Well. Never mind. 

Edited by ch4rl1e97
Link to comment
Share on other sites

I don't own a mobile device on which to test out the project, so I haven't implemented support for them yet, but i imagine the game should work on any device that supports javascript and canvas, it just may require button remappings, essentially replacing left click and right click with single touch and 2 finger touch inputs or something. I'm sure it wouldn't be too difficult to add in later though, or as a mod since its open source :)

Edited by risingstar64
Link to comment
Share on other sites

  • 4 weeks later...
risingstar64

I'm very excited about the next stable release, which should hopefully be ready in just a few more days :D

Looks like I was a bit too optimistic, but I've finally decided to release the next stable build. Once again thanks to Le's advice, I've setup a github-pages branch for the project repository so that I can more easily keep the web build up to date. Going forward, the most recent stable version of the game can be found at http://rystills.github.io/rock-raiders-remake/. The game has been cleaned up a lot since the last release, and should feel a bit more like the original. While there is still a lot to do (especially with regards to the UI) things are moving along very nicely. For a full list of changes, check out the github commit history. 

Current controls (I know these are different from the original for the time being, but please bear with me here):

-F to enter fullscreen mode (currently this does not scale the canvas size, but will hide everything except for the canvas)

-arrow keys to control camera 

-left click to select a single raider or other object

-hold ctrl and drag mouse to drag a selection box which can select multiple raiders at once

-right click to tell all selected raiders to execute a task

-left click to use any and all UI buttons

Finally, note that at the moment raiders lack random movement offsets, and therefore love to walk inside of each other, making it impossible to tell how many raiders are in the same spot at times. To determine how many raiders are on top of each other, simply select them all with control and the selection text at the bottom of the screen will tell you how many raiders are selected. To select just one of a group of raiders that are on top of each other, just left-click.

With regards to the buttons, most function the same as in the original game. However, raiders do not automatically stop their current task when selected, although they will not automatically start a new task unless you assign it to them via a rightclick or deselect them first. To stop a task that a selected raider is performing, press the button that looks like a red and white crossed circle.

 

EDIT: Almost forgot, I haven't implemented a visual indicator for each raider's held tools yet, but as in the original first level the raiders do not start out with shovels, only drills. If you want to sweep some rubble, you must first send the desired raider to the toolstore to pickup a shovel by selecting one or more raiders and pressing the shovel button.

Edited by risingstar64
Link to comment
Share on other sites

  • 2 months later...

I recently implemented support for surface maps, but while I know that buildings cannot be placed on ground tiles with varying heights, I can't seem to locate any info on the specifics of this mechanic. If anybody is familiar with exactly how tile height plays into placing buildings (does every grid square that the building takes up have to have the exact same height, or is there some amount of leniency, such as 1 height difference at most per adjacent tile? etc..) please feel free to fill me in :)

Link to comment
Share on other sites

I recently implemented support for surface maps, but while I know that buildings cannot be placed on ground tiles with varying heights, I can't seem to locate any info on the specifics of this mechanic. If anybody is familiar with exactly how tile height plays into placing buildings (does every grid square that the building takes up have to have the exact same height, or is there some amount of leniency, such as 1 height difference at most per adjacent tile? etc..) please feel free to fill me in :)

From what I know, there is a bit of leniency, at least with the power path "tab". The ground actually seems to adjust slightly when there is a height difference.

Link to comment
Share on other sites

  • 1 month later...

Hey rising star!

How's this going recently? 


Something I've noticed in the current version is it appear either they're following stacked up commands to sweep that I manually gave, or automatically going to sweep stuff up once you've given a command to sweep one pile, they'll automatically move on to the next pile when they're done. Possibly both, for sometimes they'll sweep up an entire pile, or just one "layer" of the pile, though perhaps I've clicked it multiple times (showing commands are stacking in a waiting list for that particular raider?)

But, it seems I can't stack commands for drilling walls, so I can't right click a series of walls to drill, they'll drill the first one and then forget what they're doing, they may go and drill the last of the series that I clicked, but that's it. They'll then stop and say "null"

 

I think, given that tasking is essentially working even if it is a bit janky at times like above, you could add some other content, perhaps it would be better to sort out tasking fully when the core content is added (so you know all the tasks that are going to exist in the game, so you can work around them?) though perhaps it would be better to make a properly functioning tasking system, which calls on a separate, moddable set of tasks each of which is it's own "thing", so the player gets to essentially add tasks to the task list, which is worked down by each raider, when it reaches a task on the list, it enquires about the task from it's name in the list say "Sweep -50,23" so it calls on the task called "Sweep" puts in the given data (coordinates) and within the sweep task it'll say something like path to: X,Y; check X,Y is still rubble, sweep animation; set decal of tile X,Y to a clear ground/next step of rubble clearing; spawn (or don't) an ore object somewhere on the tile

etc. etc.

 

I think this would then allow for people to add their own content easier by creating their own "tasks" like "get laser blaster" if for example you didn't add that yourself. and they wouldn't have to alter anything else other than adding the laser blaster as an object. 

Link to comment
Share on other sites

Looking through the game source, I honestly do not know where the task system is. Everything is lumped into 5 JS files with at least 150 LOC each (the longest is over 800 LOC). A clear-cut task system like you mentioned, @ch4rl1e97, would actually be really nice and help out a lot.

 

@risingstar64 I wrote a queue system a while back that might be similar to what you may need. You might consider using objects to define each task. Because I expect you'll want to implement the task priority level system, an idea for the object structure might look like so:

// Example clear rubble task
{
  name: "clear",
  details: {
    x: 250,
    y: 250,
    item: "rubble"
  }
}

// Example pickup item task
// X-Y coords would refer to location of tool store
{
  name: "pickup",
  details: {
    x: 10,
    y: 100,
    item: "sonic-blaster"
  }
}

 

With a structure like this (you really might be able to drop the nested object and merge it into the main object) you can quickly check the task type and compare it to the assigned priority for that task defined elsewhere:

// Current task priority levels
// 1 === highest priority level
{
  clear: 2,
  pickup: 5,
  repair: 1,
  // etc...
}

 

Thus as you proceed through the queue you can determine the priority level of each task and respond accordingly.

Link to comment
Share on other sites

  • 2 weeks later...

@ch4rl1e97 Hey! I believe in the most recent build sweep tasks can be done by raiders automatically as long as they are carrying a shovel, in addition to the player being able to manually instruct a raider to sweep. Sweep tasks are broken down into 4 individual tasks for the 4 potential amounts of rubble (ranging from a large amount of rubble to a small amount of rubble). As in the original game, there is no task queue; only the most recently assigned task is carried out. Unlike in the original game, however, here raiders do not stop working on their current task when selected. Instead, after selecting a raider, you must press the stop button to instruct that raider to stop performing its current task. You can then instruct that raider to perform whatever task you want. Note that a raider will not select a new task automatically until it is deselected.
 

I have not touched this project in about a month as another project recently came up that requires most of my time, with the remaining time dedicated to school work. Once I have some time off, however, I have a small list of changes and bugfixes that I intend to get to for rock raiders, at which time I will also consider implementing a proper task queue as suggested by you and @le717:) 

Link to comment
Share on other sites

  • 2 weeks later...
  • lol username featured this topic
 Share

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.