Slick Forums

I have played Perfect Cherry Blossom, but I no longer have my copy of it.
I love these games though.

Thanks.

@rustycusak
Good to hear from a fan of the series. I wont claim to be doing anything as amazing as PCB but I hope that the game will end up having some worth in its own little way.

Well it's been about a month so I should probably post something.

The Current State
I got SavedGames working again, using the SavedGame class Vince pointed out. Thanks again Vince.
Got combo's set up, so now when you perform certain key presses it changed the bullets you fire.
About this time I got fed up with hard coding the stage data, and started working on defining stages externally using YAML. Right now I am about 3/4 through a system that will turn a YAML file into a playable stage. In theory anyone would be able to define their own stages, but the code for the stage definitions is pretty embarrassing; so I have no plans to support that.

The Future and BEYOND!!
Looks like I will be using a web based high score system for high scores, which should fix the other crashing error.
I am still looking for decent sound effects, and remixing the mp3's into XM files is also a really slow process. Which leaves me at a bit of a loss for sound.
I would like to replace the borrowed graphics, unfortunately good cheap pixel art is a rare commodity and looking at it from the adage "Good, Cheap, Fast; pick two" means it's a looooooong way of.


Well I hope to have an new release posted sometime. Don't have nearly as much time to work on it as I would like, but every time I get a post it motivates me to work on it more.

_________________
If at first quads don't succeed tri tri again.

Still plunking away at this between work and watching Canada take the gold in hockey :D. But I'm having trouble deciding how I want bullet patterns to function. I have something working now, but it's clunky.
There are two ways to make bullet patterns at the moment. When the level script is created you can either:

Tell an enemy to use a set of generic parametrized patterns (radial, waves burst etc):
-need to remember a lot of names (essentially a wide API)
-quick and easy to define
-some patterns cannot be defined.

Tell an enemy to use a default pattern and slap a script on each bullet fired to describe how it acts.
-fewer commands (smaller API)
-defining the script needed to describe patterns is more difficult
-can define virtually any pattern that can be conceived.


There are solutions like bulletML, but to me this is a lot like the solution that my second method already provides. It's a little clumsy to use and involves too much work. On the plus side it is somewhat standardized for describing bullet patterns.

At the moment I'm trying to think about how I would actually like to define these bullet patterns.
The goals are:
-Assuming "Pattern" is the top level class; should require as few sub classes as possible; 0 would be ideal
-Uses a small number of simple declarations that can be aggregated together to make complex patterns.
-High parametrization to make scripting implementation simpler.

I've kind of lost perspective on the problem though, so I'd really like to see other peoples ideas on how they would attempt to describe bullet patterns, or words of wisdom from people who have tried something similar before. Doesn't matter if the definitions are in java, XML or pseudo-code, I would really like to know what other peoples' thoughts are.

_________________
If at first quads don't succeed tri tri again.

Hello,

I am currently working on un shooter that I want to be bullet hell at some point.

But honestly, I have difficulties to manage my bullets. How it is possible to fill the screen with bullets without having bad frame rate.

It is a desktop game.

Well before you start doing things to "improve" the frame rate make sure you actually need to first. What I mean is; program it in a way that is simplest for you to understand. Then see if it's fast enough. If it is, your done. If it does turn out to be too slow then you have some work to do.

It also really depends on what is slowing things down.
Is it collision detection?
If this is the case you can start playing with various broad phased collision techniques. I found that using a grid with cell roughly twice the size of my entities worked best.
First for every entity you determine what cell it is in. Then for player check for collisions for all the cells that it is in (max 4). Typically this will cut the number of collision checks down by ~75% though cell size does matter.
Next check if the players bullets have shot any Enemies. Do not iterate over the player bullets though. Rather iterate over the enemies and for each enemy check it for collisions against all the player bullets that share any of its cells. The reason for this is that there are typically fewer enemies than player bullets. So you can get away with fewer collision checks.


Maybe you are spending a lot of time allocating new objects.
If this is the case you can make your own object pool and recycle bullets rather than having them get garbage collected and constructed all the time. This can be tricky though, as you are essentially managing your own memory. Make sure that object allocation really is slowing you down before you do this. In my case I say about a 12% frame rate increase based on 1000 entities on screen, but I'm not sure if it was really worth the pain.

The other thing that could be slowing it down is just plain render time. There are a number of things that can be used to speed this up but its tricky because you could just as easily end up slowing things down. Again make sure that the render cycle is where all the speed is going and then prepare for a lot of trial and error.

*Numbers are estimates based off of qualitative observations checked against the default JDK profiler, and change in frame-rate. This was not a scientific study. Your millage may vary.

_________________
If at first quads don't succeed tri tri again.