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

coderx75

Members
  • Content count

    1426
  • Joined

  • Last visited

Community Reputation

435 Neutral

About coderx75

  • Rank
    GDNet+
  1. I prefer to keep game development as a hobby and engineer enterprise applications/web services by day.  I rarely work late which affords me some time to work on a game.  This gets tricky though.  I spend nights with the wife and kids so I'm usually up anywhere from about 3:30am to 5:30am.  I'm at work by 7.  I bring my laptop so I can work on the game during lunch.  Sometimes, I get some time in at night on the weekdays and I usually knock out a good 8-10 hour day on the weekend.  It's tough but I get the best of both worlds: professionally engineered solutions vs. crazy-fun game stuffs.   My two cents on keeping game dev sane: - Learn to refactor and keep doing so until you have a solid, comfortable-to-work-within(TM) game framework  - Make time for the non-gamey stuff: tools, menu systems, etc. - Make time for the cool stuff: I used to put all my time into the big tasks but have started maintaining a list of really cool, easy(-ish) to implement features and tackle those whenever things get stale.  A lot of great gameplay and unexpected features have come out of this.
  2. Not so much of a "return" as it's been in development. Things had slowed down during the whole family-building process but have been in full swing for the past few months (as in spare-time full swing). Tech arena allows players to build vehicles (and pretty much anything they want to) from components and compete against friends, enemies and AI in an arena. These components and their functionality are each defined by scripts. On the front end, the player may create new components from existing types but these types are really templates of Lua scripts. If one so chooses, however, they can use the in-game code editor to write their own components from these templates or from scratch. I've posted a new video testing out the new rocket launcher component and the physical effects of explosions in general. Fun stuff!
  3. To start a game, no.  You can have some code lying around, slap it together into a prototype and play with some ideas.  If you're a beginner, no again.  Take something simple that already exists so you can gain some practice in game development.  It really depends on what you mean by making a game.   If you're starting a serious project then you should have a firm grasp of your concept before any development begins.  A serious project, even a smaller indie project, can be pretty vast in scope.  So, you don't need a concept if you don't mind spending 6 months to a year of your life trudging aimlessly for 12 hours per day to produce something incoherent (if you're extremely lucky). ;-)
  4. I would recommend reading Nonviolence: The History of a Dangerous Idea by Mark Kurlansky.  If your government is corrupt, there are ways to impede it without violence.  Doing so will force them to negotiate and bring about change sooner.  Non-violent protest can be a powerful thing.  Unfortunately, most people think that standing around with signs is an effective way to protest.  It's not.
  5. The OP brings up a great point about modern gaming that I think the video game industry is deaf to.  It seems that there are many more people giving up on video games for board games than is noticed simply because those people are NOT playing video games and, obviously, NOT complaining.  Granted, there are a lot of new video gamers coming up in this new era that see the current state of things as "normal".  Much money is being made off of them and they are not yet jaded.  However, the rise in popularity of board games has been huge in recent years.  Many of these people were video gamers to begin with but prefer to be face-to-face rather than deal with the endless stream of obscenities from the prepubescent masses.   I don't like playing online.  I never have.  Lately, however, it seems that major titles must have a strong multi-player element.  As a result, I don't buy video games anymore aside from the occasional mobile game.  My gaming budget isn't small either.  My expenditures in video games for the past year have been almost zip.  On the other hand, my wife and I have spent about $3000 in that same time frame on board games and expansions.  This isn't an unusual amount for a board game hobbyist either.  There's more money being lost here than AAA publishers realize.   As for "online single-player", I'm not going to "whine".  Much like "video game violence" and "games as art", I'm ignoring it completely. ;-)
  6. Detailed generation of "infinite" worlds is a bitch.  I've put myself through it and learned much but, currently am not applying everything I've learned because I'd have to bring my entire project back to the drawing board.  It's a good thing you're asking because you really want to get this right early on.   First off, a noise function will not cut it.  Sampling a point at (x, y) from a noise function to get a height value will produce very boring results.  Having an infinite world is pretty pointless if it's all homogeneous.  You will need to implement different methods of creation.  Noise (spectral synthesis) is always useful.  Displacement (also known as distortion or perturbation) really helps to produce natural results.  The use of convex hull diagrams, such as Voronoi Diagrams, are very important.  The ability to use modifiers on output, from basic mathematical operations to more complex diagram conversion algorithms, will open you up to more flexibility.  All of this is hell on seems though.  Ex: displacement can really put the edges of a terrain patch far out of whack with it's neighbors.   Second, how you generate terrain, handle collision detection of terrain and render terrain should probably not be the same.  It's efficient to generate large patches of terrain but more efficient to render in smaller patches, especially for dynamic detailing.  Collision detection depends on the library you are using but I try to get everything in place as it's generated.  I say it's efficient to generate larger patches because you want to leave yourself plenty of resources for dealing with seems.  The smaller the patch, the more seems that have to be managed.   I would suggest basing the generation of the terrain on both elevation and vertex normals.  Generating patches separately will always leave you with visible seems, even if the elevations match.  For example, the resulting edge of one patch may be horizontal while the edge of it's neighbor rises sharply, creating a highly visible "L" shape along the seem.  So, rather than using something like midpoint averages, include the vertex normal in your calculations to keep a more consistent surface (ex: a surface of an elevation can "lean" away from the midpoint, resulting in a higher midpoint and smoother surface).  If a surface at one edge is horizontal (or anything else), the vertex normal insures that it's neighbor is the same.   Another solution would be to generate "areas" or "continents" before generating actual terrain.  The area can be defined by varying dimensions, by a particular method(s) of generation and produce a terrain with a central high point and lower-lying edges.  This could be overlapped by other areas, only the higher values of the two areas being used and everything else discarded.   There's a lot to this and I've taken tons of notes (much of it in exasperation).  Dealing with texture generation, shadowing, collision detection and, likely, multi-threading, can be a real nightmare.  Once I'm done with work, I'll try to go over my notes and get back to this thread.
  7. That's a good question.  Say you have a great idea for a game but, in the prototype, you find that the player gets stuck in monotonous situations (ex: just about any RPG).  The idea could still be great but it wouldn't hurt to make the more monotonous play become more interesting.  How do you do that?   I played Curiosity when it first came out and I wasn't too impressed.  There was a bit of satisfaction in clearing screens, running up bonuses and seeing other cubes removed by other players.  The sound effects give the whole experience a bubble wrap feel as well.  However, after a couple of plays, I put it down, bored.   By itself, there isn't enough here to keep me interested.  In a larger game, on the other hand, I can see where the OP has a point.  In many games where monotonous play rears it's ugly head, the designers just leave it as-is, relying on the overall game experience.  However, some simple Curiosity-like additions could change the whole experience.  In an RPG where player's are inevitably going to be grinding, why not add bonuses for combo "streaks" to the combat mechanics, getting them to their goals faster?  In an MMO, how about introducing XP grinding that enhances the general play experience on the server and award the player for it.  Or...   ...if the player is grinding... let 'em fight bubble wrap. =b   Hey, it's better than telling your players that only the first player to beat the game gets to see the ending. =D
  8. "Give a man a 10 million dollar salary and, in two weeks, he'll think he deserves it." I don't remember where I heard this quote but I think it's a good reminder not to base your judgement on how much (OR little) you think you deserve. Consider what kind of work you want to be doing, what level of experience and proficiency you possess and what the average going rate is. Take that, add about $5,000 to $10,000 for some negotiating room and you have your answer. Keep in mind that you WILL have a few interviewers actually laugh in your face. That's okay as you probably don't want to work for their company. If you want to be paid well for your services, you'll need to have a thick skin. If they are interested in you, they will want to negotiate but try to stand firm on your original rate (prior to the 5 to 10 G's you added). If it looks like a stellar opportunity, you may want to be more flexible. However, many positions are sold to the interviewee as a "stellar opportunity". Ask a lot of questions! Remember, the more you're asking for, the more interviews you will have to go on to get hired. This is not a bad thing. You'll be getting plenty of practice in interviewing and, best of all, confidence. Also (and a little OT), if a company you work for is hiring developers, try to join in on the interviewing process. It's a great learning experience and you'll get a very good idea of how you compare to other people. Some potential candidates may even inspire you to improve in areas you didn't realize you were weak in.
  9. I've had some experience working with large-scale maps in my own projects. What I've learned is that in-game real estate is a serious consideration. As scale increases, the complexity of the required code increases exponentially. More importantly, the purpose for the extra playing area becomes questionable. Essentially, you're investing development time to increase player enjoyment. Being in charge of a project, one must constantly consider the return on investment for time spent by the team. As the world size increases, the return on investment quickly decreases. From the player's perspective, how much are they getting from the larger world? At some point, the answer eventually reaches zero and the justification for the larger world (time vs. return) dwindles long before that. I'm pretty skeptical of to-scale planetary surfaces in games (we're still a long way from pulling it off AND making it interesting to players) and 184,000 times the surface area of the Earth is just not happening for under a half-million dollars. This would be a fantastic project to attempt on your own but it's a risky game to play with other people's money. I'd suggest building a small-scale planet surface with content, collision detection, etc. to get an idea of how difficult it can be to have all the components of a game working together effectively at that scale.
  10. [quote name='uglybdavis' timestamp='1352856096' post='5000737'] If you're gonna script your game, go balls to the walls! [/quote] Agreed! So that I can do a lot of prototyping and be free to try out new ideas, I make everything scriptable. I have a core executable that fires up the Lua VM in a thread and registers some built in systems in Lua and it's own system of extensions, such as memory management, event handling, streaming, logging, etc. It then pulls in DLLs from an extensions directory, passes it's own API pointer to an entry function in each so that the DLLs can register their own functions as extensions in the core executable. At this point, DLLs can request the APIs of other DLLs and all functions can be called from Lua. Most of these functions are for setup with a low-level "update" function handling the bulk. So, there's not much loss in performance. With the Lua VM fired up, a kernel script is loaded that manages other scripts as "applications". This allows control over what each script has access to (see function environments) so that player scripts don't have access to low-level functionality. I also have a debug feature that uses Lua's built in line-by-line debug feature to "wrap" a script without affecting other scripts (would be insanely slow otherwise). I've been working with this for awhile and it's saved me incredible amounts of time. Have fun! =D
  11. I came to a point in a project I'm working on where compiling was beginning to slow me down. I had rebuilt everything into an extensible framework that would pass a pointer to DLLs, allowing them to register themselves with the main app (low-level function pointers and Lua functions). This took some time to put together but made development much easier and compile times much faster. I have about 60,000+ lines of code for the entire project but never take more than a second or two to compile a code change. An API change, on the other hand, can take a few minutes.
  12. The irony of your forum title just hit me. HAHAHAHA!!!
  13. Congrats! And you'll sleep again... if you shed any notion of staying up past 9.
  14. [quote name='gunning' timestamp='1329861298' post='4915284'] From what I can tell most restaurants are pretty bad for you overall not just fast food. We'd all do better to cook more healthy meals at home and then not feel guilty eating out once in a while. [/quote] Good point. Chain restaurants in general are pretty bad. My wife and I usually eat at locally run restaurants for two reasons. First, the food is prepared normal and without MSG, etc. Second, it keeps our money in the local economy (this goes for restaurants and anything else, so no Walmart, Home Depot, etc.) It's more expensive but we live by the motto "pay now or pay later". You're not really saving money by wrecking your health and your local economy. There are hidden costs. [quote name='samoth' timestamp='1329999424' post='4915839'] If you don't have time for a proper meal, you're without luck. Food is something I take time for, no excuses. [/quote] QFT! The time argument just confounds me. When I was single and living alone, there wasn't a single meal that I would prepare at home that took more than 20 minutes of my time... and I could [i]do[/i] other things while I was cooking. Going to the "drive thru", waiting for a half-dozen shmucks to decide what they want, wasting gas and listening to awful radio commercials for something unhealthy and worse tasting than what I could make at home would take over a half-hour. Stopping on the way home from work might save some of that time but you're still just sitting in your car doing nothing else.
  15. If you are going to be deleting/moving data often, arrays and vectors are a bad choice. A vector will get the job done but will perform poorly when deleting arbitrary elements. [i]If[/i] performance is a consideration, use list instead: [url="http://www.cplusplus.com/reference/stl/list/"]http://www.cplusplus.com/reference/stl/list/[/url].