Referências bibliográficas para C

Reference Style – All Levels



Above Intermediate

+infos(lista completa): LINK

Tags : ,

Referências bibliográficas para C++

Introductory, with previous programming experience

  • C++ Primer * (Stanley Lippman, Josée Lajoie, and Barbara E. Moo) (updated for C++11) Coming at 1k pages, this is a very thorough introduction into C++ that covers just about everything in the language in a very accessible format and in great detail. The fifth edition (released August 16, 2012) covers C++11. [Review]
  • A Tour of C++ (Bjarne Stroustrup) The “tour” is a quick (about 180 pages and 14 chapters) tutorial overview of all of standard C++ (language and standard library, and using C++11) at a moderately high level for people who already know C++ or at least are experienced programmers. This book is an extended version of the material that constitutes Chapters 2-5 of The C++ Programming Language, 4th edition.
  • Accelerated C++ (Andrew Koenig and Barbara Moo) This basically covers the same ground as the C++ Primer, but does so on a fourth of its space. This is largely because it does not attempt to be an introduction to programming, but an introduction to C++ for people who’ve previously programmed in some other language. It has a steeper learning curve, but, for those who can cope with this, it is a very compact introduction into the language. (Historically, it broke new ground by being the first beginner’s book to use a modern approach at teaching the language.) [Review]
  • Thinking in C++ (Bruce Eckel) Two volumes; is a tutorial style free set of intro level books. Downloads: vol 1, vol 2. Unfortunately they’re marred by a number of trivial errors (e.g. maintaining that temporaries are automatically const), with no official errata list. A partial 3rdparty errata list is available at (, but it’s apparently not maintained.

* Not to be confused with C++ Primer Plus (Stephen Prata), with a significantly less favorable review.

Best practices

  • Effective C++ (Scott Meyers) This was written with the aim of being the best second book C++ programmers should read, and it succeeded. Earlier editions were aimed at programmers coming from C, the third edition changes this and targets programmers coming from languages like Java. It presents ~50 easy-to-remember rules of thumb along with their rationale in a very accessible (and enjoyable) style. For C++11 and C++14 the examples and a few issues are outdated and Effective Modern C++ should be preferred. [Review]
  • Effective Modern C++ (Scott Meyers) This is basically the new version of Effective C++, aimed at C++ programmers making the transition from C++03 to C++11 and C++14.
  • Effective STL (Scott Meyers) This aims to do the same to the part of the standard library coming from the STL what Effective C++ did to the language as a whole: It presents rules of thumb along with their rationale. [Review]


  • More Effective C++ (Scott Meyers) Even more rules of thumb than Effective C++. Not as important as the ones in the first book, but still good to know.
  • Exceptional C++ (Herb Sutter) Presented as a set of puzzles, this has one of the best and thorough discussions of the proper resource management and exception safety in C++ through Resource Acquisition is Initialization (RAII) in addition to in-depth coverage of a variety of other topics including the pimpl idiom, name lookup, good class design, and the C++ memory model.[Review]
  • More Exceptional C++ (Herb Sutter) Covers additional exception safety topics not covered inExceptional C++, in addition to discussion of effective object oriented programming in C++ and correct use of the STL. [Review]
  • Exceptional C++ Style (Herb Sutter) Discusses generic programming, optimization, and resource management; this book also has an excellent exposition of how to write modular code in C++ by using nonmember functions and the single responsibility principle. [Review]
  • C++ Coding Standards (Herb Sutter and Andrei Alexandrescu) “Coding standards” here doesn’t mean “how many spaces should I indent my code?” This book contains 101 best practices, idioms, and common pitfalls that can help you to write correct, understandable, and efficient C++ code. [Review]
  • C++ Templates: The Complete Guide (David Vandevoorde and Nicolai M. Josuttis) This is thebook about templates as they existed before C++11. It covers everything from the very basics to some of the most advanced template metaprogramming and explains every detail of how templates work (both conceptually and at how they are implemented) and discusses many common pitfalls. Has excellent summaries of the One Definition Rule (ODR) and overload resolution in the appendices. A second edition is scheduled for 2016. [Review]


  • Modern C++ Design (Andrei Alexandrescu) A groundbreaking book on advanced generic programming techniques. Introduces policy-based design, type lists, and fundamental generic programming idioms then explains how many useful design patterns (including small object allocators, functors, factories, visitors, and multimethods) can be implemented efficiently, modularly, and cleanly using generic programming. [Review]
  • C++ Template Metaprogramming (David Abrahams and Aleksey Gurtovoy)
  • C++ Concurrency In Action (Anthony Williams) A book covering C++11 concurrency support including the thread library, the atomics library, the C++ memory model, locks and mutexes, as well as issues of designing and debugging multithreaded applications.
  • Advanced C++ Metaprogramming (Davide Di Gennaro) A pre-C++11 manual of TMP techniques, focused more on practice than theory. There are a ton of snippets in this book, some of which are made obsolete by typetraits, but the techniques, are nonetheless useful to know. If you can put up with the quirky formatting/editing, it is easier to read than Alexandrescu, and arguably, more rewarding. For more experienced developers, there is a good chance that you may pick up something about a dark corner of C++ (a quirk) that usually only comes about through extensive experience.

+infos(lista completa): LINK

Tags : ,

Part-time game development and life balance por Ben Thumbs

Dei de caras na rede social facebook com um post onde estava referido este blog/pagina pessoal de uma Game Designer de nome Ben Thumbs. Ele descreve como é possivel ter três filhos, trabalhar, tirar um mestrado e ao mesmo tempo ser um game designer :)

