Maidens of the Kaleidoscope
~Hakurei Shrine~ => Rika and Nitori's Garage Experiments => Topic started by: Raninf on August 21, 2010, 09:01:15 PM
-
I would've bumped my other topic, but it recommended me to start a new topic in the reply form since my other topic was "older than 14 days," so uh... yeah.
Okay, so after a while of working on this er... engine test, I decided to stop this and start designing a real game. The engine test ended up to be a very easy game* that works with few** bullets.
INFO, SCREENSHOTS, AND DOWNLOAD (http://raninf.co.cc/index.php?p=8)
The screenshots don't reveal that much, so you best play for yourself. 4? stages of boring bullet hell.
-
My gawd the game runs at 60fps on my slow comp, and it's not like the effects and bullets are lacking anything either. Not sure if there will be a noticable slowdown when backgrounds get implemented but this is looking really good :3
The only reason why this game isn't getting attention is because not many people would know how much work is needed to get it playable to this point in C++
(playable? damn this game is way beyond that, it's almost a demo!)
[edit] Also do share your danmaku code :3
-
omygawd I totally overlooked that whole C++ thing *downloads*
its remarkable that you've managed to understand and USE C++ to a point where you made an actual entertaining game! good for you!
-
Playing it just based on it being done in C++ is putting way too much praise into it. It's nice and different that it is, but I think I would rather get attention for having a good game than for it being done on a REAL LANGUAGE LOL. I praise the work done to make an engine, but it isn't like C++ is some godlike difficult thing to use. I would be insulted if that were the only thing people commented on.
That said, will play later.
-
The danmaku in the game is really good and feels unique and I like the effects and how you use them. Although sometimes the player shot just has epileptic effects on me and I can't tell what shots are coming from the player and the enemy sometimes. And to me this game seems really hard. Maybe it's just me but Normal was kicking my ass.
-
Playing it just based on it being done in C++ is putting way too much praise into it. It's nice and different that it is, but I think I would rather get attention for having a good game than for it being done on a REAL LANGUAGE Ha ha, old chap!. I praise the work done to make an engine, but it isn't like C++ is some godlike difficult thing to use. I would be insulted if that were the only thing people commented on.
That said, will play later.
I suppose you're right (you probably have more experience in C++ than me =P). As a game, this is nowhere near as good as most of the other stuff in this forum here. Rather than aiming to make something enjoyable, I was trying to make a functional engine that can make more than 10 bullets a minute.
-
:( well... I'm not sure what to say... I'm use to Windows continues or the Vista eras continues... But this game isn't fun, I can die so many times and it doesn't make a difference... it's really hard to kill the "minions" without bombs (until you have 350+ power)...
I'm not sure... This is a decent Touhou danmaku game but.... it's not fun, because the death are less noticable and stuff...
Normal is like Hard... but that could be me.
V-V I don't mean to complain... I'm just not use to this kinda stuff...
-
I suppose you're right (you probably have more experience in C++ than me =P). As a game, this is nowhere near as good as most of the other stuff in this forum here. Rather than aiming to make something enjoyable, I was trying to make a functional engine that can make more than 10 bullets a minute.
Nono, I definitely don't have more experience. It's great that you could make an engine in C++. I'm just saying you probably want people to be impressed by the finished product itself, not bow down to you because you're using C++. I was talking more to Benny and LFS.
-
The patterns are alright (save for the red ovals on stage 3(4?) that I can't dodge for the life of me).
I'd suggest lowering the enemy's health. Drastically. It just took wayyyyy too long for me to want to see what else the game had in store. If not lowering the enemy's health, up the shot power. Better yet, add a second shot type - a typically ReimuB forward-focus instead of the homing one, so it's easier to kill enemies that linger on the screen only very briefly. Consider that in most Touhou games, every enemy that comes on the screen ends up dead. Only about 20% of yours do!
-
...a good game than for it being done on a REAL LANGUAGE
...impressed by the finished product itself, not bow down to you because you're using C++. I was talking more to Benny and LFS.
eh? i thought i said i was impressed by the game O_o
- game runs fast on slow comp
- effects aren't lacking anything
- game looks pretty good
- i wanted to see his danmaku code
If it doesn't seem like that then too bad :P
you prolly got confused on the part where i said the game isn't getting enough attention
Though seriously, i wanna see how he did his danmaku (comparative+learning purposes)
-
:( well... I'm not sure what to say... I'm use to Windows continues or the Vista eras continues... But this game isn't fun, I can die so many times and it doesn't make a difference... it's really hard to kill the "minions" without bombs (until you have 350+ power)...
I suppose I was working more on difficulty than on playability. The "minions" were supposed to have enough HP to be able to shoot, but still be killed if targeted specifically. It's not very Touhou-esque, so I guess it's my bad.
I'm not sure... This is a decent Touhou danmaku game but.... it's not fun, because the death are less noticable and stuff...
Hm, I always thought that the bright bullet disappearance animation was enough. Then again, lots of the other objects clear the bullets as well. Maybe a sound effect would help, and some more invincibility time, instead of just clearing the bullets and moving the player back to its(his?) start position.
V-V I don't mean to complain... I'm just not use to this kinda stuff...
Thanks for your input. Although comments like, "Good job," are nice, comments telling me what I've done wrong are great, too.
The patterns are alright (save for the red ovals on stage 3(4?) that I can't dodge for the life of me).
After playing Double Spoiler, I've noticed that that part of the stage looks quite a lot like one of the spells in level 10.
I'd suggest lowering the enemy's health. Drastically. It just took wayyyyy too long for me to want to see what else the game had in store. If not lowering the enemy's health, up the shot power. Better yet, add a second shot type - a typically ReimuB forward-focus instead of the homing one, so it's easier to kill enemies that linger on the screen only very briefly. Consider that in most Touhou games, every enemy that comes on the screen ends up dead. Only about 20% of yours do!
Along with what I said above, I admit that I had been stalling on implementing another shot-type and ended up not implementing it at all. Upon making this game, I can safely say that designing bosses is far easier than designing stages (which, in this game, is just a compilation of very weak bosses). That's why
- The enemies have very advanced attacks compared to the ones from Touhou
- The boss is more like a boss than stages are like stages
- The enemies have too much HP
I'll be sure to lower the enemy HP and enemy shot difficulty in my next project.
omygawd I totally overlooked that whole C++ thing *downloads*
its remarkable that you've managed to understand and USE C++ to a point where you made an actual entertaining game! good for you!
Well, as Drake said, it's not extremely difficult to make a game in C++. If you have a solid engine down and know how games work, you should be able to make one easily (Game Maker helps in this). The hardest part might as well just be making the engine or getting the mathematical formulas for moving or collision detection.
The danmaku in the game is really good and feels unique and I like the effects and how you use them. Although sometimes the player shot just has epileptic effects on me and I can't tell what shots are coming from the player and the enemy sometimes.
I'll try to make the shots less visible in my next project (or possibly a revision to this one?). It certainly does look like the homing bullets are a bit too bright.
And to me this game seems really hard. Maybe it's just me but Normal was kicking my ass.
That's my bad. I had too many overpowered enemies and decided that beauty of Danmaku was more important than playability of Danmaku.
eh? i thought i said i was impressed by the game O_o
- game runs fast on slow comp
- effects aren't lacking anything
- game looks pretty good
- i wanted to see his danmaku code
- You can thank SFML for that. :)
- You can thank SFML for that. :)
- Thanks for bringing that up. I might have focused a bit too much on the graphics and difficulty, and completely forgot about playability (then again, this is an engine test, haha).
- You could PM me and tell me which parts you want, or if you want an outline of what the engine looks like.
Not sure if there will be a noticeable slowdown when backgrounds get implemented but this is looking really good :3
Unfortunately, SFML Graphics is a 2D graphics library. I'll have to read up on OpenGL (or DirectX, but SFML Window works with OpenGL well) if I want to implement 3D backgrounds.
This is quite a long post; Sorry if it forced you to scroll down. Is there a hide BBcode?
-
Nah I don't think it's worth the effort to make 3d backgrounds when people are too busy watching the bullets ^^
also sent PM :3
-
I might take a look at this, but judging from the screenshots, it appears that your interface could use a little attention. Likely the biggest issue is the font. You are using a rather standard font that does nothing at all to add any kind of flavor to the game. It basically looks like a standard program with a shmup in the other window. Naturally gameplay is important, but spend a little time coming up with an interface that feels right and it might enhance the gameplay. The rest of the graphics could use a little bit of attention too maybe, but the interface is the part which really feels lacking.
And that's about as much as I can offer before actually playing the game itself. Hopefully I can get around to giving it a shot later.
-
I might take a look at this, but judging from the screenshots, it appears that your interface could use a little attention. Likely the biggest issue is the font. You are using a rather standard font that does nothing at all to add any kind of flavor to the game. It basically looks like a standard program with a shmup in the other window. Naturally gameplay is important, but spend a little time coming up with an interface that feels right and it might enhance the gameplay. The rest of the graphics could use a little bit of attention too maybe, but the interface is the part which really feels lacking.
Thanks for your comment. I guess I was simply too lazy to get a different font--This is actually SFML's default font--for this program. It was more intended to be an engine test, although it ended up being an engine test with my bullet patterns, haha. Would you like to suggest a font that would seem suitable for something like this?
-
I hope that danmaku isn't hard-coded!
You should look at BulletML (http://www.asahi-net.or.jp/~cs8k-cyu/bulletml/index_e.html) for danmaku coding, which is reasonably easy to implement (there are Java and C++ reference implementations, I believe).
Personally, though, I'm not a fan of it and I'd embed Python into the application, but embedding the Python interpreter in C/C++ is pretty damn OH MY GOD WHAT IS THIS and using Boost::Python means you get fun, 30+ line template errors!
-
I hope that danmaku isn't hard-coded!
The suggestions below look pretty cool, but could I ask why hard-coding isn't such a good idea?
You should look at BulletML (http://www.asahi-net.or.jp/~cs8k-cyu/bulletml/index_e.html) for danmaku coding, which is reasonably easy to implement (there are Java and C++ reference implementations, I believe).
After Googling some of this, this doesn't look that bad. If I ever get to the point where I need to store bullet (enemy?) data into files, I'll look into this (or create a crappy parser for bullet (enemy?) data file reading).
Personally, though, I'm not a fan of it and I'd embed Python into the application, but embedding the Python interpreter in C/C++ is pretty damn OH MY GOD WHAT IS THIS and using Boost::Python means you get fun, 30+ line template errors!
I'll look into this too. I've heard that Python's easy to learn, but I've never gone and actually read a tutorial somewhere, haha.
-
I couldn't give you anything specific, you may even want to make a custom font or something depending on where you want to go with the game's style. I played through the game but it doesn't really help much in getting the sense of style you're looking for, in fact it feels kinda empty. Just experiment and see what has the feel you're looking for.
As for the gameplay, you do need to make it possible to kill those enemies. Part of the motivation for shooting the enemies in the stage is to get rid of some of them before they spew out bullet patterns. Halfway through the level I gave up and didn't even bother shooting at them. I also got bored with each attack pattern loooong before they moved on to the next one.
-
The suggestions below look pretty cool, but could I ask why hard-coding isn't such a good idea?
Well, generally speaking, you want your program to be extensible and portable, especially with languages like C++, which really isn't all that platform-independent or consistently implemented across compilers (both mainstream compilers, GNU C++ and MSVC++, have a truckload of non-standard extensions which you may/may not be using).
You don't have to recompile your program every single time you update the danmaku it if it's soft-coded. Hell, you could even dynamically reload danmaku at runtime (carefully), eliminating the need to even restart your program. Additionally, it would work across platforms (Linux/Windows/Mac OS X) and you would only need to update the danmaku scripts rather than the entire executable.
If you insist on coding your danmaku in C++, you could make them dynamically loadable libraries (dll/so/dylib files) which you can load at runtime, which offer similar benefits of runtime reloading (though much more trickier, due to the fact you might get a lot of null pointers upon unloading) and easier updating, but not so much in regards to portability. You'd also have to look into the dynamic loading aspects of operating systems (libdl for Linux/Mac OS X, LoadLibrary and friends on Windows, though libltdl takes some of that hassle away).
You could embed Lua too, which I hear is child's play compared to embedding Python, which is something like doing the twelve labors of Heracles six times over. But I'm not a fan of Lua, mostly because of the fact that lists start at 1.
-
You don't have to recompile your program every single time you update the danmaku it if it's soft-coded. Hell, you could even dynamically reload danmaku at runtime (carefully), eliminating the need to even restart your program.
Over our discussion in PMs, it did seem like his danmaku was hard coded (and mine was too xD)
Im glad this thread was made, thanks Raninf and rfw :3
might get a lot of null pointers
the first thing i thought was Merupo ξ・∀・）
-
You know, I'd be rather interested in seeing your code. Personally, I gave up on C++ a while ago, finding it unproductive and silly (I'm sure there are optimization whores out there who'd like to flame me to death), but nonetheless, I'd like to see how your underlying implementation of danmaku works.
-
You don't have to recompile your program every single time you update the danmaku it if it's soft-coded. Hell, you could even dynamically reload danmaku at runtime (carefully), eliminating the need to even restart your program. Additionally, it would work across platforms (Linux/Windows/Mac OS X) and you would only need to update the danmaku scripts rather than the entire executable.
My main concern is that I've heard that interpreting is quite slow (from my own experiences with Game Maker, although that might be just GM's implementation). Maybe once I get a completely solid engine down, I'll try soft-coding. Also, I hadn't thought about making this cross-platform. I'm pretty sure it's cross-platform, using SFML, but there's lots of room for error.
If you insist on coding your danmaku in C++, you could make them dynamically loadable libraries (dll/so/dylib files) which you can load at runtime, which offer similar benefits of runtime reloading (though much more trickier, due to the fact you might get a lot of null pointers upon unloading) and easier updating, but not so much in regards to portability. You'd also have to look into the dynamic loading aspects of operating systems (libdl for Linux/Mac OS X, LoadLibrary and friends on Windows, though libltdl takes some of that hassle away).
It appears I still have a lot to learn in the subject of (game) programming. I always found hard-coding to be easier (though that's because I started with Game Maker) unless I needed to load simple things, like platforming stages or similar, not scripts.
You could embed Lua too, which I hear is child's play compared to embedding Python, which is something like doing the twelve labors of Heracles six times over. But I'm not a fan of Lua, mostly because of the fact that lists start at 1.
I've heard of Lua before, but never understood how it worked because I haven't studied it much. I'll look into it and see if it would be convenient for this.
You know, I'd be rather interested in seeing your code. Personally, I gave up on C++ a while ago, finding it unproductive and silly (I'm sure there are optimization whores out there who'd like to flame me to death), but nonetheless, I'd like to see how your underlying implementation of danmaku works.
Well, it's pretty much just a combination of Game Maker and Danmakufu. I borrowed the general purpose functions from Game Maker (like instance_create) and I borrowed Danmakufu's ways of making bullets (like a renamed version of SetShotDataA).
I couldn't give you anything specific, you may even want to make a custom font or something depending on where you want to go with the game's style. I played through the game but it doesn't really help much in getting the sense of style you're looking for, in fact it feels kinda empty. Just experiment and see what has the feel you're looking for.
Ah, okay. This er... engine test was more for showing some compiled bullet patterns than to make a game, haha. It could be called a generic script thread for Danmakufu (minus the Danmakufu part), I guess.
As for the gameplay, you do need to make it possible to kill those enemies. Part of the motivation for shooting the enemies in the stage is to get rid of some of them before they spew out bullet patterns. Halfway through the level I gave up and didn't even bother shooting at them.
I'm certainly going to avoid this mistake next time. My approach in level design wasn't the best (or anywhere near the best), it seems.
I also got bored with each attack pattern loooong before they moved on to the next one.
For the bosses? Would I need to decrease the bosses' health, or are the bosses' shots just too bland?
-
Interpretation is by no means slow, as, once all the data is loaded into memory, you can access it like anything else and, as long as your underlying implementation is relatively optimized, then it should be more or less fine.
Game Maker's programming model is probably one of the worst things you could base your code off - why would you use instance_create, when you have constructor functions for classes, e.g. Bullet::Bullet? Have you looked into making it object-oriented, or is it already object-oriented?
-
Game Maker's programming model is probably one of the worst things you could base your code off - why would you use instance_create, when you have constructor functions for classes, e.g. Bullet::Bullet? Have you looked into making it object-oriented, or is it already object-oriented?
It is already object oriented. I've never figured out how to have constructors with different arguments for the child classes. It would always be
ChildObject(float xx, float xy) : Object(xx, xy) { create(); };
in the object's header file. Object(xx, xy) would set the position, some sprite data, etc, while create() would set variables specific to the class. I could call push_back(new ChildObject(...)) directly instead of an instance_create, but I'm not sure what to do from there, unless it's possible to do
ChildObject(float xx, float xy, float anotherparameter) : Object(xx, xy) { create(); /* Stuff related to anotherparameter here */ }
-
Can't you simply overload the class's constructor after inheritance?
For instance (I'm using structs because whatever):
struct MyObject
{
MyObject(int param1, int param2)
{
// code goes here
}
}
struct MyObject2 : MyObject
{
MyObject2(int param1, int param2)
: MyObject(param1, param2)
{
// here is a constructor that supports the same interface as MyObject, if needed.
}
MyObject2(int param1, int param2, int param3)
: MyObject(param1, param2)
{
// here's a constructor that extends the MyObject constructor with a third parameter
// do some initialization stuff with param3 here
}
}
That way you can construct objects with whatever parameters are required without the need for a generic constructor (or whatever the hell create_instance is).
Also, I hadn't thought about making this cross-platform. I'm pretty sure it's cross-platform, using SFML, but there's lots of room for error.
I'd forgotten to comment on this, but the idea of cross-platform compatibility is what Java enthusiasts like to call WORA - write once, run anywhere, meaning that a code can be compiled once and then subsequently run on any platform without recompilation. While this is pretty impossible with C++ as there are different executable formats on every operating system (PE on Windows, ELF on Linux and Mach-O on Mac OS X), you can eliminate some of it by soft-coding and distributing a runtime for every operating system.
Unfortunately, SFML Graphics is a 2D graphics library. I'll have to read up on OpenGL (or DirectX, but SFML Window works with OpenGL well) if I want to implement 3D backgrounds.
Just some advice on this - 3D is a big step up from 2D. While 2D is nothing more than vectors and maybe a few affine transformations, 3D is matrix and quaternion hell (or heaven, depending on how you feel about the subject), and most likely you would need to port the 2D portions of your game to use 3D textured quads, as mixing non-hardware-accelerated 2D and hardware-accelerated 3D can cause severe performance drops due to the fact you need to read the data from the GPU back to the CPU, process it there, and push it back onto the GPU - this pipeline is slow because it was never intended.
Also, I was taking a look at your internals and wondering (with reasons why I don't think it's a good idea):
- why you have 3 different variables that store number of bombs used that are dynamically allocated (no need to use the heap when you have the stack, also OMFSM WTF 3 VARIABLES),
- why you have a dynamically allocated variable for lives (likewise), and,
- why the checking for overflow of the power variable is done every game update, rather than every increment (inefficient).
Here's some fun with your internals:
(http://dl.dropbox.com/u/2880866/thumb_lolinternals.png) (http://dl.dropbox.com/u/2880866/lolinternals.png)
-
Ah, okay. This er... engine test was more for showing some compiled bullet patterns than to make a game, haha. It could be called a generic script thread for Danmakufu (minus the Danmakufu part), I guess.
I'm certainly going to avoid this mistake next time. My approach in level design wasn't the best (or anywhere near the best), it seems.
For the bosses? Would I need to decrease the bosses' health, or are the bosses' shots just too bland?
Personally, I think I'd go for a narrow font, but nothing too fancy (please don't use Papyrus). That might suffice for now. As for the bosses, it was a little bit of both really. Most spells that last that long in the Touhou games usually change midspell (and I don't recall nonspells ever taking that long, but I use Marisa, so..). Additionally, most of the spells I played before quitting were just simple streaming two-way bullets; although there was occasionally something interesting, I had too much time to get used to these spells.