Topic: NES-Style Castlevania Belmont Engine for GameMaker! (Version 0.3 UPDATE!)

[Inccubus]

I have a suggestion for the use of paths for bosses, Las. In order to make things less 'mechanical' and repetitive, use about 6-12 different path variations that are chosen at random by each bat object. Also, upon the completion of a single path loop have the bat object select another path at random excluding the one it just finished. That will make it less obvious that they are flying in set paths.

My personal opinion, however, is that you should a simple random direction choice as it would be much closer to the original and would probably be a lot less work. Plus having paths for a flying enemy even if it is a lot of variants to try to mask it, kinda implies a more mechanical nature to the enemy.

Having said all that. What would be a cool upgrade to this boss would be to have all the sizes of bat have a more realistic behavior. For example as soon as they are created they all fly to the ceiling where they enter a hanging state where they are in the back ground and can't be hit. Then after a random interval they drop down and dive-bomb Trevor. This would make more sense than slowly flapping about waiting to die. Plus it could make for some nice and brutal situations during the fight if say 8 bats decide to attack at about the same time.

[TheouAegis]

That's semi-doable in the original code. You'd just have to alter a few lines. I think you could do it in the ROM without altering the ROM's size.
...
Don't ask me how. The main bat already has a code to make it hang upside down if certain conditions are set. You'd just have to change those conditions. It's handled during the Begin Step event, essentially.

[Las]

I like the idea Incubbus, it all depends on what i can code in. With paths i kinda figured out what to do. I also can now make intros for bosses. But for some reason i tried to put one to death which didn't work. I'm thinking because he was on a path. But the idea of the bats clinging back to the ceilign does seem like more intelleigent AI. Dunno that i can code that in yet thouhg. As for teh multiple paths, i wonder woudlt i set that too random? I'm really not super effecient with code. I always try things first to see if i get them working and ask questions later if not. I do like that idea to so it is far more random and the AI is much tougher to beat. The bosses shoudlnt' be super easy to beat.

[Inccubus]

@Theou: I hadn't thought of that. But you're right most of the needed code is pretty much  already there.

@Las: You can make the paths random by using a switch statement. Very easy actually. Make it into a script. For the bat's creation code make it fly to the origin point you want it to start the path from; +/- a few pixels in x & y for variety. Then call the script and feed it a random number in the correct range. Then in the "End of Path" event make the exact same call to the script. That's pretty much all there is to it. Wouldn't even need any additional variables.

[TheouAegis]

So all this time I thought my code was bad (well, it was pretty messy) because it ran super slow on both my computers. You guys said it was fine and ran ok on your computers. I couldn't figure out what the hell was going on. I spent 6 hours last night rewriting it and trying to debug it (there's another bug in it now), only to find out it was running slow because I had vsync turned on and my computers don't like vsync. 

So here's my script for a door going to the right. Right now there is a bug that may or may not have to do with the fact that I didn't optimize my tile sheet, or it may be related only to my computer. I don't know what's causing the bug, but it's a freaking pixel offset and it's annoying me. So for that reason, this code contains extraneous 1s. Once I figure out why it's doing it, I may update the code because all those 1s slow the transition down a couple cycles.

Here's a link to the new demo. WITH SOUND! (kinda) It still uses my old CV3 engine (Inccubus knows what I'm talking about), so it really is just a demo. The transition itself can be used with any engine because it doesn't involve collisions at all, really.

...Yes, in case any of you missed it, this script will play a sound when the door slams open and again when the door slams shut! Bet you didn't know you could execute sounds during a room transition! (Neither did I...)

//Set scale to window_get_region_width()/256 before transition.
//Set py to obj_Belmont.y*scale before transition.
//Set px to (obj_Belmont.x-view_xview)*scale before transition.

argument15  =   argument4 * transition_steps >> 0;

/* OPTIONAL code if your door doesn't have the black "wall" already
if argument15 >= $8C
{
    draw_set_color(c_black);
    draw_rectangle($70*scale,py-$32*scale,$80*scale,py,0);
}
*/