Apresenta inclusive sugestão de calendário para organização do dia-a-dia :)

Uma dessas sugestões é:

Part-time game developer Mon – Fri example schedules

Early work commitments
4:00am – 6:00am Game development
6:00am – 7:00am Morning routine
7:00am – 5:00pm Work (& commutes)
5:00pm – 9:00pm Free time
9:00pm – 4:00am Sleep

Regular work commitments
5:00am – 7:00am Game development
7:00am – 8:00am Morning routine
8:00am – 6:00pm Work (& commutes)
6:00pm – 10:00pm Free time
10:00pm – 5:00am Sleep

+infos(oficial): LINK

Tags :

A explorar: Arduino & Node.js

Algo a explorar, usar o arduino com uma interface numa pagina web..

+infos: LINK

Tags : , ,

Pós-graduação: Mestrado em Engenharia em Desenvolvimento de Jogos Digitais

O Mestrado de Engenharia em Desenvolvimento em Jogos Digitais (MEDJD) destina-se a quem quer aprender as principais tecnologias de apoio ao desenvolvimento de jogos, mas também o respetivo design, análise e produção. Educamos profissionais que irão contribuir para o futuro dos jogos digitais, adaptando o estado da arte tecnológico a mecânicas e ao design, em função do seu significado cultural. Neste mestrado, os estudantes irão participar na experiência de criação de videojogos no Centro de Investigação e Desenvolvimento de Jogos Digitais do IPCA, tendo acesso a todos os laboratórios dedicados à área da produção, formando profissionais capazes de integrar esta indústria mundial.

Este Mestrado conta com o apoio da Full Sail University, uma das maiores universidades do mundo na área do desenvolvimento de jogos digitais, que assinou um acordo de colaboração com a Escola Superior de Tecnologia em Março de 2015.

Os projetos de investigação são abrangentes, podendo ser abordados temas puramente tecnológicos, bem como questões relacionadas com a cultura dos jogos, design de jogos, animação, ou a imersão e experiência de jogo.

Unidades Curriculares
Programação de Dispositivos Móveis e Multissensoriais
Inteligência Artificial para Jogos
Teoria de Jogos Digitais
Programação Concorrente
Projeto Integrado I
Motores de Jogos Digitais
Síntese e Reconhecimento de Voz
Realidade Aumentada
Som e Música Digital
Projeto Integrado II
Interação e Experiência de Jogo
Animação para Motores de Jogo
Empreendedorismo e Inovação
Metodologias de Investigação
Projeto de Dissertação
Projeto / Dissertação / Estágio
Horário Pós-laboral
Possibilidade de Bolsa de Estudo
Propina de 1.700 € (2 anos) *
30 vagas

