rozniak / junkbot Goto Github PK

My plan is to use generalized user interface controls in Junkbot. The original game has an image per button used in the game, with the text already in place. Whilst it would be easy to just render these images, I think it would be nice to have the buttons be dynamically built, in case any new features get added to this version and we need custom button text.

This is kinda done right now... but it's not great - I implemented a rough DrawBorderBox method in rzxe that it makes use of right now, it was good for testing but it's less than ideal.

Essentially this is blocked by rozniak/rzxe#1 - once the necessary feature is available in rzxe then this can be implemented (hopefully) quite easily.

Need a method of saving the current game progress - it's important that this is able to save per-game (Junkbot, Junkbot Undercover, any user made levels in future).

Suggest that this is saved in the user profile, with each game/level pack having its own progress JSON. For instance on Windows it would be something like:

%appdata%\Junkbot\progress-junkbot.json

With contents like:

{
    "building-progress": [
        [
            {
                "done": true,
                "moves": 1
            },
            {
                "done": false,
                "moves": 0
            }
        ],
        [
            {
                "done": false,
                "moves": 0
            }
        ]
    ]
}

This one might take a bit of thought... Junkbot and Junkbot Undercover have levels split into blocks of 15, arranged into 'buildings' or 'areas' on the menu.

There needs to be a UI component for this, but it's not super straight forward because the layout is very different between the two games.

Here's the building selection on Junkbot:

And here's the building (or I guess 'area') selection on Junkbot Undercover:

