Between the Bubbles - a game concept

Hello,


I was thinking some time about non-violent concept for thinBASIC game, and I was also tempted to make game which is controlled via single button (changed in V2).

I have made spaceships killing each other, robots killing each other and many more, but I wanted to create something more "meditative" - more slow paced, with no destruction or shooting involved.

I also wanted to try approach, when the core gameplay will be prepared before any media (graphics or sound) will be integrated.

Simply to see, if it has some potential.


So - I started working on new game called "Between the Bubbles".

The current form is really a very early work :D

Playful aspects
The bubbles are source of energy, but also a source of direction change - what you need more at the moment, energy, or current orientation?

The bubbles can also be used as "taxi" - high energy bubbles move faster and can get you from one place to another.

Player can burst the bubles in case he is not careful enough.

How to try the game?
Simply download the BetweenTheBubblesV5 ZIP archive, extract and run BetweenTheBubbles.tBasic.

The player is represented by the bug, and the bubbles by the circles.

Currently, you may explore the movement, how to survive longest, how to collect most energy. Otherwise, you cannot "win" the game yet.

Development
The game is developed on GitHub:
https://github.com/petrSchreiber/BetweenTheBubbles-tb

...but the builds, discussion about the design and technical topics stays safely here, at thinBasic forum.

DirectuX kindly joined the development :drink:

Have fun and let me know, if it runs okay on your PCs :)
Petr

Attachment 10026Attachment 10023Attachment 10024Attachment 10025

Petr, this is excellent!
I like the idea, it makes me think of a mix between drift (1993) Attachment 10022 and Osmos.

It runs okay on my PC. :)

Thank you very much for trying :) I think it will be fun!

Coding something in TBGL after longer time helped me to open eyes and see how inconsistent the design is :p I need to clean it up a bit...


Petr

Thank you Petr
the 2D games and demos have appealing . i have spent countless hours before many many years trying to solve the Dos game called ssa or ancient empires https://www.youtube.com/watch?v=pN_Ces6y1pg .
after a while i saw a kid reached the final stage in which the bonus price is to fly over the pyramids (i think so). that was with the computer XT with CPU 8088 . the same situation with prince of persia version 1 for Dos and even i still remember the cheat "princemegahit" to have super power.
now i'm too old.

Wow Petr great concept!
And quite complicated to go on, not easy at all.

My mind started to think about improvements :D:D
First of all timing to count time you are able to resist. Even though game concept is random ... timing will challenge to resist more.

Source code if fully using OOP concepts :wizard:

Added 4 images to your first post.
I cannot stop playing :)
...and thinking

Imagine also the game in 3D with bubbles being planets and triangle a space ship trusting in 3D with zooming on the path.
Stop stop stop :)

Experimented with more than 100 bubbles sized up to 250 of energy
Attachment 10028

:)

This is fun read, thanks all!

Eros - your idea with goal is intersecting with my evil plans.

I have the following goal scenarios in my mind:
- "try to survive at least X seconds" - quite good to master the basic principle
- "try to reach X level of energy" - ho ho hoo, things get complicated!
- "try to survive AND catch a golden fish, moving through the scene" - now you need to care both about you and object in scene
- "try to survive AND catch a golden fish, while avoiding enemies!" - this is the toughest I could come up with

I will try to work on these next week and once ready, at least something, I will update the first post.


Petr

Hi,
as it comes to ideas, here's my (little) contribution :
playability may benefit from

• an in-situ visual feedback of the energy stock
• use of easing instead of infinite acceleration / deceleration
• variability in the rotation (it's always counter-clockwise and slow , it's a bit frustrating)

and gameplay from perks to collect by example for a laser pointer effect, an harpoon to catch bubbles, a bubble-magnet :p ...

Quote:

---

Originally Posted by ErosOlmi

My mind started to think about improvements :D:D
First of all timing to count time you are able to resist. Even though game concept is random ... timing will challenge to resist more.

---

timing... and an hall of fame :evil5:

DirectuX,

thanks a lot for the ideas, I like them all.

Currently, the triangle becomes green once it has 100% energy, but the red-green shift is very subtle and unobservable.

I have some ideas I will try to implement.

Could you please explain more about the "easing"? I am not sure I follow/understand precisely.


Petr

Hi,

"easing" as here : https://easings.net/

In (real) life, changes are progressive, thereby, games implementing this behaviour are easier on the eye.

Examples : full speed is attained after acceleration, stop is preceded by deceleration (unless you hit a wall...:shock31:).
One can extend this to bubble drainage (can speed up quickly) or power consumption (can slow down at the very end), you can stick and bounce a little when touching the bubble, and so forth.

for 100% power, it can also be a flare burst, a little flashing, and a sound, but I meant something more granular, especially toward the low end of the gauge :shock26:
maybe a flagella that shorten ?

Hi DirectuX,

thanks a lot for the explanations!

I uploaded V2, it can be retrieved from the first post of this thread.

Features added?
- attempt at easening
- player is no longer represented by arrow, but by a water bug
- bubbles are little bit prettier
- you can both thrust and slightly turn
- the bug has energy indicator on his body
- if two bubbles meet each other, they merge
- you will get the survived time information in the game over screen, hehe

Of course, more to do. Like the high scores screen. I need to check the thinBasic game scores module for that ;)

Thanks a lot for the ideas - while not all of them came in V2, I have them all on the list.


Petr

I uploaded V3, it can be retrieved from the first post of this thread.

It (hopefully) fixes a crash which can occur with some GPU drivers.

Otherwise identical to V2 - if you did not download V2, you can download V3 directly :)


Petr

Caution!

There is a bug in this game !

Hi Petr,

played :) pretty much improved indeed ! and sure it looks prettier than v1.


Feedback :
Features added?

- attempt at easening visible

- player is no longer represented by arrow, but by a water bug kawaii ;)

- bubbles are little bit prettier made me think what about prettier (also darker) background ?

- you can both thrust and slightly turn I was not able to perceive both at the same time
- the bug has energy indicator on his body :)

- if two bubbles meet each other, they merge that's cool! Note: when the bug is attached to a bubble and merging occurs, surprisingly the bug gets dropped.
- you will get the survived time information in the game over screen, hehe yeah, unfortunately you can't survive for long, bubbles keep disappearing from screen and at some point there's no more bubbles :shock18:

Hi DirectuX,

thanks a lot for the observations - I will definitelly look at the mystery of disappearing bubbles, I think it is related to fact they used to flow right in the V1 and now they go in all directions.

As for the concurrent change of direction and thrust, it is currently separated in order to support the "struggle" feeling, however... I do realize it is a bit awkward.


Petr

Quote:

---

Originally Posted by Petr Schreiber

As for the concurrent change of direction and thrust, it is currently separated in order to support the "struggle" feeling, however... I do realize it is a bit awkward.

---

I liked more the feeling when the change of direction was correlated with the bubble drainage, I think it lacked only control over the direction (clockwise or ccw) and the speed of rotation (tell me if I'm not clear)
(sort of a 2-button game : [MAINTAIN][T]=thrust , [PRESS][R]=toggle direction and [MAINTAIN][R]=accelerate rotation , what's your opinion on this ?)

Concerning the count of bubbles, (I didn't check in the code) do you set an amount of energy at the beginning and it remains constant all long ( bug's energy storage + remaining energy in the bubbles = total energy of the screen ?) In that case, difficulty level is directly linked to the total energy.

Quote:

---

Originally Posted by Petr Schreiber

I will definitelly look at the mystery of disappearing bubbles, I think it is related to fact they used to flow right in the V1 and now they go in all directions.

---

In function "MakeElementsFlow" you do a four-position check for the bug. For the bubbles, instead there is an inline calculation that is ok only if it goes too far at right (yes, like in the V1). Why not have a delayed "CheckPos" function that you can apply to all elements at once, like your futures "golden fish" :fishing:, "enemies to avoid" and stuff... ?

Hi DirectuX,

again, very valuable feedback. You made a very good point with the constant total amount of energy, to make the results comparable.

I discovered few TBGL design issues I would like to address before I continue. It is interesting to see TBGL with fresh eyes.

Stay tuned :) And thank you, sincerely, very much for to the point feedback :drink:


Petr

V4 attached to the first post :)