+infos(oficial): LINKS

Tags : , ,

Texto: ODE AO BOM GAME DESIGNER por Isaque Sanches

Este texto relata o que é ser um bom game designer por Isaque Sanches:

— Há bons game designers e maus game designers.
— Ser um bom game designer não se aprende nem se adquire. Há quem nasça um bom game designer e quem não. Um bom game designer nasce ensinado, é um génio, e sabe fazer jogos geniais desde sempre.
— Um bom game designer não precisa de saber nada para além de game design. Algumas soft skills ajudam, mas só pouco.
— Um bom game designer, portanto, para além de não saber programar, não sabe também: ilustrar, animar, modelar, criar som, prototipar nem que seja em papel, fazer estimativas, multiplicar, somar, ou falar com outros seres humanos.
— Se um game designer for bom, o jogo “foi criado” por ele (embora na prática tenha sido desenvolvido por uma equipa). Há de sempre referir-se ao produto final como “o meu jogo”.
— Um bom game designer é manipulador. Tem que ser. Isto porque o seu papel é ser “a pessoa que dá ideias”. Se mais gente der ideias, então ele não serve para nada, logo ninguém pode dar input, fora ou dentro da equipa. Mas se ninguém dá input, começam a surgir frustrações, logo alguma manipulação é necessária para que toda a gente fique feliz, com a impressão falsa que a sua opinião interessa.
— Uma crítica para um bom game designer é uma afronta. Sobretudo se for por parte de um utilizador (jogador). Os jogadores não sabem se o jogo é bom ou não, e é preciso explicar-lhes porque é que tudo faz sentido. Sempre que alguém dá feedback, tem que surgir uma justificação.
— Numa equipa, só há um game designer. Isto porque um game designer também é o RP da equipa. E se uma equipa tem mais do que uma cara, então o público fica confuso. O papel do game designer, para além de explicar a toda a gente que o jogo é da sua autoria, como explicado na alínea acima, é apertar a mão a toda a gente, criar contactos, procurar investimento: é “vender o jogo”, de grosso modo.
— Embora um bom game designer não saiba programar, tem que saber dar input aos programadores. Para isso, tem que aprender alguns termos-chave sem, no entanto, entender o significado destes, ou o contexto em que são usados. Apenas para dar alguns exemplos: buffer, pacotes de informação, responsive, algoritmo, procedural, hashset, shader, “cliente-servidor“, input, collider, runtime.
— Embora um bom game designer não saiba fazer nada na prática, sabe um bocado de tudo no papel, seja qual for o tema, desde cinema, a análises de mercado, a História, Química, Filosofia, e até pesca: sabe tudo, porque tem que saber, porque faz jogos.