if argument15 < $0C
{
    draw_surface(argument0,0,1);
    draw_sprite_ext(spr_Belm_walk, 0, px, py, scale, scale, 0, c_white, 1);
}
else
if argument15 < $8C
{
    px          -=  scale;
    draw_surface(argument0, -(argument15-$0C)*scale,1);
    draw_surface(argument1, argument2-(argument15-$0C)*scale,1);
    draw_sprite_ext(spr_Belm_walk, 0, px, py, scale, scale, 0, c_white, 1);
}
else
if argument15 == $8C
{
    draw_surface(argument1, 1+(argument2>>1),1);
    draw_surface(argument0,1-(argument2>>1),1);
    draw_sprite_ext(spr_door_rt, 0, $70*scale, py-$30*scale, scale, scale, 0, c_white, 1);
    draw_sprite_ext(spr_Belm_walk, 0, px, py, scale, scale, 0, c_white, 1);
}
else
if argument15 < $96
{
    draw_surface(argument1, 1+(argument2>>1),1);
    draw_surface(argument0,1-(argument2>>1),1);
    draw_sprite_ext(spr_door_rt, 1, $70*scale, py-$30*scale, scale, scale, 0, c_white, 1);
    draw_sprite_ext(spr_Belm_walk, 0, px, py, scale, scale, 0, c_white, 1);
}
else
if argument15 < $C8
{
    if argument15 == $96
        sound_play(snd_DoorSlam);
    draw_surface(argument1, 1+(argument2>>1),1);
    draw_surface(argument0,1-(argument2>>1),1);
    draw_sprite_ext(spr_door_rt, 2, $70*scale, py-$30*scale, scale, scale, 0, c_white, 1);
    draw_sprite_ext(spr_Belm_walk, 0, px, py, scale, scale, 0, c_white, 1);
}
else
if argument15 < $F8
{
    px          +=  scale;
    draw_surface(argument1, 1+(argument2>>1),1);
    draw_surface(argument0,1-(argument2>>1),1);
    draw_sprite_ext(spr_door_rt, 2, $70*scale, py-$30*scale, scale, scale, 0, c_white, 1);;
    draw_sprite_ext(spr_Belm_walk, (argument15-$C7-1)>>3, px, py, scale, scale, 0, c_white, 1);
}
else
if argument15 < $102
{
    draw_surface(argument1, 1+(argument2>>1),1);
    draw_surface(argument0,1-(argument2>>1),1);
    draw_sprite_ext(spr_door_rt, 2, $70*scale, py-$30*scale, scale, scale, 0, c_white, 1);
    draw_sprite_ext(spr_Belm_walk, 1, px, py, scale, scale, 0, c_white, 1);
}
else
if argument15 < $10C
{
    draw_surface(argument1, 1+(argument2>>1),1);
    draw_surface(argument0,1-(argument2>>1),1);
    draw_sprite_ext(spr_door_rt, 1, $70*scale, py-$30*scale, scale, scale, 0, c_white, 1);   
    draw_sprite_ext(spr_Belm_walk, 1, px, py, scale, scale, 0, c_white, 1);
    if argument15 == $10B
        sound_play(snd_DoorSlam);
}
else
{
    px          -=  scale;
    draw_surface(argument0, scale*-(argument15-$10B)-argument2/2,1);
    draw_surface(argument1, argument2 - argument2/2 - scale*(argument15-$10B),1);
    draw_sprite_ext(spr_Belm_walk, 1, px, py, scale, scale, 0, c_white, 1);
}

draw_status(scale);

[FireSeraphim]

@TheoAegis: I wonder if you couldn't somehow compress the door transition code to be more "multiple protagonist friendly"? Also I believe I sent you a PM ages ago and find it amusing that you have not replied yet.

[TheouAegis]

Too busy to work on other people's games.

And define "multiple protagonist". If you mean 2 or more characters will be on the screen at the same time, .... that would be doable...  If you simply mean the player can be playing as one of 3 or 4 different characters, you need to just put in a conditional that checks which character the player currently is. If the game was optimized, you could even just turn it into an arithmetic function, which would be a bit faster I think.

if obj_Belmont.object_index == obj_Belmont
draw_sprite_ext(spr_Belm_walk, 0, px, py, scale, scale, 0, c_white, 1);
else
if obj_Belmont.object_index == obj_Grant
draw_sprite_ext(spr_Grant_walk, 0, px, py, scale, scale, 0, c_white, 1);
else
if obj_Belmont.object_index == obj_Sypha
draw_sprite_ext(spr_Sypha_walk, 0, px, py, scale, scale, 0, c_white, 1);
else
if obj_Belmont.object_index == obj_Alucard
draw_sprite_ext(spr_Alucard_walk, 0, px, py, scale, scale, 0, c_white, 1);

An example of the arithmetic method would be:

draw_sprite_ext(spr_Belm_walk+12*character, 0, px, py, scale, scale, 0, c_white, 1);

[TheouAegis]

I also posted this on my blog. I'll keep this post shorter though, as I'm long-winded on my blog.

Ask a Game Maker programmer how to put wave motion in a game and they'll almost always tell you to use sin() or cos(). There is an easier method. Although probably not technically a sine wave, it's still a wave motion.

