Flukz, the shmup that you can edit yourself

[Yukito]

Hey, ever thought of a shmup where players could create the content of the levels themselves, just like on wikipedia ?
We have just started to create it
It's called Flukz and available here : http://flukz.org

Here is what it looks like when you edit a shmup level :



You can change easily the position of the sprites, their speed, the speed of the fire, etc.
Well, there is still a long long way of work to do before we have all the functionalities of a good shmup, but keep an eye on us. We're going to change the world ... maybe

You can already help us to create new levels. The fun is that they are instantly available to all other users.

[BPzeBanshee]

What kind of support does this have in terms of bullet pattern control?

I don't want to burst your bubble but there's a few things out there already that do this, such as Blast Works and Danmakufu (although the latter requires a bit more work I think). Where I hope your project will shine is bringing the best functionality of the lot into an easy-to-use engine.

[Yukito]

Oh, I see. Interesting. I didn't know these games. In fact, I hardly know anything about existing shmups (or other games). I'm clearly more a developer (of classic applications, not of games) than a gamer. But never mind bursting the bubble. The program is open source, and we're doing it for the fun. Whatever already exists, it will not break our hearts

Currently, bullets and ships have only one pattern. They can only move on a straight line, with some speed. I guess the first thing to do in the next version is to introduce more complex patterns and more control on them.

[BareKnuckleRoo]

In fact, I hardly know anything about existing shmups

Developers that don't also play games have no way of judging how genres have evolved, and thus can't innovate/improve on the genre in their own way. Sine Mora is one of the best examples of a recent game developed by a team that clearly doesn't play games; despite the fact that good modern shmups feature things like customizable control mappings, often a slowdown button for precise movement when using digital controls (an analog stick), automatic rapid fire, etc, we get a game that has an enormous number of basic flaws that represents more of a regression of the genre (broken shot firing rate that encourages constant tapping, only 3 control mappings, score system that encourages neglecting of your special ability, and so on).

I strongly feel that if your goal is developing good games then you should also make an effort to play games somewhat actively, to get an idea on what's out there and add your own improvements and twists to the genre.

oh god it uses the spacebar to shoot, not this again

See, this is why you need to play other stuff. The convention nowadays is the Z button to shoot because it doesn't interfere with the limited button inputs on a lot of modern keyboards (you can't move diagonally up-left when holding space). Or better yet, a simple custom control mapping options screen.

Also extremely buggy. I tried out some "black and white" level, and you die if you move diagonally up-right to the corner of the screen, despite there being no enemies present whatsoever, in fact just moving diagonally in that direction lower down seems to kill you at random, despite not touching any bullets. In fact, you can get this to happen on any level, hold shoot, tap up-right intermittently, explode for no reason.

I'm not sure anyone would want to make levels for this yet, it feels like a very, very early alpha...

[Yukito]

Thank you for the feedback

Ok for the keyboard. I will at least link the Z key to the shoot in the next version.

The random explosions are caused by your own fire. If you go in the same direction as your fire (up), you usually collide with it, and your ship is destroyed. Sure, this is a really annoying behavior. I will work on this before anything else

