![]() ![]() 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. The original project up to v0.3 is pretty much scrapped. If obj_Belmont.object_index = obj_Alucardĭraw_sprite_ext(spr_Alucard_walk, 0, px, py, scale, scale, 0, c_white, 1) Īn example of the arithmetic method would be:ĭraw_sprite_ext(spr_Belm_walk+12*character, 0, px, py, scale, scale, 0, c_white, 1) ![]() If obj_Belmont.object_index = obj_Belmontĭraw_sprite_ext(spr_Grant_walk, 0, px, py, scale, scale, 0, c_white, 1) ĭraw_sprite_ext(spr_Sypha_walk, 0, px, py, scale, scale, 0, c_white, 1) If the game was optimized, you could even just turn it into an arithmetic function, which would be a bit faster I think. 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 you mean 2 or more characters will be on the screen at the same time. Too busy to work on other people's games.Īnd define "multiple protagonist". Set px to (obj_Belmont.x-view_xview)*scale before transition.Īrgument15 = argument4 * transition_steps > 0 Set py to obj_Belmont.y*scale before transition. Set scale to window_get_region_width()/256 before transition. 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.) The transition itself can be used with any engine because it doesn't involve collisions at all, really. WITH SOUND! (kinda) It still uses my old CV3 engine (Inccubus knows what I'm talking about), so it really is just a demo. 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. So for that reason, this code contains extraneous 1s. I don't know what's causing the bug, but it's a freaking pixel offset and it's annoying me. 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. So here's my script for a door going to the right. 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. I couldn't figure out what the hell was going on. You guys said it was fine and ran ok on your computers. So all this time I thought my code was bad (well, it was pretty messy) because it ran super slow on both my computers. 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. This would make more sense than slowly flapping about waiting to die. ![]() Then after a random interval they drop down and dive-bomb Trevor. 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. What would be a cool upgrade to this boss would be to have all the sizes of bat have a more realistic behavior. 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. 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. That will make it less obvious that they are flying in set paths. Also, upon the completion of a single path loop have the bat object select another path at random excluding the one it just finished. 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. I have a suggestion for the use of paths for bosses, Las. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |