AEROGP'S PROFILE

Search

Filter

GAY MARRIAGE CALL-OUT

Is that you saying all those things, or your friend?

Habits

I have too many. Probably ADD, but I'm not sure.

Release Something! Day VII: Advent Children [June 20th]

It means that your committing yourself to releasing a game/demo to the site/forum, no matter what its condition is, on June 20th and then passing it around and playing everyone else's releases.

Hope you have something presentable by then. =P

Release Something! Day VII: Advent Children [June 20th]

Finally got around to making something in VX, and it's looking pretty good. I'm not entirely satisfied with how I organized it, but I'm sure I'll be able to restructure and have something playable for everyone to try by June 20th. I'm leaving the game untitled, for now, because I haven't fully decided what the storyline will be like.

My first RSD... should be interesting.

If you had to make the next Sonic game...

author=halibabica link=topic=3768.msg75841#msg75841 date=1242790011
I'll admit, I haven't played many of the new Sonic games, so I don't know how well they recapture the essence of the old games. But the ridiculous premises and gimmicks behind them are so awful, I've never even bothered to check them out. The abysmal reviews I hear don't help things much. I'm usually willing to try something before assuming it's terrible, but I guess I've heard too many negative opinions to want to waste $40.

Rent them for less. At least Sonic Rush Adventure or Sonic Unleashed, as they appear to be the direction Sonic Team intends to head forward with. Unless you're into mercilessly abusing glitches and bugs, though, avoid Sonic the Hedgehog (2006) like the plague.

If you had to make the next Sonic game...

The Mega Drive titles were about level design. They captured a certain blend of simplicity, flow, exploration, and intuitive gimmicks, then wrapped in up in a bow of restraint. At some point, the bow was released, and all the elements pretty much splattered out. None of the newer titles could reclaim that magic because, even if they could gather the bits and pieces, the bow is gone so they just get in each others way. They couldn't blend anymore.

That's what happens when you make Sonic all about speed. Most of the actually interesting concepts require slow precision and patience, but when you're running at 72 mph, it becomes a chore to even stop and jump from platform to platform - you know, actual platforming. Other titles in the franchise had their own share of problems, such as copious amounts of linearity, but this is by far the most important one, and Sonic Unleashed the most recent and best example. (It even has the exploration and simplicity back in full force!) Most other "problems", especially some of the ones mentioned in this thread, are superfluous drivel

Problems with Game_Unit

Wow, I had some stupid preconceived idea on how print works in Ruby, and now that I've actually tried it out, it's become my new best friend. =O

Anyways, I used to discover that it was @active_battler that was going nil, not sprite.battler. Understandable: @action_battlers' lopping off the top reference and passing it to @active_battler, so it's not longer there when I go back to check. *smacks forehead* I think I can take it from here, thanks.

Also, that sorting trick is a default part of make_action_orders in both xp and vx. I didn't write it.

Problems with Game_Unit


#--------------------------------------------------------------------------
# * Create Action Orders
#--------------------------------------------------------------------------
def make_action_orders
return if members.empty?
@action_battlers.clear
@action_battlers = members
@action_battlers -= $game_party.members if $game_troop.surprise
@action_battlers -= $game_troop.members if $game_troop.preemptive
for battler in @action_battlers
battler.action.make_speed
end
@action_battlers.sort! do |a,b|
b.action.speed - a.action.speed
end
@battler_sprites.clear
for battler in @action_battlers
@battler_sprites.push(Sprite_BattlerFace.new(@viewport, battler))
end
end

#--------------------------------------------------------------------------
# * Frame Update
#--------------------------------------------------------------------------
def update
return if @battler_sprites.empty?
for sprite in @battler_sprites
offset = @action_battlers.index(@active_battler) -
@action_battlers.index(sprite.battler)
sprite.update(224 - offset * 96, 256, (offset <= 2 and offset >= (-2)))
end
@viewport.update
end

Okay, so the new problem is that Sprite_BattlerFace contains a reference to a battler in @action_battlers, which is set with make_action_orders. But when it comes time to update, the game returns an error basically saying that @action_battlers.index(sprite.battler) returned nil - it couldn't find the reference back in its original source. Why is that?

Problems with Game_Unit

EDIT: Nevermind, you were right in a way. members = defined members as local instead of using the method called members. Removing that and setting @battlers = instead solved that.

I had another problem, too, but I think I know how to resolve it. I'll post again if I don't get any results. Until then, thanks.

Problems with Game_Unit

After getting back into RPG Maker and successfully implementing a turn-based system in VX, I'm now trying to implement a turn order framework. I've managed to grouped together the functions used to determine turn order in a class Game_Battlers, inheriting from Game_Unit, without breaking the combat system. Now to make things simpler for the system, I tried to put $game_party.members and $game_troop.members into a single array "@battlers", which like the former two can be referenced with the method "members," and is initialized in Game_Battler before anything else.


#--------------------------------------------------------------------------
# * Initial Battlers Setup
#--------------------------------------------------------------------------
def setup_members
members = []
for i in $game_party.members + $game_troop.members
members.push(i)
end
end

There's a bug in this method, and I want to know what it is. To make sure it wasn't anything else, I setup combat to automatically start a game over if members.empty? returns true, and unsurprisingly it does. Naturally, this would cause the combat to break down into an infinite loop of @active_battler being nil, which is why I had to test it in this way. When I tested to see if the native members were okay, though ($game_party.members and $game_troop.members), they returned false - they weren't empty, yet members was leaving the method empty anyways.

Just be sure it wasn't the way I was doing it, I changed the method to a single line: members = $game_party.members + $game_troop.members. Short, sweet, and to the point, yet still nada. Just what the heck is going on here, and what can I do about it? Just solving it is not enough, either - I need to know the cause so I can avoid it in the rest of my code.