And I agree completely with your point that I need to play more games if I want to design good ones... I still wonder why I started to code a shmup in the first place. My knowledge of shmups is just some old memories from my childhood. Usually, I am more interested in board games (it's even my current job). But one day, I started to code this shmup, just to kill some spare time in a rainy weekend. And then, I could not stop at all...

[BareKnuckleRoo]

The random explosions are caused by your own fire. If you go in the same direction as your fire (up), you usually collide with it, and your ship is destroyed. Sure, this is a really annoying behavior. I will work on this before anything else

jesus what, it sounds like you even knew about this bug, did you actually release the game in this state knowing you could crash into your own bullets without fixing it first

i have no words

[trap15]

^ my response precisely

[nasty_wolverine]

The random explosions are caused by your own fire. If you go in the same direction as your fire (up), you usually collide with it, and your ship is destroyed.

okay, what gave you that idea in the first place, why would the player shoot himself, doesnt the shots travel faster than the ship...?!?!
I dont even know what to say...

[Udderdude]

I think you'd need to make the in-game editor way easier to use if you expect non-developers to be able to make something with it.

[n0rtygames]

To be honest, this reaction is a little offputting. Yeah, I accept that crashing in to your own bullets is probably one of the worst ideas in a shmup ever - but this guy has done something that's actually really good.

You see, the shmup genre is basically dying out. We all know this. What it's going to take for people to start going loony over shmups is for one of them to have the guts to basically be an "art game" - with something quirky and unique that makes people take it seriously beyond having tate support, or fancy new patterns.

This is precisely the kind of direction we need to be headed in. You can mock Sine Mora all you like, but the fact of the matter is people have heard of this game. They've heard about it, because people like TotalBiscuit did a "WTF IS" about it. People have heard of and played Jamestown. These developers are successful - making games for other people and they are quite widely played. Moreso than highly regarded Doujin games.

Now, killing yourself in a shmup is never going to fly regardless but give the guy a break. If he listens to the vocal minority here - he is never going to make a game that will be widely accepted by casual audiences. There has to be some love for games that don't fit the tried and tested formula of our annual Top 25, y'know?

Euroshmups with all the mechanics that WE hate are getting 4 figure sums off kickstarter projects and then milking them for an extra thousand in a week by offering (and I shit you not) 7 different coloured diffuse textures if the developer hits a stretch goal of +£1000 over his original goal. Something that takes about 10 minutes in photoshop using the CTRL+U colourize tool. £1k? Really?

Taking the piss out of him for making such an obvious mistake is coming across as more than a little mean when there are other things taking the genre further and further away from where we all clearly want it to be in terms of mainstream acceptance. So stop it! It's compromise time. This is the dev forum, not the witch hunt forum. As I said, this sort of feedback and pitchfork mentality is really more than a little offputting.

This however, is a fucking excellent post:

What kind of support does this have in terms of bullet pattern control?

I don't want to burst your bubble but there's a few things out there already that do this, such as Blast Works and Danmakufu (although the latter requires a bit more work I think). Where I hope your project will shine is bringing the best functionality of the lot into an easy-to-use engine.

Nail hit on the head. We already have tools out there to create shmups with little to no coding knowledge. So - your "USP" (unique selling point) has to basically make your game the little big planet of custom shmup making. I have to be able to drool on my mouse and keyboard while making a fun stimulating game. It's an area a lot of people have considered, but have been reluctant to touch because it's actually really daunting and hard. So - good luck, I REALLY hope you achieve this goal. It might inspire some of us to start doing similar if somebody can actually put together a formula for doing this in a gamer friendly fashion.

Good luck dude.

[Yukito]

Thank you for the encouragement, norty. It's ok, I'm happy some players took the time to give it a try and give me feedback . It really helps me to understand what can be improved and what is important.

For example, I knew the bug of the ship that collides with its own fire, but I overlooked it. There is no crash, freeze or other harmful behavior of the program, so I considered it as a minor bug. But from the player perspective, it spoils the game, so it's a major bug.

I'm working on it now. I'll come back soon when it's corrected.

[BareKnuckleRoo]

just pointing out that

Now, killing yourself in a shmup is never going to fly regardless but give the guy a break.

you're defending someone with this level of quality:

For example, I knew the bug of the ship that collides with its own fire, but I overlooked it. There is no crash, freeze or other harmful behavior of the program, so I considered it as a minor bug.

for reference, this is the real issue here

i'm done with this thread

[n0rtygames]

For example, I knew the bug of the ship that collides with its own fire, but I overlooked it. There is no crash, freeze or other harmful behavior of the program, so I considered it as a minor bug. But from the player perspective, it spoils the game, so it's a major bug.

FWIW, I've done some time as a paid games tester for Codemasters. What you're talking about here is a minor bug in the grand scheme of things. It's been reported as crap, you've accepted it's crap - you'll fix it.

There are times in AAA companies where we've had situations where looking at enemies will cause the meshes for their eyeballs to grow every frame, framerate dropping rapidly until the game just crashed. Or vehicles randomly turning upside down or falling through the floor in racing games. Not through doing anything particularly stupid, but just by playing the game normally. The esoteric stuff like forcing yourself off the track and finding breaks in reset lines gets found through psychotic day to day testing.

But there are situations in professional companies where developers deliver builds to testers with shockingly bad oversights - but you know what? 80% of the time these things don't result in a crash. The first stage of testing any game is basically, can you crash it? It doesn't matter if it's the most awful game in the world - so long as it doesn't explode. Once you iron out crashes, then you can start making your game good.

So actually, I have a lot of respect for you - stepping out in to the public with a game that basically has sub standard gameplay and getting people to publically test it as clearly your mindset is "Does my game flow break?" - this is the polar opposite to a lot of developers who start writing games without getting the basic flow down!

Let us know when you're making actual gameplay changes and want feedback on THAT side.

[BPzeBanshee]

I see both sides here but agree with n0rty completely. There's room for improvement without question, and the guy wants to improve on it, which is good.

The initial reply shown by him does give me bad memories of Sine Mora and other projects where the developers have had no clue from start to finish, and I can see why people are keen to jump against that before this also turns out that way.

But at the end of the day I'm not in the business of spooking people off Development with asshole Shmups Chat behaviour, and neither should the rest of you. Bettering of the project through tempered fire, rather than 4chan-like witchhunts, is the way to go.

[Yukito]

Just a message to announce that version 0.3 of Flukz is available : http://flukz.org

The two problems discussed above in this thread are now corrected : the player doesn't collide anymore with his own fire, and the Z key can be used to shoot.

I've also added a score and a life bar at the top-right, like on this screenshot :


When you fail in a level, you can try it again, and your starting score will be the score at the end of the previous level.

There are now 4 wuhu levels and 5 black-and-white levels available. If anyone is interested and want to try for high scores, my current best is 714 at the end of the 4 wuhu levels, and 820 at the end of the 5 black-and-white levels.

[BPzeBanshee]

In its current state (which might I add is considerably better than last release) I get the impression that the engine still seems rather limited compared to other stuff that is available around the place. Even in the G-Wange engine there is a lot of variables that are customisable by the person using the engine to make a game.

Ideally the engine should be versatile enough to allow someone like myself to be able to modify every aspect of the game, including:
- life handling. 99% of good shmups don't use healthbars for players, extend rates, extend items, maximum lives, starting lives
- Game over handling. 99% of good shmups don't restart on the same level, this should be able to be modified
- player shot handling
- player movement speeds
- player shot firerate
- keyboard/joystick customisation of buttons
- more than one background layer
- boss enemies, with healthbars and timeouts and multiple parts if required
- enemy bullet patterns/complex movement
- powerups, or medals, etc

I believe with a bit of thinking of how shmups work, and looking at other game development engines for these type of games, the limitations/flaws in what you have should become quite apparent: and from there the beacon towards bettering this.

[Yukito]

Thank you for the test.
Sure, the core engine still lacks many essential features. I'll let you know when I've made some progress.

[Yukito]

Version 0.4 of Flukz is released : http://flukz.org/

The main innovation of this release is an automatic save of the best scores on the server. A list of the top 20 scores are saved on the server, and displayed at the end of a level when the player dies or completes the game. Even if it doesn't change fundamentally everything, one week after the release, it already seems to have motivated some players to try the game more than just one time.

Game flow is also improved. When a level is finished, the next one is launched automatically. And when you die, you can continue from the beginning of the current level with a loss on the score. I also considered about continuing from the last position that the player reached in the level, but it is clearly more difficult to implement. So, before I try more difficult things, I wanted to ask some advice about what is a good/failed handling of game over and continue.

This new version now supports Ogg/Vorbis files for the sounds and musics, instead of only the Wav format. All the files needed for a level are downloaded on-the-fly the first time the level is played, which can be slow. The Ogg/Vorbis format for the musics will help to accelerate a bit this first loading (loading is fast after the first download, because the files are cached on the computer of the player in the .flukzData folder).

There are now 4 games, each with a different music and atmosphere, for a total of 16 levels. Here is a screenshot of the "lost galaxy" game:



I had no time left to improve the engine itself (for example with bullet patterns), or the level editor. I guess it will be the big work of the next version.

[BPzeBanshee]

Certainly sounds like an improvement in some departments for sure!

So, before I try more difficult things, I wanted to ask some advice about what is a good/failed handling of game over and continue.

Most arcade games continuing process involves either starting immediately where you left off or rebooting the entire stage. Some games do a mix of both, for instance the final stage may only get rebooted on continue but puts you back where you died the rest of the game. Game Over is exactly that, no option to reboot the stage, just the end of your run.

In all of these scenarios the score usually gets reset to 0 along with any associated variables relating to the player (ie bomb count, medal count). I'd highly advise giving some arcade games in MAME a spin, I'm not usually a fan of recommending Cave games as an example, but DoDonPachi and ESPRade are some classic examples there without getting too difficult at the beginning. They should definitely make the parts that Flukz currently lacks stand out more.

[Lord Satori]

If this is a game you can edit yourself, then surely you should be able to edit these settings yourself?