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

latent

Members
  • Content count

    99
  • Joined

  • Last visited

Community Reputation

139 Neutral

About latent

  • Rank
    Member
  1. Same story over here. Plus my focus at work is shifting a bit and that tends to affect what I do in my 'spare' time. Looking forward to more updates in the new year.
  2. The GUI is single-threaded. I simply check a flag at the start of the draw. If clear, I set it, draw, and clear it. No control's message processing within the draw can then cause the draw to restart. Taken further, if you're animating the draw from a timer or something, you can test the flag to see if you've already got a draw message in the queue.
  3. That's effectively the sort of state machine I've most often needed to use. Of course, you can code it any old way, such as swapping in a different state object, or a state function pointer, or whatever. The decision usually depends on how the rest of your application has been structured, and whether you want all state handling in one file or want it spread across several source files or classes. [source lang="cpp"] //in main loop pOnStateTick(this); //... //state function void StateWait(MyApp *app) { if (DoWaitStuff() == FINISHED) app->pOnStateTick = StatePathFind; } void StatePathFind(MyApp *app) { if (DoPathFindTick() == FINISHED) app->pOnStateTick = StateWait; } [/source]
  4. Another point of view - it's likely that 99% of a given developer's career will be spent modifying an existing codebase - whether that's adding new functionality or fixing issues. This is generally why the 'system analyst' role doesn't exist per se, because there's rarely giant new superstructures to design. This is also reassuring for the new developer, because when you start out, you start out working on existing code. So you learn coding and design practices as they apply to that product, and frankly it's pretty hard to stuff up one-liner new-guy tasks like "Change the form where it says 'Csutomer Sales' to 'Customer Sales'". And most places I've worked they expect the new guy to take like days to complete that job while he figures out their specific IDE, location of the code, how to fill out the job sheets and so on.
  5. [quote name='M0dSe7en' timestamp='1322523596' post='4888620'] [left]unfortunately the high school programming at my school is a joke and consists of a football coach that copies and pastes code off of google and presents everything in powerpoint [/quote][/left][left] [/left][left]That's sad. Though I suppose it's good motivation to learn to teach yourself, which in the tech industry is something you do year in and year out anyway.[/left]
  6. You can program a game on anything with a programming language. So the list could include C#, HTML5, VB, Javascript, Lua, Ada, Pascal, your programmable calculator, yada yada yada. There's like a discussion a day on programming language or game engine choices - and as there's obviously never so definitive an answer that it doesn't get asked again tomorrow, then I just suggest that you go with whichever one you're having the most fun with when you try it out. If you learn to program competently enough in that, moving to another language later will be easy.
  7. [quote name='AnotherFalseProphet' timestamp='1321985621' post='4886629'] However latency is incredibly noticeable and jitter can be seen with every key press. The how noticeable it is depends on the latency, obviously. [/quote] While I don't have an ebook to recommend, have you reviewed hplus0603's [url="http://www.mindcontrol.org/~hplus/epic/"]interpolation demo[/url] found via the [url="http://www.gamedev.net/index.php?app=forums&module=forums&section=rules&f=15"]FAQ[/url]?
  8. looking at the way they're warping, it looks like they're just a couple of texture layers blended on top of each other. Also your original link doesn't seem to work for me unless I remove the embedded tag. [quote name='Mode7James' timestamp='1321985575' post='4886627'] [media]http://www.youtube.com/watch?v=pIQLZsB5nfU[/media] [/quote]
  9. [quote name='Krunchyman' timestamp='1321912726' post='4886361'] I know enough C# keywords and operators that I wouldn't have to go back to basic tutorials but I lack "syntactical" skills and find it difficult to successfully arrange classes to create a game of epic stature, even if it's just a massive text adventure.[/quote] First, be open to these discussions of experience and time. Learning 'syntactical' skills and keywords and so on is a little like learning just enough French to understand sentence structure and/or find a word in a dictionary. Speaking it for years yields fluency and the ability to use common sayings that are outside the scope of educational material. In programming, we tend to develop 'patterns' - common approaches to problem solving which we can pick up and reuse to address similarly structured problems in future. While computer science education does tend to include a discussion of design patterns, there's no substitute for learning by doing, so just keep hacking away at it secure in the knowledge that even when you don't appear to be making progress, your skills are developing. Second, I also started young - maybe a little younger than yourself, and that was 25 years ago. My first programs were all games, and I still write games occasionally as a hobbyist. Programming taught me problem solving and analytical skills (and a little pragmatism) which I couldn't get in the classroom and which have resulted in a more than adequate income source and satisfying career. So if you can build it slowly and just have fun while you're doing it, you could put yourself into an enviable position when it comes time to hit the workforce.
  10. [quote name='MattCa' timestamp='1321864117' post='4886138'] P.S. An unrelated question, but how would I calculate a 3D point on a ray? I'm trying to figure out how I could do cube selection, but I can't find any good tutorials that don't use the functions already provided by glu or directx. [/quote] You could google for how to find the intersection of a parametric line with a plane, but for your purposes a simpler solution may suffice. Create an offscreen selection buffer, and render the closest (say 3 tiles out) blocks. Then just use the cursor position to get the pixel colour in the selection buffer, and use this as an index into the nearest blocks. The advantage with something like your minecraft clone is you're only ever going to pick the closest geometry so you'll never have to waste time rendering everything to the selection buffer. Some OpenGL references - [url="http://www.opengl.org/resources/faq/technical/selection.htm"]1[/url], [url="http://www.opengl.org/resources/code/samples/sig99/advanced99/notes/node117.html"]2[/url] - though something similar will likely apply to any library.
  11. [quote name='Ozwald' timestamp='1321831518' post='4886011'] Yes, the screen is blank. [/quote] The blank screen is pretty normal and usually a result of one of the following - [list][*]camera transform is pointing in the wrong direction[*]scene is outside the clipping frustum[*]we're culling the wrong side of faces[*]lighting is enabled but the scene is not lit[*]something is outside/inside glbegin/glend when it should be inside/outside[*]missing glcolor[/list] In the past I found a good solution is to start with the obligatory triangle sample code, then tweak one parameter at a time until I end up with the code I want - somewhere along the way I'll find the offender.
  12. Is everything in a single vertex buffer? Could you instead have a vertex buffer per chunk? Have you profiled your rebuild code? If the issue is transferring the (relatively huge*) updated VBO to the graphics card, then transferring only the smaller, modified VBO may be far more efficient. (* how big is the area you're transferring?) And out of personal interest, are you computing only the visible chunk surface for your a VBO or does your array include occluded geometry?
  13. For those of us that don't want to download code and compile it, can you describe how 'can't get OpenGL to render my data' presents itself? Do you get a black screen?
  14. Loving the art style, but that falling/raising effect for terrain leaving/entering the player's area looks very distracting.
  15. [quote name='Bregma' timestamp='1321565200' post='4885112'] The answer is: tune where your optimizer tells you you have a problem spot and focus on clarity everywhere else. It's almost never worth worrying about microperformance, and when it is you'll definitely know it (it has dollar signs attached). [/quote] ^ this. Some random examples, from your original post: [source lang="cpp"] vector<Widgets>::iterator widgetsEnd = m_widgets.end(); for(vector<Widgets>::iterator iter = m_widgets.begin(); iter != widgetsEnd ; iter++) { float width = iter->getWidth(); float viewAspect = getApplicationContext()->getScreenDimensions().getViewAspect(); //(1) float val1 = (56 * 90 + width) / viewAspect; //(2) float val2 = (57 * 90 + width) / viewAspect; float val3 = (58 * 90 + width) / viewAspect; } [/source] 1) viewAspect never changes per iteration, so why not declare it outside the loop? 2) division can be much slower than multiplication. Why not define viewAspect as 1/... and then multiply? You could continue going ad nauseum (cache hits?)