For those unfamiliar with Game Maker's terminology, vspeed is the variable used for vertical speed and ystart is the variable used for the starting y-coordinate of an instance in the room. Pretty straight-forward.

vspeed += (ystart - y) / length

The value of length is inversely proportional to the wavelength -- the higher the value of length, the narrower the wave. The initial value of vspeed affects the amplitude of the wave directly.


Yes, it took me this long to figure out what the Medusa Head code actually did. I'm old and fat -- leave me alone!

[Corpsecrank]

Lol you started talking about waves and I was like wtf would you need a wave motion for in an 8bit cv game then you said medusa head and I almost spit my drink out.

But aside from that are you still messing around with this? I am thinking about using this to demonstrate how the tile sets I am working on can be used. I wasn't sure how complete this was or what the deal was with it. Game maker isn't really my thing but if this is fairly solid it could make a great base to put my tiles to use once.

[Esco]

<DELETED>

[Corpsecrank]

<DELETED>

Stop being so mysterious geez...

[TheouAegis]

I'm curious what Esco's post was too.

The original project up to v0.3 is pretty much scrapped. It's a workbench. I use it every so often for some things, but the current version is just a rewrite of the actual NES code, some things scrapped. For example, I was including Sypha, Grant and Alucard at first, but have since decided to only focus on Trevor's Code for the time being to simplify things a little. When I'm not working or watching Ultraman episodes, I'm usually looking over NES code. So in a sense, the project is on indefinite hiatus. However, every so often I do release "new code". I don't use the tiles method anymore, opting for collision maps now, but I still stand by most of what I have come up with over the months (or has it been a year since I scrapped it)? The password and name entry screens I have no intention of changing, except maybe someday trying to simplify the code, although I doubt that will ever happen. The Medusa Head/Bat/Winged Demon code I posted here took me a long ass time to come up with.

My problem was I kept using a literal movement script (discussed in the latter pages of this thread), but when I finally consolidated the three variables (vert_1,vert_2,vert_3) into a single variable, the entire sine wave code Konami used made perfect sense and I was able to come up with that formula. Most code I still suck at interpreting. I'm sure if I showed Esco the White Dragon script, he might be able to make sense of it, but I only barely understood it the last time I looked at it and in my rewrite of my code (it's like my fourth rewrite that i'm on right now), I haven't gone back to tackle the White Dragon yet. Right now I've put enemies on hold to try to break down the mechanics of the Step Event (so to speak) and that's taking me a long time to get through. There are lots of little things going on behind the scenes that affect the mechanics of the game that I haven't worked out just yet. And I'm sure they have some code that they ripped off other games that have no use either, so some of the code might be dummy code. Some variables might pertain to Grant or Alucard, but since I'm not coding them I'd have no idea.

But I've already adopted quite a few coding styles based on CV3, so I don't care anymore if people are waiting for a release -- I'm taking my time just learning from Konami. It's also fun seeing code and thinking, "WHy the hell did they do that? It'd take up less cart space and possibly even less CPU if they just did this instead." Or "Wow, Konami made a typo here!" It's kinda like the episode/volume of Hikaru No Go where Hikaru points out a flaw in Sai's match against Toyo-meijin and Sai was like, "Oh snap, Hikaru's progressed so far already!" I'm not a fast learner, though. If I was, I'd know what the fuck I'm looking at half the time.


....

Wait were you the guy that had that ROM hack that everyone was like, "Sick tiles mate!"? If I ever got my code taken care of, I was gonna recruit that guy for custom tiles. My current pet project is to implement attribute tables, but I think that's actually too simple so I put it on hold. I know it's ticking Inccubus off cuz he doesn't want to use tile assemblies or palette-swapped backgrounds (although I have serious doubts that a palette swapped background is all that worthwhile in Game Maker). But the palette swap demo that didn't have enough comments for Esco is already being incorporated into my project. Hence another reason I had to do a rewrite. Also, once I figured out what the subroutine for playing sounds was in CV3, I had to go back and locate all the sound_play subroutines so I rewrote the code while I was at it. I've isolated a couple more variables since then too. I wish I could get the ROM offset notes from the guy that made reVamp, in case there's something "obvious" I missed.

[Inccubus]

I essentially only care about Trevor, really. And I have tons of stuff to do in the mean time. So no worries.

[Corpsecrank]

I'm curious what Esco's post was too.

