So you call this a game engine, but aren't developing a scripting engine. In that case, is this more of a framework and specific library full of abstracts and interfaces for the programmer to build on top of?
I'm also interested as to how exactly the "game flow" is structured, because from what I can tell it's just really one big main loop for game events. Relatedly, do you have any details on the programming interface? Do you have a good example of project flow yet (say, for one spell card), or is it too early to tell?
How are hitboxes calculated? Would it be feasible to roll your own?
I pretty much consider an engine as something that does the core functionality and has a lot of utility for making a game that the engine focuses on, but I guess a framework is also a good naming.
And no, it's not all abstracts and interfaces, a ton is actually ready to be implemented at all times, but specifics, like bosses, spellcards, stages, etc, need to be filled in.
Sure, I have a game flow schedule here for Sekibanki's stage.
In case you're not familiar with Java, any kind of object that's not inside the same object can only be referenced if it's an object with final.
Adding final though means you also can't replace that object anymore, however an object can contain other references to objects that can be changed.
That's what the SaveableObject is for, it's just an object containing another object, but only the SaveableObject is made final so it can be referenced in other objects, but the content can still be changed:
http://hastebin.com/zososayuha.javaThis is basically my idea, a thread that runs on the background that waits for specific conditions to move on, and it should usually go into specific classes for Stages, Bosses, etc to not overcrowd the game flow scheme.
That is also the reason why for most things you need to use the built in scheduler to execute stuff on the main thread, since it will cause errors otherwise.
For hitboxes I actually have something pretty cool, I wrote a code which turns a texture into a hitbox by a specification, like this:
Polygon poly = HitboxUtil.makeHitboxFromSprite(texture, new HitboxSpecification()
{
public boolean isHitbox(Color color, int x, int y)
{
// For most bullet I use a standard specification, anything with a transparancy under 40% is not hitbox, so:
return color.a > 0.4f;
}
});Then the hitboxes are bound together with a sprite in a so called HitboxSprite, which basically makes any changes to the sprite uniform, so if you scale a sprite up twice, the hitbox will as well.
Together with that, there's also offsets for the hitbox, so ie. if you want to have a hitbox that's half the size of the sprite, you can set the scale offset to 0.5f and it will stay that way.
By default, all touhou bullets I added are half the hitbox of the sprite. And that seems to be a pretty good number.
So someone else has made a Danmaku engine in Java too, huh. ^^
Good luck with your project! ^^
I can relate to your problem with Danmakufu. I just couldn't work properly with it, either. ^^;
Funny thing is, just a few weeks ago I ported my own Danmaku engine from Slick to LibGDX because Slick was causing more and more problems (like projectiles vanishing for no apparent reason, and my FPS counter being stuck on 63).
So, from what I understand, (the core mechanics of) your engine is finished?
I've got a coupe of questions for you, since I'm interested how you implemented some things compared to how I did. ^^
? Is your program real time based (causing frame loss with less frames) or frame based (causing slow down with less frames)?
? How do you implement the animations for a character, or any kind of object in general?
? How/ where do you implement the shot types/ patterns that enemies (or even other objects) shoot? Can you reuse your patterns for different objects (like, can you reuse an enemy's pattern for another kind of enemy, or even the player)?
? How exactly work your hitboxes? What kind of hitboxes do you have? (What I mean is, I have a standard hitbox for general hits, a graze hitbox, a physical hitbox for enemies to determine whether a player was too close to them (this one is smaller than the general hitbox) and an item collect box for the player)
? And while on the topic of hitboxes, how does your hit detection work?
? How do you do your Screen Handling, Stage Handling (in case you treat your stages not as different screens)? Do you have some kind of Wave Handling as well?
? How many projectiles can you create without your framerate dropping? (if you have ever tested this) (With my engine, it's about 18000 for one type of projectile and about 5000 for multiple kinds (getting this fixed is the next thing I do. It's a problem coming from not working with libGDX from the start))
? How do you handle conversations? Where do you store the conversations? (I'm using XML files to hold the conversations, for example)
? Lastly, how do you load and store your sprites? Do you use the libGDX loading structure?
I'm asking this specifically because I'm not used to libGDX that much yet, and back when I was using Slick I didn't understand their loading and resource storing structure at all, because of which I wrote my own thing completely. xD;
Well, I did use their methods to load the sprites into my game, but I wrote my own classes for storing the resources so I could load and unload them for each Stage specifically.
I think those are all the questions I had. ^^
Sorry for this amount of programming specific questions, but I'm just really curious. ^^
Yeah, the core of my project for gameplay is done, bosses, bullets, backgrounds, etc, but there's undoubtedly stuff I missed.
I also ported this project from Slick to LibGDX, what a coincidence, yeah it was bringing in a lot of problems, and libgdx has a lot more options, and is "harder, but a lot more", which I like.
To answer your questions:
1. Frame based, I probably would have preferred a real time based or something that scales with the frame rate, but this was the default for LibGDX.
2. Using LibGDX's Animation object. I actually have a class that can read frames from an image (ie.
http://i.imgur.com/PbSwWsc.png) and transform it into an Animation object with:
int chunkHeight = 160; // This is how high one frame is
int chunkWidth = 128; // This is how wide one frame is
Texture sprite = new Texture("anm.png"); // This is the one I posted above
Animation idle = ImageSplitter.getAnimationFromSprite(sprite, chunkHeight, chunkWidth, 0.2F, 1,2,3,4); // Reads the 4 frames, 0.2f is the time between frames.
Animation left = ImageSplitter.getAnimationFromSprite(sprite, chunkHeight, chunkWidth, 0.2F, 5,6,7,8); // Reads frames 5 to 8
Animation right = ImageSplitter.getAnimationFromSprite(sprite, chunkHeight, chunkWidth, 0.2F, 5,6,7,8); // Also frames 5 to 8, but this is going to get mirrored.
for(TextureRegion reg : left.getKeyFrames())
{
reg.flip(true, false); // Mirror it over y
}
Animation special = ImageSplitter.getAnimationFromSprite(sprite, chunkHeight, chunkWidth, 10F, 9,10,11,12,12,12,12,11,10,9); // Special uses a different timer so it starts at the beginning of the animation, that's why the frame difference is 10f.
special.setPlayMode(PlayMode.NORMAL);
3. I already answered this above, however on boss hitboxes, they have a simple rectangle 'hit' hitbox, where bullets can land, usually the bounds of the boss sprite.
And they also have a 'player' hitbox, where the player dies, this is a rectangle hitbox that's right in the middle of the boss, and it's a lot smaller, this is an image that shows them:
http://i.imgur.com/sbXCUs4.png (Also showing the new effects I've been working on)
4. Hit detection works by using a polygon overlap method, every object that needs collision has a hitbox, I'm not sure how it works but LibGDX has a method for it.
5. A menu will have to be composed the same way as the game has to be composed, a stage consists of StageObjects, that have a simple x, y, draw method, and an update method, for a menu you'd make them take input and change states by keys and have a background object.
Though, I haven't worked yet on menu's, so once I get to those I'll have more utilities and classes to make easy menu's
Stages use a game flow scheme that I showed above, it works for pretty much everything
you can make waves by using the tick counter in the main class, and spell card objects have a counter themselves.
You can also make use of any objects getTicksAlive() method.
6. I've not really tried that yet, but I've had cards with up to 10000 bullets while trying working fine, but it depends on how good you pc is I reckon.
7. I don't have anything for conversations yet, but I assume I will make a framework for it, which should be pretty easy.
I'll probably make it load the conversation by making a class for it and use JSON to load it, of course users are free to input whatever they like.
8. I use LibGDX's interal loading, however every object has a list of Disposable objects, which get disposed once the entity gets deleted, and you just don't add any static objects to the disposable list.
This works fine for me right now, and doesn't cause for any lag, so I won't need to change that if it's not causing any lag, if it does, I'll reckon I need to load stuff over time before hand.
And yeah, Slicks system didn't really make sense to me either, considering I was new to game design from scratch, and I couldn't even gasp the fact you had to dispose stuff since it wasn't mentioned anywhere, probably why my first demo had a lot of RAM issues, though LibGDX has made it a lot easier since it's so "raw", I guess, you really work with openGL and a lot of stuff.
For bullet textures, I keep those loaded in memory at all times, since they could practically be spawned at any time. (Also because making a hitbox of a texture takes quite a bit of time to do with such an amount of bullet textures, at least if you make them dynamically like I do).
For the rest, like bosses, they load their textures on spawn, since that is pretty much instantly (And no boss should really be spawning when anything is going on), but you can also pre-load them by just not adding them to the active objects list.
Hi, I'm the one on Reddit who recommended you to post here.
Good luck on the project, I've been wanting to play the Touhou All Stars since I saw the original video.
Thanks so much man, I really feel like I'll get a lot more help from talking here than on the Touhou subreddit.
I'll be sure that you'll enjoy the all stars game.
