Vícios e amores servem para preencher o vazio
Estou ciente desse aspecto da linguagem (como você mesmo apontou), mas também não vejo de que forma isso prejudica o código.Resque comentou:Arquivo GameManager Linha #37
Código:def scroll_speed_increment return $game_score / 100.0 / Graphics.frame_rate end
Os métodos em Ruby sempre retornam a ultima linha por padrão, o return acaba sendo usado para forçar uma saídas do método antes que chegue na ultima linha, igual você fez no código abaixo:
EX:
Código:def generate_obstacle(y) return unless rand(100) < 90 range = (1...width).to_a - track_range(y).to_a return if range.empty? type = obstacle_types_by_rate.sample x = range.sample if @obstacles[y].nil? @obstacles[y] = Game_Obstacle.new(type, x, y) else @obstacles[y].type = type @obstacles[y].x = x @obstacles[y].y = y end end
O método da linha #37 poderia ser alterado para:
Código:def scroll_speed_increment $game_score / 100.0 / Graphics.frame_rate end
def window_width
return 160
end
Resque comentou:Arquivo Spriteset_Christmas Linhas #24, #26 e #27.
Código:def create_viewports @viewport1 = Viewport.new @viewport2 = Viewport.new @viewport2.z = 100 @viewport3 = Viewport.new @viewport3.z = 300 end
Utilizar números (1, 2 e 3) no final do nome de variáveis 'viewport' dificulta a leitura, cada viewport poderia carregar a finalidade em seu próprio nome:
EX:
Código:def create_viewports @viewport_track = Viewport.new @viewport_santa = Viewport.new @viewport_santa.z = 100 @viewport_score = Viewport.new @viewport_score.z = 300 end
Código:def update @viewport_track.update @viewport_santa.update @viewport_score.update ...
def create_viewports
@viewport1 = Viewport.new
@viewport2 = Viewport.new
@viewport3 = Viewport.new
@viewport2.z = 50
@viewport3.z = 100
end
Resque comentou:No começo do jogo, se o personagem for carregado para a extrema direita, ele nunca será congelado mesmo estando na neve:
#--------------------------------------------------------------------------
# * Verifica se uma posição está na trilha
#--------------------------------------------------------------------------
def on_track?(x, y)
@data[x, y] != SNOW_TILE
end
#--------------------------------------------------------------------------
# * Verifica se uma posição está na trilha
#--------------------------------------------------------------------------
def on_track?(x, y)
(@data[x, y] or SNOW_TILE) != SNOW_TILE
end
HermesPasser comentou:esqueci de postar aqui ontem. É culpa do sono hehehe. Uma azul
Brandt comentou:Estou ciente desse aspecto da linguagem (como você mesmo apontou), mas também não vejo de que forma isso prejudica o código.
Muitas vezes fica até meio ruim de entender a intenção de uma função em Ruby quando o retorno é implícito e a expressão retornada é mais complexa (pode nem ser o caso, mas ainda assim).
Aliás, os próprios scripts padrão do RPG Maker por vezes fazem isso, vide linhas 24-26 do Window_Command:
Código:def window_width return 160 end
Claro, esses scripts também têm retornos implícitos, mas só pra exemplificar mesmo que na verdade tanto faz.
Brandt comentou:Arquivo Spriteset_Map (padrão do RPG Maker), linhas 26-32:
Só segui o modelo proposto pelos próprios scripts que vêm com o RPG Maker. E na verdade esses Viewports não são só para o papai noel, pro caminho ou pro score, eles são as 1ª, 2ª e 3ª camadas da tela, que representam (mas não se limitam a) o chão, os personagens e a interface, respectivamente. A ideia é poder incluir mais coisas neles (inclusive, a neve e os obstáculos estão no viewport2 também), sem ter que mudar o nome da variável por ter deixado de fazer sentido ou criar uma nova mesmo. Aliás, se cada Viewport servisse só pra um objeto, não tinha nem porque ter Viewports em primeiro lugar x)Código:def create_viewports @viewport1 = Viewport.new @viewport2 = Viewport.new @viewport3 = Viewport.new @viewport2.z = 50 @viewport3.z = 100 end
HermesPasser comentou:
HermesPasser comentou:
CleanWater comentou:Caixa azul, manda o desafio. ^_^
Resque comentou:- O jogador precisa convencer os NPCs a comprarem suas rifas, que valem uma cesta de natal;
- Cada NPC necessita de diálogos e missões específicas para ser convencido a comprar a rifa;
- Um tempo limite para a venda das rifas deve ser adicionado, se acabar e nem todas foram vendidas, fim de jogo;
- O sistema precisa gerar o ganhador da rifa aleatoriamente, para que não haja repetição nos resultados;
- O sistema deve ser configurável para que:
1) A quantidade espaços na rifa seja customizável.
2) NPCs sejam adicionados/excluídos.
HermesPasser comentou:Resque comentou:- O jogador precisa convencer os NPCs a comprarem suas rifas, que valem uma cesta de natal;
- Cada NPC necessita de diálogos e missões específicas para ser convencido a comprar a rifa;
- Um tempo limite para a venda das rifas deve ser adicionado, se acabar e nem todas foram vendidas, fim de jogo;
- O sistema precisa gerar o ganhador da rifa aleatoriamente, para que não haja repetição nos resultados;
- O sistema deve ser configurável para que:
1) A quantidade espaços na rifa seja customizável.
2) NPCs sejam adicionados/excluídos.
Essa é a que eu tinha dropado
HermesPasser comentou:Um azul E UM FELIZ NATAL
e as namoradinhas?
Sistema | Participante | Pontuação |
Tree | [member=1330]HermesPasser[/member] | 175P. |
Jogo da Velha | [member=1330]HermesPasser[/member] | 193P. |
Fish | [member=1330]HermesPasser[/member] | 171P. |
Sistema de fogueira | [member=1330]HermesPasser[/member] | 174P. |
Luzes e Gerador | [member=1330]HermesPasser[/member] | 185P. |
Hole | [member=1330]HermesPasser[/member] | 178P. |
CleanWater comentou: