• 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.


  • Content count

  • Joined

  • Last visited

Community Reputation

1065 Excellent

About InferiorOlive

  • Rank

Personal Information

  • Location
    Wisconsin, USA
  • Interests


  • Twitter
  • Github
  1. Yeah, I wasn't asking for help coming up with a name. Sorry if my original post wasn't clear.
  2. Hi and thank you for your responses, but I don't feel that they're addressing my questions, which boil down to whether or not the name of a game is part of its overall design, and how so (or not so)? I don't really understand how this is a writing question.
  3. The game that I'm working on is nearing alpha release. Aside from cementing a couple of features and smoothing some rough edges, there's one thing that my game really needs: a title. I have a fairly clear idea of what the game is about, and a solid understanding of the mechanics at play, but I don't know how to turn all of that into a name. So my question might be best described as this: Do you consider the name of a game to be important to the game's overall design? Perhaps I should give an example? Two games that I have spent very little time with (so I'm sorry for how incorrect I may be) but seem to be mechanically similar but with dramatically different name concepts are Enter the Gungeon and Nuclear Throne. Nuclear Throne suggests environment and might prepare the player for a particular mechanic (scarcity of resources, perhaps, associated with a peri- or post-apocalyptic setting). Enter the Gungeon, however, is a play on words that sets the player up for a game that takes itself less seriously than a name that conveyed similar information about the game (about everything, enemies included, being guns or parts of guns or ammo) such as Shooting Gallery might convey but without the slightly silly tone. Also edited for clarity.
  4. @Tom Sloper: I'm not the one who down-voted you, but I'm curious about your responses. I guess part of my question that wasn't as clear as I could have made it is: with limited time and resources, at what point during development would I get the most out of bringing the art into strong consideration. Perhaps considering the art too early might result in many more ideas that don't pan out, or that scrapped due to changes in game-mechanics or design-direction, for example.
  5. I've been working on a project on-and-off for a while and I've just been using the free art that I can get on the internet to serve as placeholders during development (because I'm not much of an artist and I'm not sure of the aesthetic that the game should have). Most of the game-mechanics could fit a wide-array of settings and art-styles.   My questions are these:   1) As an artist, how much of a game's style and/or setting would you want to be established (and, I suppose, how established) before you started on the artistic design (visual, mostly, but I suppose this could also extend to music and sound-design)?   2) How early in development of the game (it's small enough that it's not really using an engine, so what would normally be considered engine-development would also fall under game-development), in terms of mechanics and scope, should the artistic design be started? I could imagine that while mechanics might influence the art, art might also inspire changes or addition/elimination of mechanics (maybe this isn't the case, though).   Since it's a 2D sprite-based game, I know at least the limitations inherent to that art-style, but I haven't really done anything beyond implementing simple sprites and animations, and I'm not sure what features would extend what I have in a meaningful way that an artist would really be able to appreciate and take advantage of.   I hope I was clear-ish, and thanks in advance for any feedback!
  6. I agree with Bregma.   The internet is an awesome resource for tutorials, but if you're just copying code, you're not necessarily learning; you can, though, learn a lot about the general architecture of a game (gameloops, for example) as those can be a little less intuitive (or maybe I'm just slow).   Further, I'd recommend against using an engine for basic games like those you mentioned, as they can strip away a lot of valuable learning opportunities to a new game-programmer (and nothing you'll be making for a long time will actually need or seriously benefit from an engine like UE4).
  7. I would suggest just making games. Test your skills with those tools to make a small game from start to finish; focus on the aspects that you'd want to showcase to an employer (do you want to be an artist? make the art stand out!).   Each position you apply for is going to want different things, but most of them don't want just "experience with x", they want "experience developing with x" (meaning working on a project as a whole, and often time shipping the project).   The absolute most surefire way (that may be an exaggeration) to find out what you need to do to get a job in game development is to look at job-postings (there are a lot of game-dev jobs posted on job boards on the internet) and look at what they want.
  8. A common method of achieving constant-rate logic updates (independent of rendering speed) is the fixed-timestep gameloop. This is an effect you can also achieve by enabling vsync (though this is generally not recommended).   In C#, to get the precise timing you'd want to implement a fixed-timestep you're probably going to have to use System.InteropServices to import some dlls to enable you to check the cpu tick-rate.
  9.   For starting out, and for creating a simple game like Pong, it is best if one doesn't directly go for tutorials. He should instead spend at least some hours on pen/pencil and paper trying to figure out how his game would work.   I didn't mean to imply that following a tutorial was the best idea. I was just providing options (and suggesting that there are existing answers to a lot of questions).
  10. What have you tried? Using a popular search-engine I found this set of tutorials (first thing it returned) for, what appears to me, your exact dilemma, but if you want to figure it out with a little less guidance, then asking more specific questions and telling us what has and hasn't worked for you is going to help us best help you.
  11. So how do you think these languages work? Each language translate to what the computer understand. I'm not saying noise is language instead when you imply rules to noise you could create language because the rules would transform into some meaning. Every language is translatable that doesn't mean its a one to one translation. One concept that will blow your mind is the ideal that subtraction can be done with just add operation. The ideas are basic things you want to convey. You can should be easily able to translate. Also you mentioned Functional vs OOP here you going on a tangent OOP is not a language but the rule on how to use a given language same with Functional. For instance Procedure vs OOP, C is procedural and C++ is OOP but if one looks closely one can see that you can still implement the same program in any of the two languages. However, C++ might make it easier for some problems. Functional languages are built around solving a problem on the ideal of functional tuning. This isn't to say that procedural programmer can not learn the language and not be able to solve the problem procedurally. They could also learn an opposite program tackle it from another prospective. Prospective is what you having problems with and that is common because some people can see the smaller points and not the larger picture. If you study language you will soon see the whole picture of both small sub parts and large parts. As human continue to invent one must say how was it done in the past. We see that we hardly ever invent thing that bring new concepts not tried. We have cell phones but we can trace back to telephone then telegram and so on.   I'm going to say that a library is not the language you miss understanding what is language and what is created by the language. The language is the things that is allowed to be correct. the statements, the creation of variables, and other features.   CFG is how the language is parsed while this is what the compiler does but what else does the compiler do? It translates. CFG stands for context free grammar not all language are context free. But the cfg will make up the language. Lets look at English what constructs a simple sentence? Subject verb object. But you should ask what makes these parts different and there lies things called grammam rules. ?   On the one hand, I think that you're more or less correct, that you can technically write a program in one language and approximately port it to another language (there are probably exceptions to this, but it's not something I've looked deep into, so any clarification or examples of exceptions would be appreciated). BUT that does not mean that it will work in the same way or have anything resembling a similar layout or architecture. I think if you consider it more close to translating between a language like English and a tonal language like Mandarin, such that one phoneme can have multiple meanings based on the intonation. Yes, you can technically translate between the two, but the translator must have a mastery of both language-styles (tonal and... atonal?) to do so. As such, this is a non-trivial task.   You originally suggested that the translation from one language to another is primarily syntactic, which is where you are less correct. While syntax does differ between languages, many other aspects differ to an equal or greater degree. To assume that rosettacode can substitute practice and experience with a given language is farcical.   Edit: what happened to selective quotes?
  12. C# and Java are about as similar as two languages can get, and the differences between them may feel rather arbitrary for the early stages of learning the language. I learned C# first and making a game in Java has since been mostly a matter of determining what the syntax equivalents for C# methods are. There are some nuances that make C# more attractive to me (the ability to pass by reference, for example; edit: to be more clear, Java passes references by value, whereas C# passes references by reference), but I'm not sure how necessary I would feel that was if I had learned Java first.    Ultimately, choosing between those languages is not going to be one of the more important choices in your life, and, if you like programming, it won't be the last time you choose which language to learn. They're both capable and they both do a lot of things, some things better than others, but they won't be the limiting factor on what you can accomplish with them for, probably, a very long time.
  13. If all you care about is logic, then I think that something like Unity or Unreal or whatever engine in that vein will work for you. I've never worked with any of those (because that's not my jam) but if you look at the games that are made using those engines, you can see very clearly a broad spectrum of genre, complexity, and quality.    As to your other questions: often times multiple languages are used on a project, but not necessarily all for the code that winds up being shipped. I know that C#, for example, is sometimes used to make tools for the developers that aren't released with the game.   A game map is, roughly, a series of vertices and the triangles that they form. How those triangles become a world that your character moves around in is entirely up to you, but generally involves collision detection and response, input handling and response, and whatever else you might need. This isn't even considering that the world is visible, which requires texturing and rendering all (or at least some) of those triangles.
  14. You've been asking a lot of questions lately, which is really what this forum is for, but it doesn't seem like you're figuring much out without our help. If you're going to be any sort of programmer (or any sort of anything, really), you need to figure out how to figure some of this out for yourself.   It sort of doesn't really sound like you have a good enough understanding of programming in general to start making games. Even simple games (pong) are fairly complex compared to what a lot of for-beginners tutorials and books teach you. It might be worth at least having a general understanding of how to solve these problems on your own: using documentation, for example, to at least make sure that you're using your tools correctly before you ask others to figure your code out for you.   We've all been beginners, and all of us are beginners at something. You're not going to improve, though, if we keep finding your bugs for you.
  15. This article breaks down the efficiency of several different solutions, though in relation to a different problem.