— Para um bom game designer “não, porque vi num episódio do Extra Credits que…” é a melhor forma de começar um contra-argumento.
— Um bom game designer não faz level design, não faz diagramas, esquema de mecânicas, não se preocupa com UI, nem se deve interessar em garantir que toda a gente na equipa sabe que jogo está a desenvolver. Um bom game designer vai corrigindo o que está mal. Por exemplo, vê o trabalho de outra pessoa, diz-lhe “isto não pode ser assim”, “manda”-o fazer outra coisa, sem no entanto explicar-lhe bem o quê ao concreto. Se decidir fazer trabalho produtivo, como por exemplo level design, terá que se feito antes da última milestone no calendário de produção, mas sempre depois da penúltima.
— Falando em milestones: um bom game designer sabe que são irrelevantes. São, porque um bom game designer é um deus. Quem decide quando o jogo está pronto é ele, não é o produtor, não é quem investe, não é quem produz conteúdo. Ele é que sabe das datas, por uma razão muito simples que muita gente não compreende: se na última semana entende que um projecto de meses ou anos é para ser todo mudado de uma ponta a outra, é isso mesmo que tem que acontecer.
— Um bom game designer não está sentado, como a ralé que é o resto da equipa. Está de pé, atrás de um programador ou um artista, a olhar para o que está a fazer, de pernas abertas, numa postura militar. Se o game designer for um homem tanto melhor, porque de pernas abertas exibe a sua virilidade e portanto autoridade melhor. Para não parecer um inútil prepotente, o game designer vai ou fazendo perguntas ou dando ordens a quem está à sua frente. As duas frases preferidas de um game designer são “um bocado mais para a esquerda” e “afinal, um bocado mais para a direita”.
— Um bom game designer conhece, usa e abusa da regra do 83%. Que diz, resumidamente que: um número inventado é mais credível quanto mais aleatório for. Por exemplo, diz-se antes sempre 81, 82, 83 ou 84, quando se inventa, nunca 80 ou 85. Concretamente: “fiz um estudo de mercado e 83% do nosso público-alvo…”.
— Para além dessa regra, sabe também que para conquistar é preciso dividir. Para ele, além de o jogo ser “o meu jogo” a equipa é “a minha equipa”. Para a equipa estar nas mãos do game designer, no entanto, este tem que garantir que o diálogo entre membros é mínimo, e passa quase sempre por ele, estilo pombo-correio. Sem esta ferramenta preciosa, o game designer não pode impedir ninguém contribuir criativamente para o jogo.
— E ainda sobre essa regra, há a variante fundamental que é o “diz que disse”. Resumidamente, de novo: o game designer tem uma ideia, fala com o José, pergunta-lhe o que acha, o José diz que sim, e diz à Mariana que o José teve uma ideia incrível, com a qual concorda. Pergunta à Mariana por outra ideia, ela diz “porque não”, e diz ao José que a Mariana teve uma ideia incrível, com a qual concorda. Por sua vez, fala então com o João e o António, que são doutro departamento, e diz-lhes que tanto ele, como o José, como a Mariana, os três, tiveram estas duas ideias, que são na verdade dele.


Tags :

Construir um jogo de RTS de quarta geração

Aqui está um artigo de apresentação do jogo Ashes of the Singularity, bem não é de apresentação deste jogo, mas de indicar um dos caminhos que os jogos de RTS têm ao seu dispor face às tecnologias que entretanto emergiram.

Os requisitos do Ashes são:
Sistema Operativo: 64-bit Windows 10
Processador: Intel Core i5 or Equivalent
Memória: 16 GB de RAM
Placa gráfica: 4 GB GDDR5 NVidia GTX 970 / AMD R9 390 or better
DirectX: Versão 12
Rede: Ligação à Internet de banda larga
Espaço no disco: Requer 13 GB de espaço livre
Placa de som: DirectX Compatible Sound Card
Notas adicionais: 1920×1080 Display Resolution or Higher


+infos(artigo): LINK

+infos(ojogo): LINK

Tags :

As 10 linguagens de programação que garantem trabalho…

De acordo com o artigo de as dez linguagens de programação que garantem trabalho agora e nos próximos tempos são:

+infos(artigo): LINK

Tags : ,


Repositório interessante em espanhol acerca da história dos videojogos:

Tags :

Unity assets

Aqui fica um referencial de alguns assets para o Unity, livres (free):

Não testei ainda nenhum deles apenas é uma colecção de referências.

Tags : , ,

MOOC interessante sobre POO

Aqui está mais um MOOC interessante sobre POO, com o nome de CS101.2x Object-Oriented Programming

+infos: LINK

Tags : , ,

Compilação de links..

Alguém se deu ao trabalho de compilar uns links relacionados com GameDev Tutorials..

Alguns exemplos na categoria GameDev Tutorials – Unity 3D

Devmag – 50 tips for working with Unity (best pratices)

Imgur – Unity 3D tips and tricks

Juicy Beast – Collisions for platforming

Gamasutra – “0-60 fds in 14 days!” What we learned trying to optimize our game using Unity 3D

Maildeveloper – Optimizing Unity games for mobile platforms

App Gruruz – Learn to Create Isometric games like clash of clans

Unity 3D – Reducing the file size of the build

Unity 3D – Physics best pratices

Unity 3D – How to make a physically real, stable car using WheelColliders


Tags : , , , , , , , , ,

