Castlevania Dungeon Forums
The Castlevania Dungeon Forums => Fan Stuff => Topic started by: Dengo vlad tepes on May 04, 2012, 11:23:52 AM
-
well i tried to make my own but my skills weren't good enough to make it ... well anyone ?
-
I'm in the same boat. I have several CV ideas that already have some sprites to show for it. But nothing truly tangible, as I can't code worth s**t. It is extremely frustrating knowing that the ideas are just floating around out there, waiting to be realized and you can do nothing about it even when you've tried your damnedest.
-
Let me be extremely dumb and ask you guys what the hell is a demon castle war...
-
what the hell is a demon castle war...
Something that IGA came up with but never bother to expand upon while he had the chance.
-
Let me be extremely dumb and ask you guys what the hell is a demon castle war...
It's nothing special really, it's just the event in which Dracula was permanently killed by Julius Belmont. An event that has yet to be seen since it's conception in Aria of Sorrow 9 years ago. A event that will most likely not be seen because IGA failed to capitalize on it when he had the chance but instead made side stories that did nothing but add more plot holes that will never get filled.
-
OHhh, I got it! I thought it was about that, but now I'm sure. Thanks.
Yep, Iga made some random plot holes but I can't hate the guy, he made some awesome games in my opinion. Unfortunately not so awesome in the plot side.
I would like to see a fan project out of that, but I don't believe that there will be any so soon. It requires a nice engine and I think that it would feel better to play a metroidvania out of it, cause it fits more Iga's Gba and Ds games. What sucks really is the lack of coders, there are so many sprite artists here that would like to make their own game, but no coders to help at all :/
-
well at first place i though it was much easier it will be more up for GM than my skills but sadly it was 10% up to game maker and 90% to your skills and i'm not that skilled programmer .... sadly
-
Well if you want to compare game maker language with c++, game maker is 10x easier. I code things around in game maker and seriously, everyone can learn, not THAT hard. But you can't also except the program to do all, I see a lot of that in here : ''Oh, c++ gets all the respect" but game maker is also a hard tool if you are just starting to use it. But trust me, if you keep at it you will soon be better!
-
Well if you want to compare game maker language with c++, game maker is 10x easier. I code things around in game maker and seriously, everyone can learn, not THAT hard. But you can't also except the program to do all, I see a lot of that in here : ''Oh, c++ gets all the respect" but game maker is also a hard tool if you are just starting to use it. But trust me, if you keep at it you will soon be better!
I'll start now to start with an engine layout then i'll try to make a new engine my self until i get better and better to make a whole new game
-
Make an engine and then remake an engine.
Because I'm [slowly] working on my engine for other people to use, I'm forced to stick with using object-based collisions rather than tile-collisions. I can say this though: tile-based collisions make platforms and shit so much easier to code. With object-based collisions, you have shit like "a=place_meeting(x,y,obj_ground); if a if a.object_index!=obj_platform{ ". Something like that. Then you end up having parents of parents and that's just a plain headache. With tile-based collisions, it's a simple matter of only needing to check for collisions with platforms and not worrying about the ground (which is handled in a separate script).
Then you start coming up with similar methods for use in object-based collisions. With a tile-based collision, you don't need to check every pixel, just a few select pixels within a specific range. So then why not do the same for object-based collisions? If your sprites are 32 pixels tall and your tiles are 16x16, just check for collisions every 16(+1) pixels. So for a sprite 32px tall or shorter, check for collisions at bbox_top, bbox_bottom, and ceil(mean(bbox_top,bbox_bottom)). You went from checking 16x32 pixels to checking just 12 pixels (3 for each direction).
Yes Inccubus, that's one reason it's taking me so long to release v0.4 for you.
Here's an excerpt exemplifying what I was talking about above. It checks if there's a block in front of the player, then checks if it's a trapdoor (which should be passable), then prohibits movement if the check passes.
var plat_T,plat_M,plat_B;
plat_T=instance_position(x+(x-sprite_get_bbox("bbox_left")-1+max(0,sign(hspd)))*sign(hspd),
sprite_get_bbox("bbox_top"),prt_ground);
plat_M=instance_position(x+(x-sprite_get_bbox("bbox_left")-1+max(0,sign(hspd)))*sign(hspd),
ceil(mean(sprite_get_bbox("bbox_top"),sprite_get_bbox("bbox_bottom"))),prt_ground);
plat_B=instance_position(x+(x-sprite_get_bbox("bbox_left")-1+max(0,sign(hspd)))*sign(hspd),
sprite_get_bbox("bbox_bottom"),prt_ground);
if plat_T
if plat_T.object_index==prt_TrapDoor
plat_T=-1;
if plat_M
if plat_M.object_index==prt_TrapDoor
plat_M=-1;
if plat_B
if plat_B.object_index==prt_TrapDoor
plat_B=-1;
if plat_T || plat_M || plat_B
{collide=true; break;}
-
Make an engine and then remake an engine.
Because I'm [slowly] working on my engine for other people to use, I'm forced to stick with using object-based collisions rather than tile-collisions. I can say this though: tile-based collisions make platforms and shit so much easier to code. With object-based collisions, you have shit like "a=place_meeting(x,y,obj_ground); if a if a.object_index!=obj_platform{ ". Something like that. Then you end up having parents of parents and that's just a plain headache. With tile-based collisions, it's a simple matter of only needing to check for collisions with platforms and not worrying about the ground (which is handled in a separate script).
Then you start coming up with similar methods for use in object-based collisions. With a tile-based collision, you don't need to check every pixel, just a few select pixels within a specific range. So then why not do the same for object-based collisions? If your sprites are 32 pixels tall and your tiles are 16x16, just check for collisions every 16(+1) pixels. So for a sprite 32px tall or shorter, check for collisions at bbox_top, bbox_bottom, and ceil(mean(bbox_top,bbox_bottom)). You went from checking 16x32 pixels to checking just 12 pixels (3 for each direction).
Yes Inccubus, that's one reason it's taking me so long to release v0.4 for you.
Here's an excerpt exemplifying what I was talking about above. It checks if there's a block in front of the player, then checks if it's a trapdoor (which should be passable), then prohibits movement if the check passes.
var plat_T,plat_M,plat_B;
plat_T=instance_position(x+(x-sprite_get_bbox("bbox_left")-1+max(0,sign(hspd)))*sign(hspd),
sprite_get_bbox("bbox_top"),prt_ground);
plat_M=instance_position(x+(x-sprite_get_bbox("bbox_left")-1+max(0,sign(hspd)))*sign(hspd),
ceil(mean(sprite_get_bbox("bbox_top"),sprite_get_bbox("bbox_bottom"))),prt_ground);
plat_B=instance_position(x+(x-sprite_get_bbox("bbox_left")-1+max(0,sign(hspd)))*sign(hspd),
sprite_get_bbox("bbox_bottom"),prt_ground);
if plat_T
if plat_T.object_index==prt_TrapDoor
plat_T=-1;
if plat_M
if plat_M.object_index==prt_TrapDoor
plat_M=-1;
if plat_B
if plat_B.object_index==prt_TrapDoor
plat_B=-1;
if plat_T || plat_M || plat_B
{collide=true; break;}
that was a good info you have there
for anyone who would like to help send me a PM
-
This applies to what X said as well as the topic at hand's question;
The storyline I've got for my game is so dusty I've forgotten the majority of it. If anybody's got a plotline or ideas for one but no game to incorporate them, drop me a line-maybe we can work something out.
I've thought about making mine the DCW game, but doing so would require me to make a full platform sheet for Julius and I already have a fuckton of spriting jobs to finish as it is.