Messages

1

SFML projects / Re: BubbleByte 🫧🐱 incremental/clicker game about cats & bubbles!

« on: March 14, 2025, 06:16:53 pm »

BubbleByte has officially launched on Steam! 🥳🎉
I'd be incredibly grateful if you tried it out and shared your thoughts with me! ❤️
https://store.steampowered.com/app/3499760/BubbleByte/



Check out the release trailer here:
https://www.youtube.com/watch?v=Db_zp66OHIU

2

SFML projects / Re: BubbleByte 🫧🐱 incremental/clicker game about cats & bubbles!

« on: March 06, 2025, 01:25:19 am »

I think my point about stress is it seems to be a "if you're slow, you progress slowly" as opposed to a "if you're slow, you'll fail until you're quick enough" type, which is more stressful so this would less so

This game is definitely the former -- you cannot really fail

Your bubbles look quite nice. I had presumed they were just static sprites; I had not realised that they were adjustable on the fly with your shaders. Nice work!

Thank you, it took quite a bit of work to get them to look right. In the end I created a lot of uniforms to tweak, and used ImGui to actually play around with them in-game until I was satisfied with the final look.

For me, though, overall, there seems to be too many "particles" (it seems "fussy"). But that's just me; I don't really play bullet hell games for this reason.

Gotcha. There are already options to disable all particles or certain types of them (e.g. the coin particles). They also help with improving performance on lower-end machines

Anyway, I’ve made a lot of progress over the past few days, especially on the graphics side. My girlfriend created some extra backgrounds, and one of my best friends is composing a few BGMs. Each of these is themed around the unique cats you unlock as you progress. To tie it all together, I implemented an "unlockables" system that lets you freely select these backgrounds and BGMs after unlocking them once.

Here are some sneak peeks!

- https://i.imgur.com/zQBk0Qo.mp4
- https://i.imgur.com/Kpk5FKf.mp4

I also revamped the trailer, keeping in mind that most viewers decide within the first two seconds whether to keep watching. This new version is much more direct and to the point:

- https://www.youtube.com/watch?v=TWsr9I6lYDo

What do you think? Would this be a better fit for Steam and social platforms like Reddit compared to the first, more slow-paced trailer?

3

SFML projects / Re: BubbleByte 🫧🐱 incremental/clicker game about cats & bubbles!

« on: March 01, 2025, 05:15:35 pm »

Nice. Looks cool!

Smart to involve your real-life cat too!

Thank you!

I'm guessing it's not a particularly stressful game?

Unless you're actively trying to speedrun the milestones, it is meant to be a more relaxing experience.

I wouldn't describe it as a full-on idle game... I'm still making some final balance tweaks, but at the moment I'm quite pleased with the flow.

Early game is a bit more on the active side with clicking combos.
Mid/late game is more about picking a strategy and choosing the most impactful upgrades for that, optimizing cat arrangement, and occasionally interacting with the various minigames.

If you've played Cookie Clicker, the active-to-idle ratio is quite similar. Maybe I should add some sort of "rested state" where inactivity boosts production, for people that prefer idle games...

Of course your cat is called "Byte" 

It *had* to be a nerdy name, no way around it 

---

Anyway, here's a few more sneak peeks!

This is a prestige upgrade that allows some cats to open up portals to hell:
https://i.imgur.com/tAPs0H5.mp4

And, most importantly, this is a bubble shader I wrote today. Do you think the game looks better with it on, or should I leave it off by default? Performance cost is not significant.
https://i.imgur.com/k9lIWiQ.mp4

4

SFML projects / BubbleByte 🫧🐱 incremental/clicker game about cats & bubbles!

« on: February 28, 2025, 02:17:20 am »

https://www.youtube.com/watch?v=nWmuHIllETs

Hey folks, here's what I've been working on lately -- a cutesy/cozy incremental game with a combination of idle, clicker, and tower defense mechanics, inspired by my cat Byte's fascination with soap bubbles. 🐈

In short: you start as a lone bubble popper, earn money by building up clicking combos, and purchase upgrades and cats. As the game progresses and you discover more types of cats, the automation aspect kicks in: by strategically arranging cats of different types in the right way, you can start earning a lot of money very quickly!

