Full Games List
Featured Games
New Games
Reviews
Media
Blogs
Game Updates
Images Feedback Summary
Game Design Highlights
Articles
Scripts
Utilities / Plugins
Resources
Engines
Engine Bulletins
What is Makerscore?
Past Events
Achievements
Misaos
Forums
Chat
New to RMN?
Full Store List
RMN Music Pack (free)
Profile
Locker
Play ListsKAZESUI'S PROFILE
Close
Search
Filter
All
Game Pages
User Statuses
Valedictory Game Drive
1. Where were you in your project when you joined the Game Drive?
Started the project from scratch for this event, so it simply didn't exist before the event.
2. Progress report
basically, I've gone from nothing to this:
a functional side scroller shooter with one complete level until now. Though functional it could still use help in form of testing
3. Set your goals for this week
Goal for the week would have to be to finish level 2. If I can keep up the pace, despite all the other non rm related stuff I have to do, it'll have 4 levels by the end
Started the project from scratch for this event, so it simply didn't exist before the event.
2. Progress report
basically, I've gone from nothing to this:
a functional side scroller shooter with one complete level until now. Though functional it could still use help in form of testing
3. Set your goals for this week
Goal for the week would have to be to finish level 2. If I can keep up the pace, despite all the other non rm related stuff I have to do, it'll have 4 levels by the end
Zero Base
Yeah I know it, just never gotten around to use it since I like to make the events myself. They have a pretty good list over the different tools for rm2k3 at "atelier" (german forum) so I know of quite a few, though I have barely tested any of them. Still thanks for mentioning it
As for the ABS, it's still mostly system and less game at the moment, which is why it doesn't have a game page yet or anything. I've gotten a bit further with it since the video though. Now it has a spell which will cast 3 homing ice missiles which will each target an enemy if they're within a certain radius of the targetted enemy.
I really like that spell.
As for the ABS, it's still mostly system and less game at the moment, which is why it doesn't have a game page yet or anything. I've gotten a bit further with it since the video though. Now it has a spell which will cast 3 homing ice missiles which will each target an enemy if they're within a certain radius of the targetted enemy.
I really like that spell.
Title.PNG
your keen eye isn't wrong, I just had some trouble finding a font which would replicate the old one better. For those who don't recognize it, it's a slight edit of the Zero Wing title screen.
If I get time, I'd like to do something about it, but since I want this done for the valedictory event, other stuff takes priority.
Can you make arrays in rm2k3?
you should use the pointers in rm2k3 for that. you can use "variable reference" to access the variable with same ID as the value of the variable you're using as reference, and you can use "Value stored in index" to get the value of the variable with ID equal to the value of the variable you use as reference.
2 Animations in 1 ?
author=Cherry
(Off-topic, just curious: What's that lower case "m" with the number 0 below my profile picture?)
It's your "maker score". You get more maker score from submitting stuff to the site, like reviews, articles, tutorials, games and so on.
Zero Base
Yes, totally a lot of work. I started working on this from scratch... last last thursday or so, i.e. about 3 days ago.
It does probably help that I'm quite familiar with the engine though, knowing a lot of the ins and out of it, which is how I was able to come up with a solution which would allow for this many bullets to not cause lag, at least not on my computer.
Also, the explanation I gave was rather brief and probably not too considerate to details which comes with doing pixel based stuff, lot of it being the math behind it.
The bullets are all pictures with screen relative coordinates, so to get the tiles around them, you have to subtract the screen relative coordinates to a reference event, and then divide them by 16, and then further I use modulo to determine how far into a cell the bullets are or so. And there's also the cannons which fire at the last position of the ship where I use improvised trigonemetry to calculate the path of the bullets.
I wouldn't say it puts shame to your abs though, since as said, I do have a bit more experience, and your game does look interesting (probably has a lot to do with the player sprite).
That said, if there's stuff you wonder about how to do in your abs you could probably ask me. I know a thing or two about rm2k3 ABS's as well, as I've worked quite a bit with stuff like that as well.
It does probably help that I'm quite familiar with the engine though, knowing a lot of the ins and out of it, which is how I was able to come up with a solution which would allow for this many bullets to not cause lag, at least not on my computer.
Also, the explanation I gave was rather brief and probably not too considerate to details which comes with doing pixel based stuff, lot of it being the math behind it.
The bullets are all pictures with screen relative coordinates, so to get the tiles around them, you have to subtract the screen relative coordinates to a reference event, and then divide them by 16, and then further I use modulo to determine how far into a cell the bullets are or so. And there's also the cannons which fire at the last position of the ship where I use improvised trigonemetry to calculate the path of the bullets.
I wouldn't say it puts shame to your abs though, since as said, I do have a bit more experience, and your game does look interesting (probably has a lot to do with the player sprite).
That said, if there's stuff you wonder about how to do in your abs you could probably ask me. I know a thing or two about rm2k3 ABS's as well, as I've worked quite a bit with stuff like that as well.
Proper performance scripting in 2k3
I thought it was weird for call event to have that adverse effect, considering I was pretty sure I had tested them in some similar manner, and also because of how much I use them in my events which needs to be updated around once every 0.0167 sec. Any extra 0.0167 per event call would have been pretty drastic there.
I don't think I've called too too many big events in label loops though, as the only time it would seem practical is if the screen is static at the time, so I guess I don't know too much about it's potential ill effects and as long as one follow your advice of having at least a 0.0 wait in the loop somewhere, it doesn't seem to have any noticable problems for me at least.
Using the method I mentioned earlier I get
60 ips for pp loops
200,000 ips for loops, and
300,000 ips for label loops.
I've done quite a bit of testing on these things as well, which has revealed to me interesting and sad things, like comments taking an instruction cycle, and even empty lines as well, which is why "loops" are slower than labels.
Doing variable operation on any variable range seems to be just as fast as any other variable operation though, which is good for optimizing code with lot of similar variable operations. In other words, being thoughtful about the location of your various variables might help as well.
Another thing I found peculiar was your claim about nesting if statements not being good unless there's a loop in it which you could prevent.
When I add a branch to the label loop with just a counter, it tells me that if the condition is permnantly false, the if statement will only execute 2 instructions for each iteration ( the check, and a jump to the command after "end" I suppose), regardless of any amount of instructions inside of it.
The problem with nesting them comes from all the empty lines and the "end" lines, when you get further into the nests, which still get read.
an "if nest" with 4 if's and only additional code in the final one, will execute 11 lines if all if's were true except the last one. This is regardless of the amount of commands within the top if (which btw. is almost all the lines if all if's are empty). If only the first if was true, it would only execute 5 lines.
You could use labels at the end of each nest top optimize it though. This could cut the 3 of 4 if's true scenario down to 6 lines. You'll just need a lot of labels in case you have many nested statements.
The way I use to determine this, is to take 600,000 / lines to read, and it will return the same value at the end of a counter session using my label loop method. it has held true for all my observations so far.
So bottom line is something you've already mentioned I suppose. Labels are very good for optimalization, at the potential cost of making spaghetti code of your events.
Hope I'm not sounding too negative or anything though, as there is very much good in this tutorial.
I don't think I've called too too many big events in label loops though, as the only time it would seem practical is if the screen is static at the time, so I guess I don't know too much about it's potential ill effects and as long as one follow your advice of having at least a 0.0 wait in the loop somewhere, it doesn't seem to have any noticable problems for me at least.
Using the method I mentioned earlier I get
60 ips for pp loops
200,000 ips for loops, and
300,000 ips for label loops.
I've done quite a bit of testing on these things as well, which has revealed to me interesting and sad things, like comments taking an instruction cycle, and even empty lines as well, which is why "loops" are slower than labels.
Doing variable operation on any variable range seems to be just as fast as any other variable operation though, which is good for optimizing code with lot of similar variable operations. In other words, being thoughtful about the location of your various variables might help as well.
Another thing I found peculiar was your claim about nesting if statements not being good unless there's a loop in it which you could prevent.
When I add a branch to the label loop with just a counter, it tells me that if the condition is permnantly false, the if statement will only execute 2 instructions for each iteration ( the check, and a jump to the command after "end" I suppose), regardless of any amount of instructions inside of it.
The problem with nesting them comes from all the empty lines and the "end" lines, when you get further into the nests, which still get read.
an "if nest" with 4 if's and only additional code in the final one, will execute 11 lines if all if's were true except the last one. This is regardless of the amount of commands within the top if (which btw. is almost all the lines if all if's are empty). If only the first if was true, it would only execute 5 lines.
You could use labels at the end of each nest top optimize it though. This could cut the 3 of 4 if's true scenario down to 6 lines. You'll just need a lot of labels in case you have many nested statements.
The way I use to determine this, is to take 600,000 / lines to read, and it will return the same value at the end of a counter session using my label loop method. it has held true for all my observations so far.
So bottom line is something you've already mentioned I suppose. Labels are very good for optimalization, at the potential cost of making spaghetti code of your events.
Hope I'm not sounding too negative or anything though, as there is very much good in this tutorial.
The Screenshot Topic Returns
Yep, I'm testing how many bullets it can handle before it gets laggy. I could probably have over 100 bullets at the screen at the same time, but I think the rm2k3 would start objecting some time before that, as every bullet also needs to be able to detect if has hit something.
As for my the implementation of the bullets, for the player bullets I'm utilizing the "get event ID" for everything it's worth.
Basically, every bullet checks the tiles around them, and if it finds an enemy event, it uses a call event to call the event with the same ID.
Doing this prevents me from having to go through a big bunch of checks against all enemy coordinates for every iteration of every bullet. Something which would quickly cause lag.
Also, the reason why I need to check the tiles around the bullets and not just it's current is because of how rm2k3 handles tile coordinates. Pretty much as soon as an event decides to go in one direction, it will change it's coordinates, eventhough most of the event is still in the previous tile. So adding some tiles to check as well as a little check with screen relative coordinates within the events you call, I can more precisely determine if the enemy event was hit.
As for the enemy bullets, they pretty much only check if they've hit the hitbox of the ship in terms of screen relative coordinates, so that part of them isn't too complex. The only other thing about them is that they can go at any angle dividable by 3, which adds some variable operations to each of their iterations.
So far it doesn't seem to cause any noticable lag, which is better than I expected. I also think there's still a little room for optimalization.
As for my the implementation of the bullets, for the player bullets I'm utilizing the "get event ID" for everything it's worth.
Basically, every bullet checks the tiles around them, and if it finds an enemy event, it uses a call event to call the event with the same ID.
Doing this prevents me from having to go through a big bunch of checks against all enemy coordinates for every iteration of every bullet. Something which would quickly cause lag.
Also, the reason why I need to check the tiles around the bullets and not just it's current is because of how rm2k3 handles tile coordinates. Pretty much as soon as an event decides to go in one direction, it will change it's coordinates, eventhough most of the event is still in the previous tile. So adding some tiles to check as well as a little check with screen relative coordinates within the events you call, I can more precisely determine if the enemy event was hit.
As for the enemy bullets, they pretty much only check if they've hit the hitbox of the ship in terms of screen relative coordinates, so that part of them isn't too complex. The only other thing about them is that they can go at any angle dividable by 3, which adds some variable operations to each of their iterations.
So far it doesn't seem to cause any noticable lag, which is better than I expected. I also think there's still a little room for optimalization.
Games - Tester
Games - Other
