Meanwhile i was searching something on google, i found a thing which lets you generate a random game idea.

Go here: http://www.streamingcolour.com/blog/game-idea-generator/

and generate one!

---

Games made for Game Idea Generator Madness!

Hey all! In the last few weeks I've revived a project I was posting about here a year ago:
Stream of Pretentiousness

It's daily vignettes about my life (interactive non-fiction, if you will). I'm calling this Season 2 because last year I was making them in Twine, and this time I'm experimenting with other open-source engines for making hypertext stories. So yeah!

I've recently updated my <<Replace>> Macro Set to version 1.1.5. Normally I don't make auxiliary posts explaining changes to my macros, but I think this deserves one due to the number of nuanced fixes that this attends to.

<<endinsertion>> fixed
This particular end tag had a nasty and embarrassing bug - the text "n>>" was left behind after it, unless you instead substituted <<endinsert>> for it (which was also a bug, as it shouldn't work like that). That's fixed, and <<insertion>> spans may be used with their proper end tags again.

<<revise>>: "end" option fixed
Consider this code:

<<revision "B">>The balcony is vacant.<<becomes>>The balcony is occupied by a party of ghosts.<<endrevision>>
Maybe you should <<revise B "look closely" end>>.

The "end" in the <<revise>> macro is supposed to make it so that the text "look around" remains after you click to the end of the revision... but until now, it's been broken. Now that's fixed. While making some Twine games of my own, I discovered (or rediscovered) that this particular idiom is actually a valuable usage case, so I deeply regret that it's been unavailable for so long.

<<hoverreplace>> <<gains>> behaviour fixed

<<gains>> hasn't quite worked with <<hoverreplace>> since its inception. Consider this code:

<<hoverreplace>>First bit<<gains>> and next bit<<endhoverreplace>>

If you moused over the first bit (causing the next bit to appear), but did not ever touch the next bit, it wouldn't disappear when you moused off it. This is now fixed.

<<hoverreplace>> rapid mouse behaviour fixed
For awhile, <<hoverreplace>> has been more than a little flaky when rapidly moving the mouse on and off the element. I've tried a few fixes in the past to alleviate this, but this one looks to be much better, and testing shows it to be robust.

A note about <<hoverreplace>>
One thing that is still not yet fixed is the problem caused when the initial state is larger than the end state. Consider this code:

<<hoverreplace>>[img[large image]]<<gains>>Small text<<endhoverreplace>>

This code is still buggy because as soon as you mouseover the large image, it disappears, leaving the small text behind, and thus your pointer is no longer "over" the hoverreplace structure. I may still be able to fix this in the future, but generally, in this particular situation you should resort to <<mousereplace>>.

Questions
Q: Why did it take you 9 months to write the fixes for these bugs?
A: At the time, my attention had been single-mindedly focused on both my day job, preparing Twine 1.4.2, and developing Twine 2. I apologise sincerely for this unsightly delay in basic maintenance, and will try to be less badly negligent in the future.

This videogame is two-player only.

Player 1. WASD to move
Player 2. Arrow Keys to move

A man finds a treasure map which lead him to the middle of the sea.
He takes the dive down to an underwater wonderland.

Use down, left and right arrow keys to swim around and avoid the deadly shark fishes and jellyfishes.

You'll also need to keep an eye on your lung pressure, do not let it go too much over 100, or you gonna be sleeping with the treasure. To do this you'll need to chill out in the shallower water first (not that you aren't pretty much forced to because I got carried away with the rng again.)

Also about Kung Fu 3 which I've been endlessly blabbering about:

I'm gonna try and give myself a kick in the butt (I've barely made enough progress that counts this far), and put up a dev diary for it sometime next week in hopes that I will actually someday work towards finishing it instead of working in random twenty minute farts couple times a week.
I'll also drop lots of other shit in there from time to time, like an updated version of the second one for starters, followed by some of my non-GTW-wrecks from past years and maybe a bit more "history" so you dudes understand what's going on (I never introduced myself :( ).

Despite my lack of updates, only some of my lack of progress is because of Elden Ring. I can't help it. The game lets me marry a living doll. I have a type.

That said, I'm 100% going to miss the deadline but I don't care because I've been enjoying working on this game. My most recent efforts have been focusing on making a vehicle controller for the hoverbike thing the protagonist is going to be jetting around on and lemme tell ya, it has been an ordeal.[i] My first attempts basically just involved using invisible wheel colliders and having those provide all the functionality I needed, but it turns out that Unity's wheel colliders are kinda... awful for that? Figuring out what their specific dampening values and everything need to be is also an arduous process because they're all expecting ranges I'm expected to just guess I suppose.

My next solution was to use raycasts and physics forces. Figuring that the best way to ensure the bike from flipping would be to have some spread out forces, I put four of them around the bike and lowered the center of mass so that it was always inclined to stay upright. This [i]kinda worked, but it meant that applying forces at positions for steering had to have special offsets, and that resulted in weird torque behaviours that were a nightmare to diagnose and even more of a nightmare to code.

Not fun.

Then, one night, as I was tossing and turning in bed, I awoke in a start. Not because of inspiration, but because I'm prone to nightmares. To work myself down from the post-nightmare anxiety, I started thinking of new ways to get this to work, and I finally settled on a hybrid solution of an idea I had the night before and a new one as well.

Instead of using four raycasts, I use two, front and back. Next, I lock the bike's rotation along the z-axis and only ever change that with direct access from code to make the steering look "cool" by giving it a bit of a banking effect. Then, on top of all this, I added some dampening physics to it all. The front raycast gets a low dampening value to make it extra bouncy, and the rear raycast gets a high one to make it more rigid. In a way, it sorta recreates the suspension of a motorcycle! Neat!

After that, I added some extra quality of life stuff. Instead of immediately losing forward thrust in the air, I made it so that if you spend too much time in the air (about half a second), you start to have the amount of thrust the accelerator gives you drop to half its strength, meaning you can't fly around forever. I also added some functionality to make the bike automatically balance to face the horizon after a second or so in the air to help keep the player from flipping around all over the place. In the end, after far too many lines of code (both included, commented out, and deleted) I finally have something I think I really enjoy zipping around on, which is all I could really ever ask for!

Motion sickness warning on this video, by the way. I'm still mucking about with the camera system.
https://www.youtube.com/watch?v=IIZVrT5BFNA

I just think it's neat!

This is a minimally interactive randomly generated narrative experience. It's slightly inspired by old first-person role-playing games. It's also kind of dumb. I think you need java installed to play it. Enjoy!

Apparently I was up until about 2:00am whipping my code into shape just so I could share the introductory portions of Alien Zit 2000. I've been having a blast drawing and singing and playing the jaw harp.

Download the Alien Zit 2000 teaser! You may also want to peek inside the data directory for a special MP3 surprise.

Use z to shoot, arrows to move. Kill the core.

This is a four player game. One of the player is the murderer (they must kill half of the citizens), and the rest are cops (they must hunt down the murderer). Press a button to know if you're the murderer! Press another button to kill people!

Mostly made over a coffee high at 2 am. Some things are still a bit choppy (killing people is imprecise as fuck). Also my first game!