Oi pessoal, eu sou estudante de Desenvolvimento de Software, e estou pensando em fazer um jogo em java, já procurei em outros luigares, mas encontrei pouca informação, por isso queria que alguém me desse uma opnião, alguma dica, algum método para mudança de telas, experiências, qualquer coisa serve. O jogo é simples, inspirado naqueles velhos “joguinhos de tela” feitos para DOS, onde você digita suas ações, “pegar”, “olhar”, “falar”, etc. num terminal na parte de baixo da tela, e na parte de cima fica a tela, que na verdade é só uma imagem estática de uma sala ou um outro ambiente qualquer. Acho que vou ter dificuldades na formação das palavras chave, as ações.
na verdade… esse é o tipo de jogo mais facil que vc pode criar heheh
a tela estatica… nao vai ser nada alem de uma imagem…
embaixo… pode criar um textfield para o jogador digitar as ações…
e um textarea para mostrar as ações disponiveis, e todo o texto que o jogador precisaria ler…
poderia ter uma list de Strings com as palavras chaves para determinadas ações…
classes como ações… ou mochila (se vc pretende usar esse tipo de sistema)
tem um jogo chamado World of Zuul
que é praticamente oq vc ker fazer…
o codigo fonte em Java dele tem na net, só não lembro onde… o Google ajuda =)
Classes como ações? É uma boa idéia, eu pensava em objetos como ações, obrigado pela dica. O que é mochila mesmo?
PS: Quem tiver mais alguma coisa pra me ajudar poste aí.
Mochila seria uma classe q guardaria arrays de Item…
que são os itens que o personagem carrega durante a jornada… (chave, tocha, espada, etc…)
então teriamos mais 2 classes
Mochila
Item
onde vc tb poderia fazer os itens serem classes… (classe Espada, classe Tocha, classe Chave…)
aconselho isso depois que vi o codigo fonte de um jogo de PC…
fazendo cada Classe de Item separadamente, e extendendo a classe ‘Item’, e implementando algumas interfaces de acordo com o tipo do Item… vira uma ferramenta bem poderosa…
pode parecer complexo agora… mas vai facilitar muito futuramente
Uma dica… procure se informar sobre uma linguagem de script. Costuma a facilitar muitíssimo o desenvolvimento de jogos como esse.
Você faz toda “engine” do jogo no Java, mas a história mesmo do jogo e o desenrolar do game, você faz na linguagem de script.
Eu andei vendo o código do jogo World of Zuul, e achei uns bons exemplos lá, um dos exemplos é a classe Game, que seria o main do jogo, também seria onde eu “narraria” o jogo, tipo, eu começo na sala 1, onde tem uma cadeira, então no começo da classe Game eu chamaria a sala 1 por default, e chamaria o item cadeira, aí se o cara apertar o botão ‘frente’, chamaria a próxima sala, e assim por diante. Outro exemplo legal é os estados do item, removível, combinável, para formar outro item, etc, eu acho que não vai ser tão complicado de fazer esse último, o que vocês acham?
é bem simples de fazer…
se vc criar uma classe para cada objeto…
nele mesmo vc poderia implementar algo chamado Combinavel…
essa interface poderia estar vazia…
e uma outra classe ( CombinarItem ) faria a combinação… .
ela recebe 2 objetos… verifica se ambos pertencem a interface Combinavel…
se sim, faz a mesclagem e retorna o terceiro Item…
isso pode ser muito vantajoso em Ações tb…
terá uma lista de golpes…
Soco, Bola de Fogo, etc…
Soco extends Item implements CombateCorporal, ArteMarcial, AtaqueFisico
BolaDeFogo extends Item implements Fogo,Magia
a interface Magia por exemplo… poderia exigir uma int chamada PotenciaMagia… q afetaria o Dano causado…
executando a ação em determinado alvo…
ele poderia achar as informações mais facilmente, sem necessitar criar boolean infinitas e desnecessarias em todas as classes…
vejamos:
Vejamos:
public class Item
{
private String itemDesc;
private boolean removivel;
private boolean combinavel;
public Item (String descricao, boolean rem, boolean comb){
this.itemDesc = descricao;
this.removivel = rem;
this.combinavel = comb;
}
public String getDesc()
{
return "Você pegou um "+itemDesc;
}
A idéia de ataques foi uma ótima idéia, como isso é um RPG eu não pensava em combate corporal, valeu. Vejamos, acho que serão dois tipos de ataque: corporal e magia, mudando somente o tipo e a potência, acho que por enquanto tá legal. Mas se os golpes terão dano, isso quer dizer que eu vou ter algo do tipo, uma barra de energia, ou mesmo pontos de vida na tela, mas só pra incrementar, como ficaria uma barra de energia? Lembrando que o objetivo é fazer uma coisa simples, afinal, é um jogo de telas.
bom… se o jogo for em Texto… mostraria PV: 10 / 20 (exemplo)
se vc kizer fazer algo grafico…
vai precisar de um leve toque de matematica… e desenhar na tela… dah um pouco mais de trabalho…
veja sobre Graphics 2D … dentro de um JPanel…
aqui no forum tem exemplos de como desenhar em um JPanel…
seria apenas criar um Retangulo (borda) com um segundo retangulo dentro, que o comprimento dele é a % de vida restante…
e por ai vai…
mas perfumaria deixa pra depois… o importante é vc começar a fazer o sistema em si =)
lembre de fazer a Classe Personagem
onde vai guardar os pontos, PV, MP, EXP e etc…
e a Classe Monstro que poderia ser uma class Abstract… se vc kizer usar o mesmo sistema de Ações e Itens, poderia criar uma classe para cada monstro e Implementar as suas caracteristicas especiais…
ficaria… Aguia extends Monstro implements Voador,Animal
monstro apenas para herdar PV, MP e etc…
voador e animal são caracteristicas… que no caso poderia herdar meios de ser imune/fraco a certo tipo de dano…
enfim… ideias infinitas :lol:
se não quizer poluir o forum… pode mandar duvidas por MP que respondo…
Eiii… mandar mensagem aqui não polui o fórum, bem pelo contrário, complementa!
E eu também posso acompanhar a discussão! 
[quote=Maracuja]LUA
hehehehehehehehehehe[/quote]
Lua em Java não presta.
Pelo menos, não comparado ao Groovy e outras linguagens que se aproveitam dos recursos da VM.
Aliás, não vi nada de tão interessante assim no Lua que justificasse ela para C++ também. Existem outras linguagens como Squirrel, Python e TCL que oferecem mais recursos, com tantas facilidades quanto e com OO nativas.
Talvez para C, sei lá.
Vejamos:
//Classe Item
public class Item
{
private String itemDesc;
private boolean removivel;
private boolean combinavel;
private boolean pego;
private int dano;
public Item (String descricao, boolean rem, boolean comb, boolean com, int hits){
this.itemDesc = descricao;
this.removivel = rem;
this.combinavel = comb;
this.pego = com;
this.dano = hits;
}
public String getDesc(){
return itemDesc;
}
public boolean removivel(){
return removivel;
}
public int getDano(){
return dano;
}
}
//Classe Pedra
public class Pedra extends Item{
public Pedra(String descricao, boolean rem, boolean comb, boolean com, int hits) {
super("pedra", true, true, false, 1);
}
}
/*Certo, o personagem terá pontos de vida e de magia, mas não terá experiencia,
- a evolução virá com a subida de níveis, etc.
*/
public class Personagem{
private boolean pe;// sentado ou em pé
private int PV;
private int PM;
public Personagem(boolean pe, int pv, int pm) {
this.pe = pe;
PV = pv;
PM = pm;
}
}
estou com dificuldade no seguinte: Java não tem herança múltipla, como faço pro personagem chama pedra e golpes, etc.?
certo… vamos setar essa conversa como “Public” então uahuahuah
eu faria da seguinte maneira… a parte de itens…
parece complicado… mas imagine a gama de possibilidades…
(vou explicar primeiro e deixar as classes no final no post)
digamos que vc use o metodo convencional…
criar um item chamado Espada…
que terá pelo menos umas 10 booleans, para dizer se é Equipavel, combinavel, mastigavel, causa dano de fogo, anti-mortosvivos e por ai vai… coisas normais em um jogo de RPG
se vc diz que todas essas Booleans vem de uma classe Item… então todos os itens ocupam na memoria essas 10 variaveis boolean, 10 variaveis int… que inclui o dano, durabilidade, defesa, bonus Força, bonus Agilidade, bonus Magia… e por ai vai…
ou seja, todo Item acabará tendo obrigatoriamente q ser setado todas essas variaveis… oq é muito chato e improdutivo
supondo q vc tenha uns 100 itens carregados pelo seu personagem, então vc estaria usando quase 500 Ints, booleans e por ai vai, em um jogo de grande porte q utilizaria pelo menos 100x mais, isso seria um belo peso extra na sua memoria, podendo até dar um OutOfMemory se chegar ao extremo…
o modo via Heranças, Interfaces
(seguindo o exeplo que fiz abaixo)
existe uma classe chamada Item, ela é DEUS, todos os itens dependem dela, e ela só possui oq é exatamente necessario existir em cada item. Nome e Descrição (pode adicionar mais se sentir necessidade)…
então crio o Item Pedra, como vc disse, ela é um item Combinavel, utilizo o “implements Combinavel”… se ela não tiver nada demais alem de ser combinavel… veja que na classe dela vc não precisa setar mais nada, alem do Nome e Descrição…
faremos agora uma Arma… criamos a Espada…
Armas vão ser coisas comuns no jogo, então para generalizar criamos a Abstract class Arma que Extende a classe ITEM já que todos itens existentes precisam de Nome e Descrição…
e ela Implementa EQUIPAVEL, já que toda arma por natureza deve ser equipavel…
ela possui inicialmente 2 coisas (vc cria mais depois)
1- o Dano da arma…
2- e a posição do corpo onde o item será equipado, considero que é a posição da mão Direita é 0… (podemos dizer que 1 é escudo, 2 capacete e por ai vai)… como a ARMA sempre será na mão direita (normalmente, e não considerando equipar 2 armas) podemos definir que ARMA carrega um atributo FINAL setado em 0…
feito a classe Arma, faremos a Espada…
Espada extends Arma (já que Espada é uma arma que por sua vez extende um Item… então toda Espada é um Item tb)
e ela alem de possuir o setNome e setDesc…
terá o especial que apenas as Armas possuem… o setDano…
(crie metodos a vontade para desenvolver o seu jogo)
desculpe o tamanho do post… mas é complicado simplificar… uahuahuah
duvidas, pergunte =)
//Interfaces Equipavel e Combinavel
public interface Equipavel {}
public interface Combinavel {}
// Classe Espada
[code]public class Espada extends Arma {
public Espada() {
setNome("Espada");
setDano(10);
setDesc("Arma simples");
}
}
[/code]
//Classe Pedra
[code]public class Pedra extends Item implements Combinavel{
public Pedra() {
setNome("Pedra");
setDesc("Pequena Pedra");
}
}[/code]
//Classe Abstract Item
[code]public abstract class Item {
private String nome;
private String desc;
public final String getDesc() {
return desc;
}
public final void setDesc(String desc) {
this.desc = desc;
}
public final String getNome() {
return nome;
}
public final void setNome(String nome) {
this.nome = nome;
}
}[/code]
//Classe Abstract Arma
[code]public abstract class Arma extends Item implements Equipavel {
// Supondo que a posicao de equipamento onde vc poem a Arma é 0
// 1 para Escudo, 2 para Capacete e assim por diante
final int posicaoCorpo = 0;
private int dano;
public final int getDano(){
return dano;
}
public final void setDano(int dano){
this.dano = dano;
}
public final int getPosicaoCorpo(){
return posicaoCorpo;
}
}[/code]
só para mostrar como vc utiliza o Interface no meio do Jogo…
usando o instanceof vc consegue saber se a classe pertence a alguma interface…
(codigo abaixo)
o usuario tenta equipar a Pedra…
o sistema pergunta Pedra é Equipavel ? (ped instanceof Equipavel)
Não! então mostra erro…
o usuario tenta equipar a Espada…
o sistema pergunta Espada é Equipavel ? (esp instanceof Equipavel)
Sim! então equipa…
isso economiza MUUUITA variavel…
[code]Pedra ped = new Pedra();
Espada esp = new Espada();
System.out.println(ped.equals(esp)); //false
System.out.println(ped instanceof Item); //true
System.out.println(ped instanceof Equipavel); //false
System.out.println(ped instanceof Combinavel); //true
System.out.println(esp instanceof Item); //true
System.out.println(esp instanceof Equipavel); //true
System.out.println(esp instanceof Combinavel); //false[/code]
se certa Espada por acaso causa dano de fogo…
então vc cria uma interface dizendo Flamejante (por exemplo)
na hora que vc precisar saber algo da Espada… basta por (esp instanceof Flamejante) e vc saberá sobre ela…
e por ai vai =)
[quote=Fragata]
/*Certo, o personagem terá pontos de vida e de magia, mas não terá experiencia,
- a evolução virá com a subida de níveis, etc.
*/
public class Personagem{
private boolean pe;// sentado ou em pé
private int PV;
private int PM;
public Personagem(boolean pe, int pv, int pm) {
this.pe = pe;
PV = pv;
PM = pm;
}
}
estou com dificuldade no seguinte: Java não tem herança múltipla, como faço pro personagem chama pedra e golpes, etc.?[/quote]
vejamos…
public class Personagem
provavelmente ele terá alem de PV e PM, alguns atributos? Força, Inteligencia e etc… mas isso é apenas implementar na classe…
por ele ser uma classe digamos, primitiva, não haveria muita necessidade de implementar algo nele, já que será apenas 1 instancia dele, sendo assim, Unico!
ele poderia ter uma classe dentro dele, chamada Mochila…
que no caso Mochila possuirá uma ArrayList…
Mochila fará todo o controle de itens do personagem, como adicionar na mochila, usar item, mostrar lista de itens, e por ai vai…
o termo “usar item” leva os Itens a poderem ter outra Interface “Usavel”…
poções de cura são usaveis, tanto em combate quanto fora…
armas e pedras são? depende do criador do jogo achar funcionalidade para elas serem usadas fora de combate… já q de qualquer maneira a Espada já será usada por estar equipada em 1 combate… e a Pedra é um item Combinavel, então não precisaria ser exatamente Usavel…
o Personagem tambem, poderia ter um classe chamada Poderes/Golpes/Magias ou como preferir…
ela faria todo o controle dos PoderesConhecidos que o personagem conhece… exatamente como funciona a Mochila…
essa classe PoderesConhecidos, poderia possuir uma ArrayList
onde segue a mesma logica de Item…
class BolaDeFogo extends Poder implements Ataque,Magia,Fogo
a interface Ataque, permitiria que o poder fosse usado para causar dano…
supondo que fosse uma magia de Cura, ela teria a interface “SELF” (sei lah como poderia ser em portugues, “si mesmo”? :lol: ), oq permite vc ser o Alvo de seu proprio poder…
Magia indicaria que é um dano magico, ou seja criaturas poderiam ser imune total ou parcialmente… e por ser Magia poderia exigir que vc perca PMs…
e Fogo indicaria que o alvo poderia ter fraqueza contra determinado elemento…
Uma boa idéia também é criar uma “classe” para seu item, e salvar só as modificações.
Por exemplo, você cria o ItemType “Espada da Fênix” que já contém:
Ataque: 15
Dano de fogo
Dano por corte
Durabilidade 30
2 slots
Combinável
Isso representa um tipo de item, não o item em si. O item teria o seu tipo e os modificadores, se existissem. Por exemplo, um item poderia ter um modificador dizendo que, além de ser uma espada de fogo, ele tem ataque ampliado em 50%.
Isso sim, economiza uma quantiadade “agressiva” de variáveis, sem complicar muito o código. O segundo método, apesar de usar interfaces e herança, é meio desengonçado. E geralmente temos que evitar usar herança (ela gera acoplamento forte).
[quote=ViniGodoy]
Isso sim, economiza uma quantiadade “agressiva” de variáveis, sem complicar muito o código. O segundo método, apesar de usar interfaces e herança, é meio desengonçado. E geralmente temos que evitar usar herança (ela gera acoplamento forte).[/quote]
não acho desengonçado… pelo contrario…
com o costume vc tem uma facilidade muito maior em desenvolver caracteristicas proprias para os itens…
alem de q, não utiliza booleans que vão ficar preenchendo sua classe…
deixa o codigo mais limpo…
sobre permitir caracteristicas especiais na arma… é seguindo o mesmo fluxo…
basta implementar a classe Arma com os supostos “bonus” possiveis…
jah q nem todos os itens obrigatoriamente vão ter a possibilidade de bonus…
usar o minimo possivel de variaveis e somente o necessario, faz diferença…
O problema de basear em herança é que herança gera um relacionamento forte entre as classes. E isso torna o código difícil de se manter com o tempo.
A forma como eu mostrei, com um tipo do item “base” e então variáveis só para os modificadores é bastante usada. Até porque, na grande maioria das vezes, os jogadores estarão portando somente o item base. Assim, o objeto do item dele ficará resumido apenas a referência para o item base + 1 lista de modificadores vazia.
Também fica mais fácil permitir que o jogador turbine o item posteriormente. Ele poderia comprar a “pedra das chamas” e, só adicionando um modificador a lista, tornar uma espada comum uma espada com “dano de fogo”.
Com interfaces, você fatidicamente começa a ter a necessidade de ter uma classe para cada característica do item, o que pode resultar numa explosão de classes.
Por isso, a forma com agregação (do tipo da arma base) + uma lista de modificadores se torna uma alternativa muito flexível. Fica fácil também adicionar modificadores completamente novos no futuro.
E a coisa fica mais interessante ainda, se vc criar um mecanismo para esse comportamento do modificador ser definido por script. Isso viabiliza até mods, no futuro.
não entendi a diferença na pratica…
exemplos de classes sem suas extensões ficaria como?
ou vc diz uma especia de Socket do diablo ?
vc adiciona um item “especial” a uma instancia de arma, onde esse item adiciona supostamente 5 de dano…
modificando assim a instancia da arma em especifica…
é isso?
pq oq eu penso é o seguinte…
temos o tipo de arma Espada…
toda espada obrigatoriamente teria algumas caracteristicas (algumas herdades da classe Arma) e outras especiais para a Arma… exemplo algo do tipo CurtaDistancia
independente de qqer outra espada desse mesmo tipo q exista, ela acima de tudo pertence a CurtaDistancia…
supondo q exista uma Espada da Fenix…
ela extende Espada, que por sua vez extende Arma…
essa espada da fenix carregaria suas caracteristicas, ou como vc diz, Mods…
ela alem de tudo, tem o dano de fogo, e outras habilidades extras…
mas não entendi a diferença no codigo, q vc diz…
A minha classe de item ficaria assim:
public class Item {
private ItemType type;
private List<Mods> mods = new ArrayList<Mod>();
}
Note que características como o Dano da arma não estão na classe do item específico. A hierarquia que vc está pensando seria a hierarquia de ItemType. Num jogo comum, haverão dezenas de “BasicSwords” com exatamente as mesmas características, coincidentes com as do item base. Então, não haveria porque termos a repetição desse atributo (e os custos de memória) para todos eles.
A classe FenixSwordType teria as características que vc falou. Mas com uma única diferença. Será necessário apenas uma única instância da classe FenixSwordType para representar diversos itens, de diversos jogadores. O ideal, inclusive, é que os objetos de ItemType sejam imutáveis. As modificações só ocorrem nos itens reais.
Aí vc cria para o jogador uma espada da fênix, e adiciona +5 a ela assim:
Item weapon = new Item(FenixSwordType.COMMON_FENIX_SWORD);
weapon.addMod(new AttackBonus(5));
Essa é uma implementação do padrão FlyWeight, que se resume a: Pegue os dados que são comuns, que vão se repetir direto e que quase não mudam, e separe em uma classe diferente. Então, ao invés de criar atributos para todos os itens com esses mesmos dados, acople um único objeto dessa classe previamente criado.
Detalhe, num jogo em rede, os ItemTypes poderiam estar no clientes. O servidor encarregaria apenas de enviar o ID do tipo. É claro que o servidor também teria que verificar danos gerados (para que alguém que altere o cliente não transforme um BluntSword em um SuperMegaFenixSpecialSword). Mas que isso já alivia a rede, já alivia.
Claro que nossa discussão contempla muito acima do que o colega pretente. Até onde eu entendi, ele não está fazendo nenhum MMORPG, portanto, não deve ter milhares de itens ou jogadores para que isso se torne um problema.