The original project up to v0.3 is pretty much scrapped. It's a workbench. I use it every so often for some things, but the current version is just a rewrite of the actual NES code, some things scrapped. For example, I was including Sypha, Grant and Alucard at first, but have since decided to only focus on Trevor's Code for the time being to simplify things a little. When I'm not working or watching Ultraman episodes, I'm usually looking over NES code. So in a sense, the project is on indefinite hiatus. However, every so often I do release "new code". I don't use the tiles method anymore, opting for collision maps now, but I still stand by most of what I have come up with over the months (or has it been a year since I scrapped it)? The password and name entry screens I have no intention of changing, except maybe someday trying to simplify the code, although I doubt that will ever happen. The Medusa Head/Bat/Winged Demon code I posted here took me a long ass time to come up with.

My problem was I kept using a literal movement script (discussed in the latter pages of this thread), but when I finally consolidated the three variables (vert_1,vert_2,vert_3) into a single variable, the entire sine wave code Konami used made perfect sense and I was able to come up with that formula. Most code I still suck at interpreting. I'm sure if I showed Esco the White Dragon script, he might be able to make sense of it, but I only barely understood it the last time I looked at it and in my rewrite of my code (it's like my fourth rewrite that i'm on right now), I haven't gone back to tackle the White Dragon yet. Right now I've put enemies on hold to try to break down the mechanics of the Step Event (so to speak) and that's taking me a long time to get through. There are lots of little things going on behind the scenes that affect the mechanics of the game that I haven't worked out just yet. And I'm sure they have some code that they ripped off other games that have no use either, so some of the code might be dummy code. Some variables might pertain to Grant or Alucard, but since I'm not coding them I'd have no idea.

But I've already adopted quite a few coding styles based on CV3, so I don't care anymore if people are waiting for a release -- I'm taking my time just learning from Konami. It's also fun seeing code and thinking, "WHy the hell did they do that? It'd take up less cart space and possibly even less CPU if they just did this instead." Or "Wow, Konami made a typo here!" It's kinda like the episode/volume of Hikaru No Go where Hikaru points out a flaw in Sai's match against Toyo-meijin and Sai was like, "Oh snap, Hikaru's progressed so far already!" I'm not a fast learner, though. If I was, I'd know what the fuck I'm looking at half the time.


....

Wait were you the guy that had that ROM hack that everyone was like, "Sick tiles mate!"? If I ever got my code taken care of, I was gonna recruit that guy for custom tiles. My current pet project is to implement attribute tables, but I think that's actually too simple so I put it on hold. I know it's ticking Inccubus off cuz he doesn't want to use tile assemblies or palette-swapped backgrounds (although I have serious doubts that a palette swapped background is all that worthwhile in Game Maker). But the palette swap demo that didn't have enough comments for Esco is already being incorporated into my project. Hence another reason I had to do a rewrite. Also, once I figured out what the subroutine for playing sounds was in CV3, I had to go back and locate all the sound_play subroutines so I rewrote the code while I was at it. I've isolated a couple more variables since then too. I wish I could get the ROM offset notes from the guy that made reVamp, in case there's something "obvious" I missed.

I wasn't the one with the tiles. I never did a rom hack of any kind personally. I am currently also learning from konami only I am learning in the graphics department. I am kind of amazed at just how simple the graphics for the games were. The actual "tiles" are freaking huge. I mean seriously I thought the tiles were like 1/4 of the actual tile size. For instance the floor blocks are 1/4 the size of a full tile but looking at those blocks you would assume the block is a single tile. Stairs are weird because of this and they managed to cram tiles into places they shouldn't be and stuff.

Anyhow I am trying to pull as many tiles from the 3 nes games at the moment. I have that other thread called Tile Sheets where I am going to be releasing and updating that as I go. Once I do have all the tiles I can grab from those games I am going to build out a lot of custom stuff since the games had pretty heavy limitations.

My overall vision here though is to put a package of stuff together tiles sprites etc and then pair it off with an engine almost anyone can use. If your engine was solid enough it could be used for this. Essentially it would allow anyone who wanted to make a classic style fan game do so in as little time and with as little effort as possible. Stages could be built fast using the tiles I am working on and I as well as others have done a lot of enemies and characters which could just be dropped in. I can whip up a page of items and anything else needed.

I still want to make a non linear game with these tiles and stuff that plays similar to sotn and has a fairly similar map to that game only with this material. It wouldn't be quite as complex as sotn I would want to scrap the spells since they used lame fighter style input that I am not fond of just to give an example. I suppose simplifying the game play much like richter mode. I still think it would be amazing and fun.

[TheouAegis]

That awkward moment when you look back over your code and not only can't make sense of it, but also don't even remember typing it up in the first place.Those are my comments; that's my movement code; but why the hell did I put it in that particular timeline position and why can't I find it in the NES code?