What is new?

• constant total amount of energy for bubbles at the start of the game
• corrected boundary checking, which should solve the effect of disappearing bubbles
• fixed the bug drop
• while bubble merging is preserved, one more behaviour added, hehehe!

Have fun,
Petr

P.S. Together with Eros, we start to discover interesting path to extend TBGL - this is one of the reasons for the delay, but definitely worth it.

Hi,

some feedback below :

while bubble merging is preserved, one more behaviour added, hehehe! — nice :)
fixed the bug drop — confirmed here
corrected boundary checking, which should solve the effect of disappearing bubbles — similar (rare) misbehaviour : while sticking to a bubble that goes off screen, the bug can disappear totally (not long).
constant total amount of energy for bubbles at the start of the game — see V4 picture below

Attachment 10067

I may be wrong, it seems to me that there is no bubble creation to compensate the bug's energy consumption (release) , so total energy seems not constant.

Gameplay feedback : today, playing had the inverse of the wanted effect : quite stressing. So, I tried with little bigger bubbles , (just size, not energy) and it's more relaxing, more slow paced: that's because by default the bubbles are to far from each other according to the energy consumption (static and moving) of the bug and vice versa. From my point of view, it has too much to count on chance.

Hi DirectuX,

thanks again for detailed review. Now I see I understood the original "constant" idea wrong.

Currently, at the beginning of each round, the total energy of bubbles is always the same. It did not occur to me to re-create new ones to keep the level the same, that is very interesting concept.

Aaand - yes, it is quite challenging now, right? I will try to think about it, I think maybe the less "desperate" turning could help this.

Thanks a lot again for your opinions, all very valuable!


Petr

Good evening,

significant update, V5, attached to the first post.

What is new? A lot of things :)

For example:
- the screen is no longer fixed, I introduce the concept of "infinite bubbleverse" with chasing camera, which I hope Eros will appreciate, as he suggested it earlier :drink:
- in order to make the game less stressful, player has initial energy, bubbles are of higher capacity
- bubbles are also reborn once expired
- to give some challenge though, I added the feature which makes the bubbles pop when you approach them at speed - careful!

Give it a try and let me know, thanks a lot.


Petr

Challenging :heat:

While 'game-development' :beta: you can calculate/display the bug's range of action :

Ø _{from bug} = f (energy _{stored by bug} ; energy consumption rate _{while bug moving})

then, measure the number N of bubbles within the Ø range during gameplay (take Ø_bubble into account)

Observe N = f (Time) . It is a direct indicator of the difficulty level that you can then adjust for each of your Game Levels. :comp4:

Edit:
Since you changed bubble's energy in V5 ,
you could also measure the energy E_{reachable bubbles} and observe E_{reachable bubbles} = f (Time) , then adjust difficulty with:

• bubble Ø vs Energy ratio (other idea : can have different bubbles (color...) , certain more attractive than other)
• Energy consumption rate for movement
• Constant total Energy of the world

Hi Petr,
V5 is a lot easier !:)
too easy in fact : while just waiting in place, the bug turns full green ! :D

• infinite bubbleverse :good:

• did you think of any background ? (now, as the camera moves, we need a landmark) (hoping for parallax :blush:)

• for bubble merging vs bouncing, do you check against bubble energy ? I didn't see merging this time and you just said that bubbles have more energy now in V5.

• bubble pops :good:

• seems easier to move / turn , just a feeling ?

• do you plan seamless level up or levels ?

Hi DirectuX,

thank you. The difficulty is now in opposite extreme, as you say. I made a phone call yesterday, then returned to PC and bug was still alive :)

Speaking of visuals, I don't want the game to look vectorish as it is now, I have an idea about quite tasty look.

In order to add sense of depth, I want to have "fake" depth of field, with the game plane being in focus, while other planes blurred. It should create that paralax feeling.
That would mean that you could see bubbles deeper than the bug is, just with out of focus look.
As an icing on the cake, I had ideas about bubbles coming from the deep, with transition from being completely blurred to sharp, could look nice.

I would also like organic look of the bug, nice fonts and... everything :)

But first - I need the way to ballance the difficulty and add all core game elements.

Speaking of game structure, I would like smooth transition between the levels. That means, no screen blinks, but as you flow in the inifinite bubbleverse, at certain point things will happen.

All of this structured to chapters/levels, with checkpoint and autosave at these. And yes, there is even a story in the works :)

But these are the far plans - did not mention sound design yet, but it will be also important. I need to focus now on the core gameplay elements for a while, I do not have it under control yet.


Petr

:excited:

All these plans are appealing !

Quote:

---

Originally Posted by Petr Schreiber

But first - I need the way to ballance the difficulty and add all core game elements.

---

About this part, what do think of the range of action ?

My apologies I did not commented it more,

but that is because I am already processing it in background thread - I will definitely have a look at it!


Petr

Quote:

---

Originally Posted by DirectuX

• for bubble merging vs bouncing, do you check against bubble energy ? I didn't see merging this time and you just said that bubbles have more energy now in V5.

---

Hi Petr,
I had a look at this code part, and boosting the MaxBubbleEnergy to 450 lead to more variety in bubble sizes, but that's not the point of this post : why do you scatter the game parameters across your code ? Is there a reason you don't use the INI module by example ?

It would make tweaking the params easier, right?

I am also considering cAppConfig, but not decided yet. Point taken!

DirectuX, would you like to join development, if I would put it on GitHub?


Petr

Quote:

---

Originally Posted by Petr Schreiber

It would make tweaking the params easier, right?

I am also considering cAppConfig, but not decided yet. Point taken!

---

Right :)

in my humble opinion, XML is for machines, TXT or INI suits better for humans,
of course cAppConfig could be of better use for savegames. Do you plan protection against cheating (also regarding hall of fame)?

Quote:

---

Originally Posted by Petr Schreiber

DirectuX, would you like to join development, if I would put it on GitHub?

---

I'll PM you about this.

For bug's movement speed, I wanted to suggest this shape of easing :

Attachment 10082

which is closer to natural movement, and more aesthetic :

https://www.youtube.com/embed/mCd6zIuACLw


holding the key longer would "charge" the "rush" with more energy and control the final distance.

Good point,

currently, the bug behaves more like a motor boat - trying to gain speed, holding it, then slowly loosing.


Petr

I added the current (V5) source code to GitHub:
https://github.com/petrSchreiber/BetweenTheBubbles-tb

This will allow collaborative development on source code, while discussion and "builds" will continue to be published here.

Big thanks to DirectuX for joining the project:drink:


Petr

As we continue with the project, Sebastian discovered GitHub shows thinBASIC scripts as binary files, not showing the diff.

Why is that?
tbasic and tbasicu are not extensions known to gitHub, and therefore gitHub relies on its instincts - as the file starts with some "weird chars" - BOM - Byte Order Mark - it treats it as binary.

How can you fix that?
You can add .gitattributes file with the following content:

Code:

---

*.tbasic eol=crlf diff
*.tbasicu eol=crlf diff

---

This basically tells, that "*.tbasic" and "*.tbasicu" are eligible for showing the difference.


Petr

After deep investigation, it seems the Between the Bubbles project helped discover minor issue in ThinAIR.

I re-created the game repo here, without the history of confused changes:
https://github.com/petrSchreiber/BetweenTheBubbles-tb


Petr

What will be the next steps in development?

There are multiple directions which can be pursued - Gameplay, Storyline, Sound and Graphics.

In the nearest time frame, I would like to play with the ideas Sebastian mentioned, for example, easing of the movement and ballancing the difficulty.

In general, I think there are the following areas to solve in the long term for Gameplay:

1 Gameplay
The game takes place in an infinite bubbleverse, where different kinds of tasks occur at different times of the voyage.

I kind of liked how Left 4 Dead 2 has a concept of game director - a mechanism which was varying gameplay based on how well the players are doing.

But before we get to these ambitious visions, it would be nice to have the building blocks for such high level system - and by these block I mean core gameplay systems.

The game director would be then dosing the gameplay systems in thoughtful (read: "fun and challenging") order, and with appropriate dosing (timeboxing).

Back to those building blocks.