There is a prestige mechanic that grants game-breaking permanent upgrades, and a map exploration mechanics that unlocks legendary cats with unique minigames and mechanics.

I'd be happy to hear what you think, and I'm also looking for some beta testers to help me tweak the balance before release -- both veterans of the genre and newcomers are appreciated! ❤️

BubbleByte | Wishlist on Steam
- https://store.steampowered.com/app/3499760/BubbleByte/

5

SFML development / Re: Defining "consensus" policy for disagreement on proposals

« on: June 24, 2024, 06:34:30 pm »

My comment wasn't directed at you or related to having a BDFL. I was trying to achieve calling out a self serving proposal by Vee, one which would give him much more influence over the direction of the library at the expense of other stakeholders.

Could you please point out where I said that my vote would weigh twice as much as the other stakeholders' vote?

Or could you please point out where my proposal mentioned that if one of Vittorio's proposals gets below 75% approval he gets a pass anyway?

Oh, I guess I never said neither of those things. Just complete insanity.

6

SFML development / Defining "consensus" policy for disagreement on proposals

« on: June 17, 2024, 04:54:46 pm »

As there recently were some disagreements on whether certain PRs should be merged or not, or on whether SFML should move in a specific direction compared to another, I believe it would be in the best interest of the SFML project and of the maintainers' time to decide on a simple process that defines "consensus" for us, to minimize time spent arguing and working on changes that will not end up being part of SFML.

I propose a simple system loosely based on WG21 straw polling -- basically, in case of a disagreement, all active SFML team members will vote with a Y/N. 75% of voting in favour of changing the status quo is required to proceed.

Despite many SFML team members being listed on GitHub, I believe the currently most active ones are:
- Vittorio Romeo
- Chris Thrasher
- Lukas Dürrenberger
- binary1248

I suggest that those four should be the ones taking the vote when required. If anyone else from the SFML team would like to be included in the polls, please let me know.

Note that there won't be a formal process for polling, but let's say that if 75% of voting members express concerns/disagreements with a proposed change either on GitHub or on Discord then there's no point in trying to argue or continue work on that proposed change.

7

General discussions / Re: Anyone targeting 32-bit platforms?

« on: December 24, 2021, 04:35:59 pm »

My case is not statistically significant at all, but still I'm using SFML with TGUI for my own applications and sometimes on freelance. And after the third complaint that application doesn't work my default choice is Win32 for all applications. To be clear - those complaints weren't SFML-related. 
But I'm not active user of SFML and can live even without x32 out-of-the-box support.

To be honest I not understand how architecture could be related to C++ standard? Architecture about users and standard is about developers.

Thanks for sharing your use cases, that is good to know. I wasn't really clear in my OP, I was mostly thinking about people developing on 32-bit architectures rather than targeting them via cross-compilation -- in my experience those kind of people are not really interested in having updated toolchains or development environments.

Regardless, there is no consensus on the proposal of dropping 32-bit support for 3.x, so this will not happen anytime soon.

8

General discussions / Anyone targeting 32-bit platforms?

« on: December 23, 2021, 07:43:54 pm »

Hello -- we are considering removing 32-bit support from SFML 3.x.

I'm curious if anyone has actively been using SFML targeting 32-bit platforms.
If so, what's your use case?

Also, do those platforms support C++17?

Thanks.

9

General discussions / Re: New SFML Team Member: SuperV1234

« on: November 30, 2021, 06:16:47 pm »

Thank you for the warm welcome! Eager to bring SFML into the modern C++ era

10

SFML development / Re: Getting the ball rolling

« on: November 23, 2021, 12:46:43 am »

I see, but since you opened a PR in the SFML repo, the idea is probably also that other users can benefit from the changes and at some point it becomes part of the "official" version, no?

It's totally fine to have things messy as a PoC, but I'd still say we should clean a bit up before merging to the main repo (on any branch). And by that, I definitely don't mean the code needs to be perfect, but things like passing CI, readable commit history, and an easy way to comprehend changes (this is where commit messages help, I don't insist on changelog for now). Not for me personally, but to give other users the option to comprehend the changes and to contribute themselves with feedback, comments, improvements.