Game Developers Conference Europe | 15-16 August 2016 | Cologne, Germany

Game Developers Conference Europe | 15-16 August 2016 | Cologne, Germany

Estão abertas as inscrições para a Game Developers Conference Europe 2016 :P.. gostava de lá dar um pulo!


Tags : ,

Gostava de ter acesso/access to your article

Gostava de ter acesso/access to your article,

Shaojung Sharon Wang and Shih-Jung Hsu (March 2016)
Not So Angry Birds: Psychological Benefits of Mobile Games

Netta Ganor and Dov Te’eni (January 2016)
Designing Interfaces for Older Users: Effects of Icon Detail and Semantic Distance

Tags : ,


A ler/consultar..

Atari to Zelda: Japan’s Videogames in Global Contexts por Mia Consalvo


+infos: LINK

Tags : ,

Contar numeros negativos e positivos num array usando ponteiros

#include <stdio.h>
#include <stdlib.h>

#define TAM 10

int  contarN(int *r, int s, int *pP, int *pN)
    int i;

    for(i=0; i < s; i++)
    printf("%d - %d \n", *pP, *pN);
    return 0;

int main()
    int tab1[TAM]= {0,12,2,333,-4,54,6,77,88,-99};
    int *a=tab1, numP=0, numN=0;

    contarN(a, TAM, &numP, &numN);
    return 0;

Tags : , ,

ainda ponteiros em C

int main()
 int a=0, b = 4;
 int *p;

 p = &a;
 printf("%d\n", *p);
 *p = b * 10; //estou a modificar o valor da variavel a
 printf("%d\n", *p);
 p = &b; //estou a modificar para onde aponta p
 printf("%d\n", *p);

 printf("%d  %d\n", *p, *p+a);

    return 0;

Tags : ,

Ponteiros (apontadores) em C

Coisas a saber sobre os ponteiros em C

tipo *nome_ponteiro;

operadores básicos:
&  -> para obter o endereço de uma variável
* -> aceder à variável para onde um ponteiro aponta

p1 -> o nome de um array é um ponteiro para o primeiro elemento. a[0] ou *a
p2 -> (aritmética de ponteiros) se existir um ponteiro a referenciar um elemento de um array, é possivel aceder aos restantes. (p+i)

int a[10]={0,1,2,3,4,5,6,7,8,9};
int *p=a;
vem que
a é o mesmo que &a[0]
a[i] é o mesmo que *(a+i)

resumo de operações sobre pointers:
atribuição ptr = &x;
incremento ptr=ptr+2 (2*sizeof(tipo))
decremento ptr=ptr-10 (10*sizeof(tipo))
apontado por *ptr
endereço de &ptr
diferença ptr1-ptr2
comparação ptr1>ptr2

Tags : ,

prenda? :)



Tags :


Tema: “Integration and deployment of video games in the classroom”, “Role of instructors”

Livro “Developments in Current Game-Based Learning Design and Deployment”: LINK

Tags : ,

The Evolution of Gaming 1957-2015

Tags : ,

Apresentação do Oculus Rift.. 3D

Aqui está uma das primeiras reviews sobre os óculos oculus rift, que permitem o desenvolvimento de aplicações para um ambiente imersivo.

+infos(site): LINK

Tags :

Livros sobre videojogos no MIT

Livros que gostava de ter acesso:

(2012)Characteristics of games
(2014)Computer games for learning: an evidence-based approach – 304p
(2014)Developers dilemma: the secret world of videogame creators – 352p
(2012)Engineering play
(2011)Handbook of computer game studies
(2011)In game: immersion to incorporation
(2014)Processing: a programming handbook 2nd ed
(2003)Rules of play: game design fundamentals
(2014)Values at play in digital games – 224p
(2015)Video games around the world – 720p
(2011)Educational Videogame Design – 120p – LINK
(2015)Uma Aula No Videogame – 288p – LINK

Tags :

Um blog a seguir

Este é um blog a seguir para quem quer desenvolver videojogos em Unity.. apresenta algumas soluções relacionadas com o desenvolvimento de plugins, cenários..


Tags : ,