1.1 "Bubbledrinker"
This is basically the current mode, when player needs to survive by carefully choosing path through the bubbles.

As Sebastian suggested this mode now seriously needs a difficulty ballancing mechanism - that should be related both to overall difficulty of actions and to the length of the session, after which the session would be considered "won" and game can be transitioned to another type of gameplay.

Action points:
- difficulty ballancing mechanism

1.2 "Collector"
This mode is layer over Bubbledrinker, while it adds the need to collect items spread in the world, ideally all visible or their location/distance indicated somehow.

This mode would be limited by number/type of items to collect or by time.

Action points:
- add ability to layer game modes
- implement collector mode
- difficulty ballancing mechanism

1.3 "Hunter and prey"
This mode is layer over Bubbledrinker and/or Collector, which adds traps and enemies to the game.

There would be multiple types of enemies, which could be creatively supplied in varying amount and diversity.

Enemy A - "deadly touch" - this is passive enemy element, which causes damage to player/enemy on touch.

Enemy B - "angry kid on playground" - this is passive enemy element, which causes damage to environment on touch. Think - destroying items/bubbles in reaction

Enemy C - "grumpy sleeper" - this is passive enemy element, which, once alerted by action in the environment (popped bubble, sound of destroyed items, ...) quickly and lethaly attacks the player

Enemy D - "strong but slow" - this is active enemy element, which pops bubbles on contact and moves towards the player very slowly. Should it ever reach player, it will perform serious damage / instant kill

Enemy E - "wateraptor" - fast water predator, which can eliminated by navigating him to Enemy A


Let me know what do you think.

Petr

I share this 'timing' : consolidate what's existing before implementing new features. So, 1/ finish the easing function (I e-mailed you about hindrance I faced). 2/ balance difficulty. For this, the more malleable way I can think of is to compute a real-time difficulty "score" (remember #23 ?). In the future we can update the scoring by taking account of the number/speed/life points of the "enemies" and such other challenges. Gameplay parameters can then be under control of such score with weightings.

Then, about the long term:
I read about the numerous ideas, from the view point of the player, what are they answering ? Straight response can be : to challenge the player. But why ? Why would the player be motivated to accept the challenge ? We need to identify rewards. (Some of them: Next Level, Extra life, Hidden Level, Skill unlock, Achievements, Hall of fame placement, cut-scene...)

"a mechanism which was varying gameplay based on how well the players are doing." can you pro / cons ?

Those building blocks:
to my eyes they are like the rewards above: new things to discover in the BTB universe. So : flat out!

"There are multiple directions which can be pursued - Gameplay, Storyline, Sound and Graphics."
For clarity, I hope we'll be able to split the project discussion according these themes and sub themes.

Hi Petr,

about the translations:
in the code we have things like :

me.playText.put("[P]lay", 2)

and

tbgl_getWindowKeyOnce(metadata.screenWindow, %VK_P)

how do you prefer we manage the input for actions like " hrát " ?

Good point,

the reason why I went with "Menu [i]tem model" was that I was lazy at the time to implement menu, where you pick items via up/down arrows, confirm via ENTER and go back via ESC.

What do you think about doing it this way? Then it will be translation independent.


Petr

Quote:

---

Originally Posted by Petr Schreiber

Good point,

the reason why I went with "Menu [i]tem model" was that I was lazy at the time to implement menu, where you pick items via up/down arrows, confirm via ENTER and go back via ESC.

What do you think about doing it this way? Then it will be translation independent.


Petr

---

Yes and that will be prepared if we want to manage gamepad as entry.

Hi Petr,

Do you think we can find a nickname for the bug ?

Hi Sebastian,

what about "The Wanderer", "The Pilgrim" :)


Petr

Quote:

---

Originally Posted by Petr Schreiber

Hi Sebastian,

what about "The Wanderer", "The Pilgrim" :)


Petr

---

"A Pilgrim is a Wanderer with a Purpose"

Ok for The Pilgrim :)

Deal :drink:

As a reminder for when it will be time : lasonotheque.org proposes hi quality sounds for free.

Thank you! Very interesting.

In case of need I have also Zoom H2 sound recorder, it is quite nice for environmental audio.


Petr