Between the Bubbles - a game concept

[DirectuX]

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

Screenshot_2019-10-18 GreenSock Docs Easing CustomEase.png

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.

[Petr Schreiber]

Good point,

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


Petr

[Petr Schreiber]

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


Petr

[Petr Schreiber]

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:

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

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


Petr

[Petr Schreiber]

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

[Petr Schreiber]

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

[DirectuX]

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.

[DirectuX]

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 " ?

[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

[DirectuX]

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.