Dê sugestões para um melhor desenvolvimento deste projeto.

Oi =)

eu tenho uma sugestão.. utilizar a codificação UTF-8 ao invés de iso-8859-1

tem gente q tem servidor pra fora do país q não disponibiliza codifiação europeu ocidental...

não é o meu caso pq nem servidor eu tenho =P... mas ja (tive) vi mt site dar pepino por causa disso... =\

hm, é uma boa idéia, fazermos uma configuração que permita alternar entre os charsets, e também não só possibilitar utf-8, ou iso, como também todas as outras possíveis.

hm, é uma boa idéia, fazermos uma configuração que permita alternar entre os charsets, e também não só possibilitar utf-8, ou iso, como também todas as outras possíveis.

=x

utf-8 eh padrão internacional pra web... e latin1(iso-8859-1) eh padrão mysql.. por isso sempre dá briga de charset qd precisa-se fazer a transição de dados normalmente eu resolvo tudo bem facil utilizando utf8_decode() antes das consultas SQL e utf8_encode antes de exibir o resultado em html... até agora foi a solução mais prática

sim, eu costumo utilizar isso também, tem funções próprias para banco de dados, que não precisa mexer nem na estrutura dele, e sim na conexão, depois faço isso

olha eu aqui denovo heheheheeh...

adorei os métodos estáticos.. ajuda numa globalização e torna-os espécies de 'comandos' online... maaaaaas... =)

sugiro.. uma espécie de plug-ins.. com métodos dinâmicos... não para todas as ações.. mas pelo menos para a parte de accounts... ajudaria na performance na hora de criar por ex. um account manager.... o player loga... e a partir daquele momento, dentro do acc man. cria-se um obj que trata apenas de particularidades daquela conta...

segue um ex...

player loga -> welcome.php

nessa pg... instancia-se uma classe dinâmica por ex. 'myAccount'

$account = new myAccount(Acc_ID);

as propriedades da classe podem ser as seguintes

$id = (int)999;

$password = (str)"senha";

$characters = array("nome"=>id,"nome"=>id,...);

$premium = (int)999;

fica mais rápido para utilizar os métodos globais já instanciados...

desculpa se to falando bobagem.. mas é que ainda não tive tempo de ler todos os return da API com a devida atenção

----

um edit, acho que mais pra bug report...

na listagem, contagem e procura de players... utilizar uma condição de 'where `playerID` > 1', para não contabilizar o Acc. Manager nas estatísticas... acho que vale também pra acc né... =)

ah, não posso fazer isso, pois não sei pra que que o programador vai usar a account class, quem saiba ele não quer criar um painel administrativo que mostre todos players?

já pensei em fazer isso sim, mas algo mais 'global' uma sessão para guardar informações do usuário, uma chamada de $_SESSION, se é que me entende.

Serialização de objetos e Sessions é obrigatório em qualquer account manager...

Ficar buscado o usuário na DataBase a cada pageview? Pavoroso.

os usuários desse fórum n se interessam pelo projeto, desanimei em desenvolvê-lo

serialização é um conceito avançado bacana, mas que não tem sentido sem ninguém usando a API pra fazer um site.

acho que n tem nenhum usuário que n seja programador e tenha interesse em programar por aqui