Polishing  a game to commercial quality requires quite some additional work compared to where many hobby games are considered finished.

And these days you face the competition of thousand of game developers (and teams), many quite skilled. It's not so easy to come up with something that realy will sell.

These days I'm actually happy if I get some response to my projects, and they aren't ignored altogether. I doubt I could sell anything that attracts so little interest even if free.

Few people are used to see planets from space, so whatever looks cool and believable will be good

Very nice indeed. A small idea: make the land less specular than the water, that uses to look better.

If gameSleep isn't much bigger than the actual time spent in your code, you start to notice the different run speeds. You should sleep for (time consumed - time between frames) instead of a fixed time, to get closer to a constant speed. If the difference becomes negative you have a performance problem.

Sometimes I use delegates to implement the painting. Then I just set the right painter delegate to the display panel.

Sometimes I've been using the CardLayout.

Sometimes I've been just replacing JPanels (remove old + add new ) with different content.

And I've been using flags like you ... all of them worked well in the right situation.

If someone loads your applet it's in their browser/jar file cache anyways. Even if you protect the jar file from direct linking, it won't help much.

- Fixed a rare ArrayIndexOutOfBounds exception which could stop the game
- Added more explosion sound variations
- Ship-enemy collisions trigger a sound cascade now

Download r11, 23kb:

http://www.java-gaming.org/user-generated-content/members/132627/vks-shooter-study-r11.jar

Edit: forgot it again ...

- Use the cursor keys to move the ship
- Press ctrl to shoot

You just fight for the high score in the current versions. Hits from enemy fire and collisions lower your score, your kills raise it. Bigger enemies have more armor points but give more points, too.

Since a while I've been working on the idea of a little sidescrolling shooter with all content procedurally generated.

http://www.java-gaming.org/topics/procedural-shooter-concept-study/28678/view.html

The progress on the graphics side was fairly quick, sound took a little longer. And since I'm a sillybugger you've got harmonic explosions now and can try to play little tunes by shooting the right enemies at the right time I think I'll call it "The Harmonic Shooter".



I have no real idea how well the latest version with sound included will run on other PCs. I assume all the content generation can be heavy on the CPU at times although it runs quite smooth on my PC. And I was told that Java sound is quite bad, so there might lurk more problems.

But for your enjoyment, "The Harmonic Shooter", r10 (23kb):

http://www.java-gaming.org/user-generated-content/members/132627/vks-shooter-study-r10.jar

Suddenly, a voice yells over the bridge, "Commander, they've learned to shoot back!"

(But luckily they are bad at aiming ...)



New in r9:

- explosions aren't so heavy on the CPU anymore
- enemies shoot
- less mines

At the moment hits from enemy bullets just lower the score. It's just to see that the hits are correctly processed and to give the player a little incentive to avoid bullets.

Download (19kb):

http://www.java-gaming.org/user-generated-content/members/132627/vks-shooter-study-r9.jar


Thanks

I hope the change for the explosions helps a bit. Otherwise I must reconsider my image blending routines.

Good to know. I found another problem in the collision checks enemy vs. ship, but I must spend more time on investigations. The ship vs. tunnel check is very coarse, too, but I'm confident that I can improve that once I spend a bit more time on it (currently only tests ship bounding box vs. tunnel spikes).

Screenshot featuring the "winged ship" design improvements:



@RobinB:

It's intended that bullets can pass through walls, the enemies can do that too I'm not quite decided if it's a good or bad feature, but I think it can stay for the moment.

The enemy flight pattern will be improved, but it will need a bit of time to include splines and set up other grouping patterns than just lines.

I'll investigate the explosions. On my system they start quite immediately when a enemey is destroyed. What is the exact problem, are explosions delayed after an enemy is destroyed, or is the animation going too slow?

A little update:

The current state of the project includes one one new feature: random mines, which block the tunnel. Well, also a slightly improved bullet vs. enemy check, not sure if it will make much of a difference though.

Download (r8, 18kb):

http://www.java-gaming.org/user-generated-content/members/132627/vks-shooter-study-r8.jar


