Eike

#8-bitBot is coming along!
- created a steam page (https://store.steampowered.com/app/3959370/8bitBot/)
- added a decoration system, together with quite a few seasonal decorations so far
- integrated a bunch of new songs and a level playlist system […]

[Original post on mastodon.gamedev.place]

Must work faster, Halloween is coming!

In other news: I got a steam page approved: https://store.steampowered.com/app/3959370/8bitBot/

Things are getting serious. I am not afraid 😅
Not at all👻

#gamedev #solodev #raylib

Refining the little bots for my 8-bitBot game; The chassis kept clipping through walls and other bots, so I made them more roundish and made them smaller. The wheels are now quite a bit too big - but I kinda like the goofy look. What do you think?

#gamedev #solodev #raylib

The image shows 8-bitBot running both as a desktop application and as a web build on a local server. On the left side of the screen, a web browser is open displaying the game running in a tab with a localhost address. The interface shows a level with multiple conveyors, factory machines, and boxes labeled with letters A and B. Below the game area, a terminal warning message is visible, along with some descriptive text about the project. On the right side of the screen, the same level is open in the desktop version of the game. Both layouts match exactly, with identical positions of boxes, conveyors, and robots. In the background, a code editor is visible, showing project source files and debugging tools. This demonstrates that a level created in the desktop application can be shared through a generated URL and then loaded and played directly in the browser version running on the local server.

I nearly 🥲
I just shared a level I made on my desktop build with the web build through the URL. 32 days ago, I started working on the sandbox editor, having already the idea that I want to be able to share levels via URL encoding - and now it is beginning to come together.
#solodev #gamedev #raylib

I still have to add the browser code path to read and load the level from the URL. That is another annoying step to implement.

And then there is the book of TODOs with other tasks in the rest of the game 🥲🫠
Not to mention that I have to set up the steam page and all that 😭

Sharing the levels via URL/clipboard is the last feature I want to add to the sandbox editor - and as always, I have trouble to finish it. I am unfocused and just want to start a new project instead 😫
Testing all edge cases is also not fun; here the import duplication fails.
#ADHD #gamedev #solodev

Screenshot of the sanbox configuration dialog in 8-bitBot. Several tabs can be selected (Manage, Information, Code, Win, Production). The Manage tab is active and a list of sandbox levels is shown. The selected one is displayed with its title and description text. An instruction limit and step limit is also shown, which is defined by the provided solutions for that level. At the bottome are several buttons: New, Load, Duplicate, Delete and Share, which refer to the selected level.

Did some minor cleanups and improvements in the menu system for the sandbox level configuration. Tomorrow I will start implementing the share button so levels can be shared via URL.

#solodev #gamedev #raylib

The image shows 8-bitBot in editor mode during a map size test. On the left is the programming panel with playback controls and program slots at the top. A few commands are placed in the vertical list, but most of the panel is empty. On the right, the isometric game world displays a large square map. Conveyor belts run along the outer edges, forming a continuous loop around the perimeter. Several blue boxes labeled with the letter "A" are placed on the conveyors. A single blue robot is positioned inside the open center area of the map. At the bottom, the editor tabs "Map", "Bots", "Boxes", "Win", and "Production" are shown, with "Boxes" currently active. This setup demonstrates the maximum map size of 16 by 16 tiles, used for testing the upper limits of level dimensions.

Added a configuration setting for the map size. 16x16 is maximum and ... oh boy, it is HUGE. There is no camera zoom/panning and I also don't intend to add one. Maybe I limit it to 10x10. 16 is the max size btw, since coordinate values are 4bits.

#gamedev #solodev #raylib

The consumer factory elements are working to a satisfying degree - even with sound 🎵! The A/B/C boxes are currently very abstract, and it would be nice if it was something specific (ore/coal/wood/etc), but first I have to get the last missing feature in: Producing units.

#gamedev #solodev #raylib

Isometric factory scene with conveyor belts and storage units. Several gray machines with red and yellow hazard stripes feature displays that show which box type they accept and how many they have consumed. Three large colored boxes labeled A and B are moving along the central conveyor with a small blue robot pushing them. On the right side, two brown C boxes are stacked near another consumer unit. The floor is tiled in a grid pattern, and multiple machines are connected by conveyors.

Adding displays to the consumers that display which box types they accept and how many they need. I think this is good enough for now. Now I need to make the counters work and configurable and then move on to the producing units.

#gamedev #raylib #solodev

My original vision was to have a factory like setup where the bots distribute the boxes from various input sources to respective outputs. I might also need more than 3 box types for that.
Total overload of possible options 🫠
On the bright side: This is the last big missing feature for this game.

Maybe I should make these entities exclusive to one tile, each only consuming one box type with an additional count.
Consumer units should also show a physical connection to clarify the connection, I guess.

But I am not sure this will visualize well. Consumers and producers looking identical is already a cheap choice to begin with; but having different consumer types on one tile? Not helpful either 🫤

Producing units can refer to consumers, requiring certain counts to be consumed before outputting something. E.g., a single tile could house an A and a B consumer (2 entities) as well as a production unit that produces C with configurable amounts (so 2 A + 1 B = 1 C).

The image shows 8-bitBot in editor mode, featuring a level with new factory elements. On the left is the programming panel, where commands for the robot can be arranged in a vertical list. Playback controls and program slots are at the top. On the right, the isometric game world is displayed. A blue robot is on a conveyor belt next to several colored boxes marked with letters "A" and "B". At each end of the conveyor, there are large orange factory machines. These elements are designed to produce or consume boxes, acting as sources and sinks for materials in the level. At the bottom, the editor tabs "Map", "Bots", "Boxes", "Win", and "Production" are visible, with "Production" currently active, indicating the player is editing the placement and configuration of these factory machines. This setup allows for designing levels where robots must transport and manage boxes between production and consumption points.

Consumer/producers in the scene, not yet functional or anything. Worrying about how to visually clarify what these orange elements are doing. The concept is that consumers take in boxes of a specific type and that producing units produce boxes of a specific type...
#gamedev #raylib #solodev

Added a new win condition: Removing boxes.
I think I need to add consumers and producers next.

#raylib #gamedev #solodev

The image shows *8-bitBot* with the **win condition editor UI** open. At the top, four tabs are visible: **Manage**, **Information**, **Program**, and **Win Conditions**. The **Win Conditions** tab is selected. On the left side of the window is a list of win conditions. One entry is shown: *Bot 0 @ (6, 4)*. Below the list is a button labeled **Add new**. On the right side, a minimap rendering of the level is displayed. It shows the grid layout with walls, conveyor belts, and empty tiles. A **red rectangle** indicates the current mouse-over marker, showing which tile the cursor is pointing at. A **yellow rectangle** marks the current target coordinate, which defines the selected win condition. At the bottom-right of the window, a red button labeled **Delete condition** is visible, allowing removal of the selected win condition. This interface is used to set up the objectives that must be fulfilled for the player to win a level.

Directly rendering a minimap into the UI for selecting coordinates, because ... why not? GetWorldToScreen and GetScreenToWorldRay are good old friends to find the right scale and position for the camera.
#raylib #gamedev #solodev

The thing is: understanding the data structures and coming up with ideas how a UI could look like is not a technical problem to solve.
Positioning the UI elements via code is not a great experience, but it is also not terribly complicated.
So I guess there's not much I can do about it :/

The image shows *8-bitBot* in editor mode with the **win condition UI** open. On the left is the standard programming panel, currently empty, with playback controls and program slots at the top. In the center, a configuration window is displayed with four tabs: **Manage**, **Information**, **Program**, and **Win Conditions**. The **Win Conditions** tab is selected. The window contains a blank list on the left where win conditions can be added, and a placeholder area on the right labeled “Selected win condition” for details of whichever condition is chosen. At the bottom of the screen, the editor tabs “Map,” “Bots,” “Factory,” and “Win” are visible, with “Win” currently active. In the background, the isometric grid of the game world can be seen, currently empty, ready for editing. This interface is part of building the system where level objectives can be defined and configured.

Making the sandbox editor UI is quite painful, but I am not sure which part is painful. The parts I see:
- understand data structures
- come up with UI
- position UI elements in code
- add new loca
- test / debug UI
I think the first 2 points are my main pain points ...

#gamedev #solodev #raylib

The configuration dialog for the sandbox level editing is coming along. Adding new levels and loading levels works. Writing all UI widgets from scratch is a bit of work but also satisfying - mostly because it feels pretty lean.

#gamedev #raylib #solodev

The image shows 8-bitBot in editor mode with the sandbox configuration popup open. On the left is the usual programming panel where players arrange commands for the robot. In the center of the screen, a configuration window is displayed with three tabs: Manage, Information, and Program. The Program tab is active. This window allows the player to set limits for each instruction type, such as how many times the robot can move forward, turn, or call subroutines. Each action has adjustable values shown in boxes with arrows for increasing or decreasing the limits. Program slots 1 through 8 can be configured individually. At the bottom of the screen, the editor tabs “Map,” “Bots,” “Factory,” and “Win” are visible, showing that the player is working within sandbox mode to adjust level behavior and restrictions. In the background, part of the isometric grid world with conveyor belts can be seen.

Adding a configuration page for defining the instruction token limits. Next things to add is the level management to allow loading/saving sandbox configurations and a page to configure the win conditions.

#gamedev #raylib #solodev

Terminal screenshot. The text: INFO: SYSTEM: Compress data: Original size: 414 -> Comp. size: 265 INFO: Serialized sandbox level (len: 414, compressed: 265): SBX v 1 guid -2547067062498283141 title Hello world description This is a description of a sandbox level. It can contain a description of the objectives, hints and tips or other messages that will be displayed to the user when starting the level to play map 8 8 ###<v<<#####v^^######^^###v<#^^###v##^^###>>>^^################# bots{ 1 4 2 3 0 1 2 0 0 0 0 0 0 0 0 } boxes{ : 1 4 0 6 4 6 1 5 5 : 2 5 4 5 3 : 3 3 5 } INFO: [000]: 654ebb6ac34010ecf72b06d426416f2b46b84895d44991ca709236d685f39dd0ae6507e37f0f120a INFO: [040]: 1832530c3b3bbbccfbcb2726247438d90e8f69916fe272139769fe5ca55596e409a955c77865e702 INFO: [080]: ce61741d752ced6807b5c1e3a3b7022b30b877c3170cc4f8ae0917389ed83de14dd11a8f367835d6 INFO: [120]: ff3fd09e119a6f6ed54e2c0fe8ad5781f11dd40e82302268cf238e2c620e2cd0de28ced639348cce INFO: [160]: cae0cc0f77d0b0bc3a098f38f7ec216a46b5feb0d84b993933a7e9680654a8288aa27aaaeb68c6b4 INFO: [200]: df2f1a2d3ad5abaef36eb7fbdbdf819aa072a5043952648829418a7826c55849376ac285e54a5b24 INFO: [240]: 9423a612399548a840415ba45420a702196d915186826ef40b INFO: Deserialized sandbox level successfully ERROR: Deserialized level does not match original level

Just boring level serialization and deserialization code. For some reason, I prefer ASCII formats instead of binary encodings. And yes, it isn't JSON; Just something simple I am hacking together, while trying to be somewhat space efficient. It has to fit into the 2kb URL limit...
#gamedev

I really like the implementation; it is an immediate mode implementation, and most of the functionality sits in a grotesquely long function of around 500 lines - but I find it easy to understand and extend; most of the code is just the event handling part (cursor/mouse navigation, etc).

A multiline and single line text field. The content is too large for both of the components and the single line text field that is having the focus is scrolling in a way that the cursor that is on the far right of the text is still visible.

Another screenshot with a similar situation. This time, the multi-line component has the focus. A part of the text is selected (which is highlighted with cyan color). The text is scrolled so that the first line is outside the scope of the text area component.

Testing the text field component with different texts. It handles now also the case when the text is too large for the textfield, in which case it clips it correctly. The cursor stays visible by scrolling the text accordingly.
#raylib #gamedev #solodev #c

Continued tonight implementing the text field element. I added a bunch of features by now:
- Selection range
- Multi line editing
- Arrow/Home/End navigation
- Click to set cursor
- Double click to select word
- Copy & paste
... and a bit more

#raylib #gamedev #solodev

Screenshot from the game 8-bitBot. In the center is a window that covers most of the area. The title is "Sandbox configuration" and on the next line it say's "Title:" with an empty sand colored rectangle next to it that is supposed to become a textfield.

Textfield, my old nemesis, here we meet again!

(I am making all UI elements up on the fly just using DrawTextureNPatch, DrawText and DrawTextureRec; so without using anything prebuilt - because apparently, I like this pain 🫠)

#gamedev #raylib #solodev

@Xanatos thanks 😊.
I keep thinking that it is maybe a tad to fast 😅.
And the beep when falling could be maybe a bit delayed ...

I am sorry, number 2 😭

But someone had to test the falling animation when a box is loaded 😢

Also fixed the box rotation when loading and unloading the boxes. Now I need box producers and consumers. I should also think about storing sandbox levels with a name or so...

#gamedev #solodev #raylib

Still plenty of things to fix, test and implement, but the basic functionality is there: Boxes can be loaded and unloaded.

#gamedev #solodev #raylib

Looks like it's getting busy 😁

There is currently a limit of 12 boxes - each box is a struct of 3 bytes for position information and flags. I might increase the max amount a little.

Next I want to add production and consumption entities.

#gamedev #screenshotsaturday #raylib