(It's probably obvious, but the gap in the 3D border in Undercover is similar to the look of the currently selected tab in the original Junkbot, if you get what I mean)

For now I suppose we could just have a simplistic UxComponent for either one, and think about extensibility when the time comes regarding custom levels/level packs.

The bin is not removed from the scene upon collection at the moment, obviously this needs to be implemented.

Right now the project doesn't quite build on Linux - I'm on Debian 10 as my main now so I'll sort this out.

Two things I've encountered so far:

• The pre-build scripts don't seem to be working...
• The path separators are Windows-specific (\ instead of /) - need to replace with Path.DirectorySeparator

Might be more, will work on this via the bugfix-1 branch.

The AppVeyor CI builds are broken I believe since I shifted the codebase around. It needs to issue nuget restore for src/Junkbot.sln. Currently it's doing it in the root directory which doesn't work because that's not where the solution file is.

Unplaced blocks should be rendered as though they were placed, in terms of ordering on the z-plane. Right now, they render on top of already placed blocks, which is not how they render in the original game.

As title.

As noted in the tiling mode commit, it doesn't work correctly outside of native res.

9bc74f1

Could easily be fixed by using the native res as a uniform for calculations or something like that. Postponing it for now because I want to work more of the project and can come back to it later.

As title.

Similar to rzxe#6 - a lot of the Junkbot code I wrote was kind of rushed and in the interest of getting things up and running. It is not really up to my standards at the moment, so at some point I will go through and have a tidy up of the codebase in respect to formatting and Intellisense documentation.

As title.

Now that the walking code appears to be 1-to-1 with the original game, it looks like additional work is required on the walking animation itself. Most noticable when Junkbot is walking down stairs to the left, his sprite displays a Z ordering problem... I think this is simply down to the position of his sprite rather than a rendering problem.

Going to have to go frame-by-frame on the original to see how they compare in order to correct them.

As title.

Need to track the number of moves the player makes.

Fairly simplistic - will need to implement a UxComponent for the level list here in order to select levels (of course).

For reference, this is a screenshot from the one in game:

Quite a simple one - the scene is rendered slightly offset on the y-axis when compared to the original game. In the original, on the demo level, the floor is pretty much flush with the UI chrome aside from the isometric perspective of the sprite. In this ported version it's raised a bit.

I would suspect this is due to a discrepancy in how the coordinate system is handled - I think the original must use the bottom-left of sprites/the overall level as (0, 0), whereas of course in the ported version it's using the top-left for (0, 0). The offset is probably the height of the isometric portion of sprites (I think CellSize is the '2D' size of each object, not counting any isometric perspective on the objects when rendered in game).

Currently this implementation goes straight into Junkbot itself without playing the introduction animation. There's no way of playing that kind of animation in rzxe yet... it'll need thought because it's quite a complicated thing I think, even if it is 99% tweening.

Even when support is added the animation will have to be hand recreated... not a simple jobby.

There is a bug in the cell assignment logic when Junkbot attempts to ascend a 1x1 staircase. Such a staircase is present in loading_level on the splash screen. Junkbot will walk over the first brick successfully, but the second stack of bricks will cause a crash when he goes to walk over them.

The crash:
Scene.AssignGridCells: Attempted to assign an occupied cell!!

Profile code exists so should be able to update level status when completed.

As the game doesn't have a fixed aspect ratio, when resizing the window it often results in distorted graphics.

The level rendering is not fully complete yet in Scene.cs - the background and decals need to be rendered. Shouldn't be too difficult as they are just static so could just have some map of decals.

As for the background... I think it is a simple tiling texture - rzxe can do this via DrawMode.Tiled.

The code in Scene.cs is coupled with other things that makes it unsuitable for writing unit tests on. The same goes for the actor code. There shouldn't be any dependencies required other than between actors and their scene (no requirement for AnimationStore for instance.

This issue is a prerequisite for #21 which I intend to use test-driven development to implement accurately.

As title.

As title.

As title.

As title.

Hey! Firstly, just wanted to say that I'm really happy to have discovered this repo - Junkbot was one of my favourite web games all those years ago, to the point where I'm currently making a game with similar mechanics.

Something that's currently stumping me, though, is the isometric rendering of all the game elements. Obviously, elements to the right and to the top render above elements to the left and bottom, but how does the game code achieve this with the objects that are greater than 1 block in length/width? We see Junkbot still being behind blocks to his right, and the 8-stud-long bricks being above other bricks directly below.

How does the game code achieve this rendering? I've scoured through it but can't see anything yet. Is that specific code in the repo yet?

In-game UI should track that the move count is on or under par (the gold awards).

As title.

Odd.. during my testing unrelated to movement tests, I happened to find Junkbot doesn't turn around on the edge of ledges where there is no stairs. He does repeat the first half of the walking animation which suggests at least something is going on - needs investigation.

Next step is to implement the brick picking and placement logic. There are some rules on being able to pick bricks, along with which bricks are taken alongside the brick selected. Will need to play the game to do some testing to see what the rules might be.

I am also marking this as wait-submodule because picked bricks need to be rendered semi-transparent which is not yet supported by rzxe.

Need to implement the state for Junkbot eating a bin - it should trigger an event so that the rest of game logic can verify if the level has been beaten.

Following on from #9, I will work on merging the game logic that @Aaronlcj did a long time ago for Junkbot. Hopefully when the scene code is up and running I'll be able to have a proper read through and get his work in place which would be a good boost to the project.

Side note - my apologies for taking so long to get to this stage @Aaronlcj 😩

Enough of rzxe has been implemented and some shell code done that makes me happy to work on some actual 'game' again. As a first step, I want to render the scene as in the test code I originally wrote when parsing the level data.

The splash screen contains a little window where a 'demo' of the game can be tried out. This is a good candidate for testing simple game scene code.

There is only code and assets in the shell atlas for the default button state at the moment. Need to implement the hovered button assets.

I've started working on a Junkbot remake here: https://github.com/1j01/janitorial-android/
Your ripping efforts have been very useful in that, especially with the atlas JSON (which you don't normally get along with a spritesheet) that was useful in quickly integrating the Junkbot animations, and the sound.
I tried to rip files from the .dcr using offzip, and only managed to extract some random set of sound files.
I'm curious, what did you use to rip the resources?
Also, if there's any other ways we could help each other out, that could be fun. I have the brick dragging mechanics working, if you want a reference for that - also with cursor images (extracted from screenshots grabbed with Irfanview).

As brought up in #7 the stitched sprites will have overlapping problems with the isometric view. The original game has the characters (anything more than a single cell tall) split into multiple sprites presumably to solve this overlapping issue.

Unfortunately this means the tedious work done by @TommytheJerk stitching the sprites together is going in the bin. 😩

On the plus side this is far simpler from a ripping perspective as we just use the original data.

Need to implement the level beginning and ending dialogs, this is being developed in parallel with rozniak/rzxe#35

As title.

I have ripped the sprites back out again replacing the stitched versions. As a first step with this data we'll need to swap the old atlas + animation data with new stuff using the new sprite rips.

As title.

Next target I think is to get to in-game state, not necessarily with the level beatable - just something that loads (since the bin state is logged as #22 ). The select level state has a UxLevelList that has a LevelSelected event that should make it easy to launch into the levels.

Will just need to ensure the actors load - suggest to just provide some basic scaffolding for now.

I think following some of the repo restructuring, the AppVeyor build process has broken - need to look into fixing this.

With some progress been made on font rendering in rzxe, it should be possible to start working on code for controls to build the 'select level' interface.

This may be dependent on some event stuff for controls to handle clicks and stuff. There is some code for it but I haven't used it in a while so marking this in case some changes in rzxe are required for work on this issue.

Have just noticed that the level list starts with Art in the Lobby when it should start with New Employee Training, looks like the indexing is off by one.

The README.MD is kind of out of date - the assets are pretty much entirely ripped (organization notwithstanding). Plus Junkbot is actually walking around now (rzxe has progressed also), granted it's not much but it would be good to present this so that the project looks like more than just 'nothing is really done yet'.