Some day I want to try that with other genres too, particularly with adventure or role playing games. But those are quite complex, so I wanted to start my studies with something easy. But it helps to make games which one can play oneself as developer, and still be surprised now and then

The structure matches our own galaxy. The short central bar, and the branching arms match quite well. There sure are enough barred spiral galaxies which looks similar, but bets are that this is a visualization of our own galaxy.

Thank you for the feedback! The collision detection runs in a low priority thread, maybe that was a bad decision. What kind of CPU does your computer have?

When I have time to work on it some more I want to add a shield meter, and collisions will reduce the shield levels. Also I think some enemies should shoot back.

Thanks again

Edit:

Quick release for testing:

- Collision detection now run as high priority thread
- Winged ships got more interesting designs now

Download (18kb):

http://www.java-gaming.org/user-generated-content/members/132627/vks-shooter-study-r7.jar

PS: Big ships have more armor points. You need to hit them several times till they explode.

While playtesting I found a stupid bug - ghost ships could collide with your ship and kill your score. Now there are now more ghost ships. And the dendril ships became a bit more colorful.

I've also changed the tunnel looks a bit. It's still the weakest of all graphical structures in the demo, I think, but a bit better now than before.



Download (18k):
http://www.java-gaming.org/user-generated-content/members/132627/vks-shooter-study-r6.jar

I would, but I'm not the right one to work a longer while on a single project. I already have four projects here in the WIP section and two or three others down in the Java2D section, and I jump between them every few days or weeks.

I manged to produce some presentable explosions effects.



Overall I'm quite pleased with the progress on this project. It's been easier than I thought, and the procedural content seems quite alright for the time spent on the routines. Actually it's quite fun to fly along and watch the enemy shapes and the explosion colors. Particlarly the dendril ships have a huge variety of shapes.

Download (18k):

http://www.java-gaming.org/user-generated-content/members/132627/vks-shooter-study-r5.jar

Next will be to create procedural sounds. I've no experiences with that so far, but I hope that the combination of envelopes with waveforms of different frequencies will create something usable.

Welcome to the forum

Looks very good. I've been a big fan of the Dungeon Keeper concept and now and then pondered to make my own remake. But it seemed too big and I was always busy with other ideas so I never tried.

Your demo looks very advanced already, so I guess there is a good chance that it will succeed. Good luck with the project

Attack of the dendril ships!



Made a new ship shape generator, did some more playtesting.

Download (17k):

http://www.java-gaming.org/user-generated-content/members/132627/vks-shooter-study-r4.jar

New:

- ship-tunnel collision checks
- ship-enemy collision checks
- slightly smoothed ship movement
- a little ship drive effect animation

Score calculation:

- Destroyed enemies give points, the harder they are to destroy the more points you get
- Score penalty if your ship collides with an enemy
- Score penalty if your ship collides with the tunnel

Download (17k)

http://www.java-gaming.org/user-generated-content/members/132627/vks-shooter-study-r3.jar

Bullets can hit and kill enemies now. Once I have a bit of free time again, I'll add scoring, also collisions between the ship and tunnel walls as well as between the ship and enemies.

Download (18k):

http://www.java-gaming.org/user-generated-content/members/132627/vks-shooter-study-r2.jar

Feels a bit like an arcade shooter already  ...

Actual screensize != preferred window size, at least for me. So I decided to ask here.

Since the vectorball idea died so quickly, I was pondering what I could do with the codebase. So I picked up another idea of mine, to make a sidescrolling shooter with all content procedurally generated. All images and sounds in the game will be created by the program itself, from random numbers and some graphics shuffling. And bits and bytes and magic. Or so



At the moment I have a starfield sort of background, an untextured tunnel shape, and one way to create enemy ships. No collision detection yet, no scoring and no game ... I'll work on that someday soon. Also I want to more variance in enemy ship designs, and a tunnel rock texture, and decorations.

For a brief moment I thought it might be something for the Java4k contest, but the jar file is 17k if I strip the debug info, and have it compressed, that seems to be way too big to try and shrink it into 4k. So I'll let that be, although I think that a shooter with procedural content generation might be a project candidate for the Java4k contest.

Download (22k):

http://www.java-gaming.org/user-generated-content/members/132627/vks-shooter-study-r1.jar

You can move the ship, shoot (but not hit anything), explore the tunnel and watch random enemy designs. More to come ...

Edit: use the cursor keys to move, ctrl to shoot. And yes it goes leftwards, there are enough rightwards scrolling shooters

And you hear a distant voice murmuring, "Begin, and I'll grant you three lives!"

http://www.java-gaming.org/user-generated-content/members/132627/brickdoh-0-60rc.jar

I wanted to give players a better chance to see the later levels. Three chances actually. I don't know how well it works though, it's been a quite quick hack. Above link is a release candidate, and seemed to work alright in my tests. Score calculation has changed a bit, too, to make up for the extra lives.

Reading this, in my head develops the impression that Java 8 will not be a Java anymore as we know it, but a critter of new and old functionality with a confusing mix of options. Just like C++ is a beast, offering so many ways to do things, and requiring so much knowledge to use it well.

I like(d) Java because it was pretty straightforward from the offered concepts.

There were primitive types, and objects.

Now they add a third category, Lambdas. It seems this will have deep impact, because APIs that were built on the old two concepts now don't look well anymore, and there is a force to change them. So not only the core language changes, but there is force to change all the libraries too.

I'm very careful with changes. This case looks like a change which has almost unpredictable impact on the future development of Java.

Stability is also virtue for a language. Call me old-school, late adopter, and living in someones basement. My opinion at this point of the discussion is that lambdas have the capability to change Java very thoroughly, and I feel sad about losing a simple and still mighty object oriented language this way

Brickdoh v0.59 got a more precise timer, which should help to smooth movement, and a small  fix for paddle-ball spin handling. Also there is one more level, and a new brick type waiting for you.



Download:

http://sourceforge.net/projects/brickdoh/files/Brickdoh_v0.59/

Edit: If you tried it, please let me know if it's too easy or too hard, or if some level has a problem. With more and more levels added it becomes really difficult for me to playtest the whole level sequence. Level 3 is the first one with special features.

I see. Thanks for the wikipedia link  

Lately I've been experiemneting a lot with multithreading, and at the moment I think that functional code is much better suited for concurrency than object oriented code. So I assume that features from functional languages will indeed help there.

In the recent years I see more and more games with umlauts used in their names. My experience is that few english speakers can pronounce them, so I feel puzzled why they are used in games names. Is it just the funny shape of the characters, or is there another reason?

And how to pronounce "Brütal Legend", "Ünembra" or "Isotröma (Tesseract 2)"?
(the latter two are from the WIP forum)

I thought the term is more commonly known, but it seems it isn't. Vectorballs were a funny thing to make graphics demos. They are mentioned in several old demos and you can also google the term and will find results from the demo scene.

A little mention:

http://en.wikipedia.org/wiki/Unreal_%28demo%29

Also:
http://www.youtube.com/watch?v=VkaVDczP8c4

And:
http://www.youtube.com/watch?v=Wv-zCyB0hiI

Basically vectorballs are glorified particles. They have been used because they are very simple to compute and efficient to move. In the demos they were used to shape more complex objects out of points, and have funky looking transitions between the shapes.

I guess it's once again a technique of the past, and I missed the point when it was superseeded with something better.

I have been thinking about this for a while, but I couldn't make up my mind, so I'll ask: Which use cases are there in which anonymous inner classes are actually a performance problem? I'm using them for listeners and such, and it never was a bottleneck or even a minor problem for my programs.

Maybe you can show me some examples where anonymous inner classes are a performance problem and how lambdas will help there.

I don't think the coding is the problem. Some pixel artwork doesn't scale well, and some games become easier if you can see more of the map (assuming the images don't get enlarged, so that more fit into the window). But I agree, there are many programs (not only games) which needlessly use fixed window sizes.

My question was more or less to see what will fit conveniently onto someones screen. Some of my programs remember the last window size when you closed them, some don't. For those which don't I wanted to have some sensible default.