TRAVIO'S PROFILE

I make and play games - playing games I use as a reward for reaching specific milestones within my various development projects. I've played a wide variety of games, having started at the tender age of three and worked my way up over the years so that, at one point, I was actually going out of my way to find the original games (cartridges, CDs, whatever) to play.

All games I elect to review must be 'Complete' status (though games still in the process of clearing out bugs are fine and will be noted in the review itself). These games must have a download on RMN (as I pass them to my Dropbox queue) and need to be self contained - everything I need to play should be in the download, without needing to install anything (including RTPs; we aren't living in the days of slow connections anymore, people). You should also have any fixes in the download, not something I have to look through the comments for - I'm going to be avoiding them like the plague until I've finished the review.

When I review a game, I try to play as much of it as I can possibly stand before posting the review - I make notes/write part of the review as I'm playing, so a lot of what goes into the review is first impressions of sections. I'm also not a stickler - things don't have to be perfect - but I've seen many examples of things not done perfectly but, at the same time, not done horribly. I rate five categories on a scale from 1 to 10: Story, Graphics, Sound, Gameplay & Pacing, and Mapping & Design. 5 is average to me, so it's not necessarily saying that category is bad - it's saying it's middle of the road. Games within the same editor are compared to one another, not games across editors (I'm not going to hold an RM2k game to the same standards as a VX Ace game due to system limitations, but I won't let it hold back the RM2k game's rating) - unless the game is part of a series across multiple editors.
Legion Saga X - Episode ...
A fan updated version of the RPG Maker 2000 classic

Search

Filter

Title.png

I'm not gonna lie, I kinda like the way this title turned out. The rough outlining with the coloured textures does something for me.

[VX Ace] Russian Roulette Skill

author=Sam
- One way I thought of doing it would be to have the Skill set a Variable to a random number between 1 and 6 to decide how many trigger pulls there will be then invoke one of another six Skills where the battle animation is pre-determined so the number of shots in the animation tallies up to the number of shots actually fired, but I think this cheapens the laws of probability and eliminates some of that essential tension as you then basically only have a 50/50 chance of it being you or the enemy that gets hit.

This is basically what it comes down to when you use the skill anyways - there's a roughly 50/50 chance the skill's going to hit either you or the enemy (weighted more towards hitting the enemy, something like 60/40 in favour of hitting the enemy). What I'd suggest is dropping the idea of only six attempts to fire it, or that the sixth shot will automatically hit. Here's what I'm proposing:

The bullet gets loaded into a random chamber - I'm assuming he's using a six chamber revolver, so it's assigned to (let's say) the "bulletLoadedIn" variable giving it a number between 1 and 6 in there. Hell, it doesn't even have to be a random chamber - you could just always assume it's in chamber 1, or 6, or 3, or whatever.

In true Russian Roulette, the chamber is spun before every shot. That means that, for each shot, you generate a random number between 1 and 6 and compare it to the bulletLoadedIn variable - if it's the same, the shot goes off, if not you swap to the other person as a target and try again, incrementing the "shotsTried" variable by 1 (and then work that variable into your damage formula so that the longer it takes for a shot to go off, the more damage it does).

The downside to this method is that RNG could make these sequences extremely long, but it would have the tension you're looking for - in your sixth-shot-hits-for-sure method, the skill is weighted more towards doing more damage to your enemy than it is to the character (because it aims at your character first and each attempt increases the damage - if you're interested, I can show you the math). With this method, it might be possible to do great damage to an enemy, but the chance of doing just as much damage to the character is there - without artifically weighting it towards one character or the other. If you want to make sure it doesn't run for an extremely long time, you can just limit the number of attempts to make the shot - if it doesn't go off, both the character and the enemy just got lucky today and live to fight another day.

I scream, you scream, we all scream for testers.

I've got some time to give you a hand if you're still looking for someone.

So, Aveyond: Lord of Twilight....

Loving me dem Steam reviews.

So, Aveyond: Lord of Twilight....

Edit: Urgh, internet hiccup double post blegh. >_<

[Ace] So you pros, how would one go about adding new variables/stats to a character class in Ace?

I'm not sure on the standard Ruby protocol, but it's just long standing programming paradigm that I've been taught: only an object/class should ever access its own variables. An attr_reader (from what I can tell) can be modified by the object itself - an attr_accessor can be modified from outside (please, correct me if I'm wrong on Ruby conventions; this particular differentiation confuses me at times). From what I can tell, Game_BattlerBase follows this pattern as well - while other methods outside of the class calculate values (such how much damage to take), they pass those values to methods within the Game_BattlerBase class to handle.

As an example, it's easier to compartmentalize your sanity testing if only a class can access its own variables.

[Ace] So you pros, how would one go about adding new variables/stats to a character class in Ace?

Assuming you only want it for player characters, Game_Actor is the place you're looking to start adding stuff to.

I don't know 100% if this is the proper way, but I'd go about it by adding a new attribute, probably one for each, most likely an attr_reader, and then create methods within the Game_Actor class to both read and set the value for each attribute. Then you could do something like...

Conditional (Script) $game_party.members.getSecurity() >= 10

Now, would they be learning these skills through in-game methods (ie. you train them as a player) or through leveling up/part of their normal class kit?

Name That BGM (Concluded?)

It was the name that immediately clicked it in my mind - Tower of the Tarolisk from Skyblazer (I don't know if there's an actual name for the song, but I remember the level). =P

Font Change?

I much prefer your old one. I can't quite place what, but something about this one seems off to me.