It's part of continuous integration: make sure things are more or less "green" right away -- otherwise we accumulate tech debt that we have to sort out later, in a giant PR when merging to master. In my opinion, if we take SFML 3 serious, we should make the branch usable from the start, and motivate users to try things out.

This is also what we would communicate by staying on master. It doesn't mean there won't be many changes, or even breaking ones, but that it's in an internally consistent state and ready-to-use, and it makes us accountable

Would be great to hear other team members' input here.

I totally agree with you, and that's why I don't want my big PR to be merged. If someone wants to use it, they can checkout the branch and play around with it.

For merging stuff into SFML, I want to create smaller and easily-reviewable PRs. I already have a plan of how to split the work, I just need a target branch and someone that reviews the stuff.

My current plan of attack would be the following:

• Get the warnings changes merged, as this would cause lots of conflicts against larger changes
• Create a sort of release branch 2.6.x, for any remaining features/fixes for SFML 2.6 (e.g. Scancodes)
• Start with step-by-step PRs for C++17 on the master branch
• Back merge changes on the 2.6.x branch to master (limited set of changes)
• Back port critical fixes to 2.6.x and consider patch releases after the 2.6.0 release

The plan sounds good, but if we had a separate `sfml3` branch we could already start sending PRs towards it in parallel, we don't need to wait for scancodes or #1846. Merging either into the `sfml3` would be relatively easy.

As originally defined in the Roadmap, I'd like to keep the SFML 3 release relatively slim and just mostly get C++17 changes in and much rather do a bigger API jump for SFML 4. There's some advantages to long living API stability (e.g. see all the SFML learning material that applies for basically all SFML 2 versions), but ultimately trying to bring a whole API evolution next to a C++17 refactoring in one release, will extend the release horizon already to multiple years, but one step at a time.

I disagree with this point, I think that this is a great opportunity to clean up the API. It's been years and we don't have SFML 3 yet. Are we seriously going to ask people to wait a decade before we can do some API breaks?

If users are not able to make small reasonable changes to their code to keep up with an evolving library, they can always use the older versions. We don't want to end up in a situation where we have to sacrifice the quality and speed of our work. SFML 3 offers an opportunity to improve SFML as a whole, and a new major version does imply API-breaking changes.

11

SFML development / Re: Getting the ball rolling

« on: November 22, 2021, 04:26:37 pm »

I wonder though if we should not use the master branch directly for SFML 3, and maintain a separate sfml2 branch for a while. [...]

I think that creating a `sfml3` branch is a good starting point. It doesn't mess with `master`, and we don't need a lot of feedback/exposure while we're just starting out. As soon as we have something more significant, we can start asking for feedback and potentially change our approach.

What I would appreciate regarding contributions, is that pull requests are reasonably sized. We can make an exception for the initial one, but if possible let's not add even more to this one. The risk of big PRs is that it becomes a daunting task to review, and people are scared off if they have to invest multiple hours just to go through the code -- which is exactly what we don't want

Also, would it be possible to merge dozens of commits to one, or a few, with meaningful commit messages? That would also help understanding a lot

The large PR is, as previously mentioned, a "proof of concept". More of a statement than anything, saying: "Hey, I did this in two days and it works on a real game. Let's get to work!".

I don't want that PR to be merged, I want to use it as a testbed and maybe maintain my own fork of SFML as I don't care about stability and want to experiment with stuff.

These are the things I request:
1. Please give me a target branch I can send PRs to, in order to initiate the SFML3 project.
2. Please tell me that my (small) PRs will be reviewed and merged in a timely manner, within reason.

If I can have both (1) and (2), I'll start creating small PRs that can be individually reviewed. The first one will only change CMakeLists to build in C++17 mode. The second one will have some small C++17 usage. And so on.

Looking forward to know how to proceed.
Cheers!

12

SFML development / Re: Getting the ball rolling

« on: November 19, 2021, 09:44:05 pm »

Here's a proof of concept PR that converts SFML to C++17 and removes some classes made obsolete by the C++ Standard Library: https://github.com/SFML/SFML/pull/1847

13

SFML development / Getting the ball rolling

« on: November 19, 2021, 07:15:16 pm »

This is a post from the perspective of a SFML user who has contributed small PRs in the past. To me, it feels like the development of SFML is stagnant. It's 2021, and SFML is still stuck on C++03 for no good reason whatsoever.

I open the roadmap on GitHub and I see a PR for a small reasonable improvement that was created back on the 12th of October 2014, and that is still open and unmerged.

- Why is the development of SFML stagnant?
- Why does it feel like there have been no major improvements for almost a decade?
- Who decides what should be worked on?
- How does someone apply to be part of the team that decides the fate of SFML?

I want to see SFML transition to C++17 and become a modern, useful and popular library.
Yes, I am volunteering to do the work. But I don't want to send a PR that's going to be left untouched for 7 years.

How do we get the ball rolling?

This is my proposal:
1. I'll create a branch for SFML 3.x, which is going to be C++17-only.
2. I'll start making some basic changes (e.g. adding move operations for `sf::Shader` and similar classes), and create PRs towards that branch.
3. Have the SFML team review the changes and get consensus as we go along. Don't aim for perfection. Don't aim to have a perfect plan right from the beginning. Move fast and break things.
4. Get a few major changes done (e.g. the entire codebase uses move semantics), and ask for community guidance and feedback.
5. Rinse and repeat.

Shall we?

14

SFML projects / Open Hexagon - now released on Steam!

« on: November 12, 2021, 12:16:56 am »

Hey folks! I remember posting about one of my first SFML projects, Open Hexagon, about 6-7 years ago. I kept working on it (with the occasional year-long pause), until it finally reached a state where I felt proud to release it on Steam.

Open Hexagon is a "spiritual successor" to Super Hexagon, a popular indie game that was created by Terry Cavanagh back in 2012. The basic concept is quite simple: you are a small triangle, and you need to avoid the incoming obstacles by spinning around the center of the screen. Note that Terry Cavanagh fully endorses the project!

http://www.youtube.com/watch?v=06y7mEsAMHM

Open Hexagon expands upon this simple mechanic by adding features such as a 180° swap move, curving walls, and more. However, the most important thing is that Open Hexagon features a powerful Lua scripting system, allowing creative people to create their own levels. I've seen incredible creations, ranging from brand new games implemented as a Open Hexagon level, to "Bad Apple!!" being embedded in the game via a matrix of moving walls.

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

The game is written in C++17, and it's completely open-source. The source code is available on GitHub. If you have any question about the game itself or any implementation detail, feel free to ask here on or the official Discord server -- we have a channel dedicated to level development via Lua scripting and a channel dedicated to the development of the C++17 engine.

I also wrote some articles on the game's internals. As an example, check out "vittorioromeo.info: implementing secure leaderboards for my game", explaining the cheat prevention mechanisms I used to implement a fair and competitive online environment.

I sincerely hope you check out the game and enjoy it.

Cheers,
Vittorio

15

SFML projects / [Steam Release] Open Hexagon

« on: July 18, 2020, 02:11:30 am »

Hello folks!

I've recently released my first complete game (powered by SFML) on Steam, Open Hexagon:
https://store.steampowered.com/app/1358090/Open_Hexagon/

Open Hexagon is a fast-paced and adrenaline-inducing paced arcade experience by Vittorio Romeo. Designed for moddability and custom level creation.

https://www.youtube.com/watch?v=TlSJZlQrVJ4

While it might look like just a clone of Super Hexagon on the surface, it is far from that. Other than brand new gameplay features such as a 180° swap and curving walls, Open Hexagon was completely designed with modding and customization in mind.

Users can create custom levels using Lua scripts, and I have seen some fans creating some absolutely mind-blowing levels that push the engine to its boundaries. I've also had fans thank me for getting them into programming, and that has been an amazing feeling.

The history of this game is quite interesting. It started as a clone of Super Hexagon about 7 years ago, and it was one of my first C++ projects. Over time it developed a community of fans who started creating amazing custom levels, and enjoyed competing with each other for the highest scores. I've worked on the game for a few years in the past, adding features that distinguish it from the original, and making it more and more unique.

After a long hiatus, I've returned to the community and I have started working on Open Hexagon again. The last few months' efforts resulted in a Steam release, with many improvements and new features.

Despite the Steam release, Open Hexagon is still available for free as open-source (and always will be): https://github.com/SuperV1234/SSVOpenHexagon/

Hope you enjoy the game, and let me know if you have any question! ❤️