• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

GeekusPrimus

Members
  • Content count

    2
  • Joined

  • Last visited

Community Reputation

138 Neutral

About GeekusPrimus

  • Rank
    Newbie
  1. Unity

    I got my entrance into programming through GameMaker.  Using drag 'n drop to build some simple games made me want to learn GML to make more complex games.  I eventually started exploring making 3d games with GameMaker, and my desire to make bigger and better things led me to learn C++ and Java (actually, it was in that order, believe it or not) as well as a little Python (I've never needed it a whole lot, so I never did a whole lot with it).  In other words, GameMaker got me into programming.  GameMaker is the reason I'm majoring in computer science.   My brother and I started working on a game a little while back, and we chose Unity to do it.  Why?  Because he doesn't know coding and I didn't feel like writing an engine that only I would be able to use.  I can do all the C# scripting and let him throw the actual game together using the assets and some ready-made components rather than make him draw stuff on graph paper for me to manually input myself.   Game making tools are just that: tools.  They don't replace the whole process, they just make it easier.  Throwing something together in pure code is a satisfying feeling, but would you rather reinvent the wheel every time you make a game just to get a spinning cube casting a shadow on a plane, or would you rather actually make the game?   I understand the DIY attitude.  I'd love to sit down and program a complete game engine with advanced resource management, clever optimizations, an awesome graphics renderer packed with every goodie you could want, a handcoded physics engine designed to offload computations onto the GPU through compute shaders, and an audio system that interacts with the physics engine to simulate how sound actually behaves.  Then again, I'd also like to spend my free time making games instead of worrying whether or not my scene graph is efficiently batching my drawing calls or if I can cut down on my CPU overhead by writing my own math library in assembly.   In other words, game makers are just time savers.  It's the same thing as using a belt sander instead of a piece of sand paper.  It's faster and often does a better job than you could have done alone.
  2. So often games are excluded as an art form.  Perhaps it is because early games were so limited by computer capabilities that many games ended up simply as digitized versions of sports, board games, or a child's playtime.   However, the games that are treasured as the greatest ever made such as Final Fantasy (particularly IV, VI, VII, VIII, and IX), The Legend of Zelda, and countless others, are treasured because of the compelling adventures integrated into the games, not just the thrill of using an enormous meteor to destroy one's enemies.  Games like Call of Duty will be remembered perhaps as technical achievements (much like Tron is remembered in the film industry as a fancy light show), but never as compelling masterpieces that should be played in spite of the imperfections present.   This is not to suggest that all games should be completely story-driven.  Let's use Mario as an example: Mario's story has been largely the same (with a few exceptions) since he was called "Jump Man" in Donkey Kong: Princess Peach has been kidnapped by <insert villain, usually Bowser, here>!  You must save her by jumping on Goombas, collecting stars and coins, eating psychedelic mushrooms, and completing platform levels!   Now let's turn Mario into a story one would expect in an RPG: Princess Peach has been kidnapped by Bowser, King of the Koopas, and is holding her for ransom to extort money and control the Mushroom Kingdom.  As one of the few people in Mushroom Kingdom that doesn't have a debilitatingly large cap on his head, Mario must save Princess Peach!  However, on the way he discovers Bowser is being manipulated by the wicked Birdo, who is using Bowser as a tool to build a fortune and build an army of Birdo-bots (I'm grasping for straws here) to enslave all Mushroom folk, destroy all Koopas, and eventually help her overrun not just Mushroom Kingdom, but the neighboring kingdom of Hyrule (I'm really jumping the shark now)!  When Mario finds this out, he reveals it to Bowser, who he must now team up with to defeat Birdo.  However, the entrance to Birdo's castle requires Mario and Bowser to find the seven Diamonds of Goomba, which, ironically, Birdo has been searching for in her quest for global conquest.   I could go on and on, but eventually it just doesn't fit the game anymore.  Suddenly the beautifully simple story and gameplay of Mario has been compounded and distorted into a complex story that just doesn't work with an overweight plumber in a red shirt and blue overalls that hits boxes with his head to get mushrooms.   I'm rambling at this point, but I guess what I was saying is that games are truly an artform.  It requires the perfect balance of story, gameplay, and artistic style to create a masterpiece, and that is why games like Call of Duty will never outlive Half-Life.
  3. I guess I'm not very experienced, but I would question the credibility of a "game development" degree from anything but a proper four year university.  Considering most advertised game development degrees are from for-profit universities like Full Sail and cookie-cutter laughing stock trade schools, I highly doubt a degree saying you know how to make games will hold any water with an industry.  From what I know, most developers want a computer science or a computer engineering degree because it represents the ability to learn, problem solve, and code semi-competently, but not necessarily because it means they can code games.  Employers care more about your portfolio and your experience, I would imagine.  The last nail in the coffin for me is that very few self-respecting four-year institutions want to touch game development with a thirty-foot pole.   How do you make a degree for an industry that is constantly changing?  A game is a joint effort between programmers, artists, musicians, and the creative nuts who don't fit in anywhere else.  Games are influenced by all of these people.  There is no magic formula or special degree that can teach the creativity and ingenuity that extends from placing a hundred completely different people in the room together and telling them to come up with an awesome game.
  4. Thanks for the article!  A buddy and I are working on what will hopefully be our first commercial indie game, and it's great to get advice from people with experience.  We've been trying to figure out what makes games go viral, and this is great to know.  Even if it doesn't go viral, it's nice to know the indie market has gotten big enough that a game can still do moderately well.
  5. I'm not incredibly experienced, so this may be a royal pain on larger systems, but it may or may not be beneficial to try maintaining a list of meshes containing references to a particular texture or shader.  Presumably you would place this list in the wrapper class for shaders and textures, and then when it comes time to render, your rendering list can go through the texture pool to grab each texture, bind it, then render the objects using that texture, unbind, then repeat the process with your other meshes.  This way you can lessen some of the sorting pains that would normally occur at render time.  Of course, you wouldn't necessarily be able to do that for anything requiring alpha blending, but that is a black art in of itself (I guess recent API updates to DirectX and OpenGL allow for order-independent rendering of sorts, but I don't think OpenGL ES has received this sort of attention yet).