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

Crowseye

Members
  • Content count

    44
  • Joined

  • Last visited

Community Reputation

308 Neutral

About Crowseye

  • Rank
    Member
  1. Genuine diversity and multiple avenues to victory are also important IMO.  With respect to the first point, players can see right through the reskinning and relabeling of units that are functionally identical.  As an example, in a WWII game, the German Panzer IV and Soviet T-34 should usually not share the same speed, armor, range, firepower, maneuverability, etc.  It's also important that the game is balanced in such a way that no one optimal strategy arises that renders all others obsolete.  Some players like to rush out cheep units and disrupt other players while others like to establish an economy and build a massive force with upgraded capabilities.  Others might want to sit back and play defense, hoping that other players run out of resources.  You should decide what strategies you want to be viable in your game and make sure that you have provided the tools to make all of them accessible to a nontrivial number of players.
  2. Use the console-specific functions in wincon.h (which is included in windows.h) rather than conio and the system functions.  Edit: conio is not standard C++ anyway and you should not use system() (read here).   You can find documentation on the functions specific to the Windows console here, and a bit more general information about the console provided by Microsoft here.   To answer your question in that light, check the console's input buffer to see if there are any input events using GetNumberOfConsoleInputEvents.  If there are, use ReadConsoleInput to grab them and handle them appropriately (you will need to obtain the necessary information from the event structure first), then move on to the rest of your loop.  If there are no events in the buffer when you check, then you just move on to updating the snake's position.  You should use the functions specific to the Windows console to control the output as well.  For example, do not clear the console screen with system("cls").  Write your own function to clear the screen making use of FillConsoleOutputCharacter (which will unfortunately require you to obtain some other info about the console as well).  There's a nice breakdown of the ways (good and bad) to clear the console window here.   And I know it seems like I just upped the complexity of Snake by a factor of a hundred.    If you're going to spend any amount of time with the Windows console for anything other than plain text games, spending an afternoon learning how to work with it properly is worthwhile IMO.  Ultimately it will feel very simple, I promise.   Anyway, to keep the snake moving when there is no user input, you should keep track of the direction the head is moving in addition to its location.   User input should change this direction when appropriate.  When you update the location of the snake, it's new location is based on its current location and the direction.  You might have other things change the direction of the snake as well, such as a collision with the wall of your "garden".
  3. I know some will probably consider it a waste of time, but writing games like Tetris and Snake on the console, and moving on to small Roguelikes can be a nice exercise for novice programmers IMO.  There's a useful lesson about separating game logic and graphics/input systems that writing such games for the console can help make clear.   Benryves has a tutorial that covers the basics of the console over on his site.  I started there and went on to write my own wrappers for console "graphics" and input.  If you follow kaktusas' link and dig around you can get to http://msdn.microsoft.com/en-us/library/windows/desktop/ms683175(v=vs.85).aspx which gives you the documentation on the functions in wincon.h   If you google something like "Breakout console C++" or "Snake console C++" you can also find a number of examples with code (some better than others, obviously).
  4. Brandon Sanderson's Mistborn series has a magical system based on ingesting metals. Certain people are born with the ability to "burn" or metabolize one or more of these metals upon ingestion and tap into the magical properties locked within. The properties are paired, so that one metal allows a telekentic push while its pair allows a telekentic pull. One allows seeing the outcomes of different possible decisions in the past while its pair allows seeing into the future. And so on. Sapkowski's The Witcher series (which was a series of entertaining books before it was turned into a video game series), has, in addition to more stereotypical elemental wizards, the witchers, who gain their powers through mutations resulting from intentional and potentially deadly exposure to chemicals/toxins. They also learn the mixing of potions and formation of elemental hand "signs" to aid them in combat. Witchers are trained professional monster slayers, but are typically not welcome in civilized society because of their mutations, which creates a source of conflict beyond the hero vs. monster one. Robert Zelazny's Chronicles of Amber has a royal family in a fantasy realm who possesses the ability to select characteristics from the "shadow" between realities, mentally adding or subtracting these characteristics to create "shadows" of their own world essentially on the fly (Earth is one of these shadow worlds in the series). Learning this power involves traversing a maze called The Pattern. The family also has a deck of tarot cards that enables them to speak to each other across these worlds and even travel between them if both parties agree. The movie Inception is set in our world but uses what could be viewed as a magic system based on the concept of "shared dreaming" and "dreams within dreams" with a number of specific rules about how these concepts operate.
  5. I might give the player an option to display a dice roll animation in the playing area for the sake of suspense, but for an RPG I can't see the time spent developing a controlled dice rolling system being worth the use it would get. In particular, if the roll is still randomly generated then the shaking and english are just "fluff" that will eventually be ignored in games that require hundreds or thousands of rolls during a play session. If they are not randomly generated but instead depend on how the player shakes them and/or the type of spin he puts on them, then the game becomes one of repeating the control movements required to get the ideal dice roll. Competitive people with a lot of time on their hands will always find a way in these cases to shift probabilities drastically in their favor in the long-run and undermine the balance of your game. IMO.
  6. I had a similar experience to Ryan's. When I got bored with the console, my inclination was to try to jump right into the Win32 API, OpenGL, and DirectX. Unfortunately, while one can copy tutorials and get nice things to show up on the monitor, it's not the same as understanding what you're doing. Progress came a lot faster after I decided to take a "step back" and work with SDL. IMO it's a perfect fit for games like Tetris, Pong, Pac-Man, and many other 2D games in that because you don't have to concern yourself so much with having the right code in the right places to make it work you can spend more time absorbing the "lessons" those games have to offer.
  7. From the documentation: SDL_BlitSurface(SDL_Surface *src, SDL_Rect *srcrect, SDL_Surface *dst, SDL_Rect *dstrect) -- srcrect is the SDL_Rect that defines the rectangular area of your source image surface that you want blitted to the destination surface. Rather than have your tiles hold their own surface generated from your original tileset surface, you can have the tiles just hold a rect (or SDL_Rect if you don't care about separating your tile data from their implementation using SDL) structure that defines the rectangular area of the tileset image representing that tile. When you want to "draw" a tile, retrieve its rect and use the (address of the) appropriate SDL_Rect as the second argument into SDL_BlitSurface. If for some reason you ever want a genuine "subsurface," the easiest way I know of is to create a surface of the appropriate size using, say, SDL_CreateRGBSurface, and then use the same principle above: SDL_BlitSurface the "clip" rectangle to the new surface.
  8. My computer is littered with text adventures, card and dice games, Tetris games, maze/Pac-Man/snake games, etc. in various states of completion. I've found that while I can write the "meat" of such games in a couple days, I don't always have the motivation to spend the additional days or weeks I'd need to add depth or work out the bugs or implement various game options, special rules, etc. to the point that I'm satisfied with them. So I can get on board with the idea of working on something one is interested in/passionate about rather than following some sort of list of must-do games. Of course, people have different motivations for learning to program. If one's goal is to get a job with a major firm in the industry, perhaps a portfolio of "must-write" games is a better approach as far as getting hired (I'm just using that to illustrate a point; while I can easily imagine a company that wants to see Tetris, BreakOut, Pac-Man, etc. from a rookie hire, I have no idea if that's actually a common practice). I know for me, personally, I had a specific project in mind when I picked up programming again as a hobby about nine months ago: a 2D RPG "suite" for a tactically-oriented RPG in the vain of Tim Phillips' old DnD-like Realmz/Divinity package. I'm doing it for knowledge and fun, with the thought that I may eventually learn enough that somewhere down the road I can apply the knowledge to a bigger project I feel passionate about. Are there useful things I could learn better and faster by writing more small, simple games before tackling something bigger? I'm sure there are. But for me, personally, either that supposed confidence boost of seeing a (nearly) completed game is not something I experience as strongly as other people, or I've moved beyond the point where I'm so affected. I get my jollies these days from seeing various elements of my project coming together. That I might still be a year or more away from putting all the pieces together into a working whole does not bother me. I guess the short of it is, as one's knowledge expands, one should try to apply it to things meaningful to oneself, whatever those things may be.
  9. RPGs: to add to some things already mentioned, I'll say bad inventory systems. For example, a single giant scrollable list with a couple insignificant filters is insufficient for games where you will pick up hundreds of items. RTSs: factions sharing nearly identical tech trees, along with buildings and units that are basically re-skins with different names. StarCraft had three diverse factions...it's baffling that so many RTSs struggle with this. FPSs: as others have mentioned, the inability to bind controls to the keys/buttons one wishes is ridiculous in this day and age. While I can manage in other types of games, it seriously affects my enjoyment of FPSs.
  10. Having NPCs with a complex AI routine that emulates daily life is not sufficient IMO. As much as I was impressed by what they were able to do in Fable and wish that more developers put that much thought into their games, to me the majority of Fable was a bunch of anonymous, generic levels. I think one of the major goals in world-building is to create a sense in the player that the geography, history, and "logic" of the world exists on its own merits, not solely as the setting for the player to fight and quest. For example, lots of games have ruins of a deceased civilization. And who can blame them? Ruins look cool. But if there is no historical context or geographic logic offered to the player for why the ruins exist and/or exist where they do, then they're just a cool background to move around against. *The first step IMO, is to have NPCs refer to locations and features in a way that makes it clear to the player that the inhabitants of the world are aware of them and consider them part of their world -- that they don't just exist to the player, they exist to the people he or she interacts with also. *The first step is probably not sufficient in and of itself. To take it a step further, the various locations and features of the world must appear to mean something to the inhabitants beyond what they mean to the player. The player doesn't live in that world, so to him a river is an obstacle to cross and a mountain is something to climb to get to the Magic Sword of Pwnage. But to the NPCs a mountain might be the "mother" that protects their town. A town might receive notoriety and respect from those far away because the ruins of a great library are there. When NPCs acknowledge the existence of other parts of the game world, they reinforce the idea that while the maps may be separate, they are part of a single whole. *To pick up on that last point. Adventures and RPGs rarely take place over an entire world (though some MMOs are there, or come close). Acknowledging different parts of the game world outside of the scope of the game and its story can be a helpful world-building tool. NPCs that have traveled or relocated to or from other parts of the world help reinforce the interconnectiveness: the town, or the kingdom, or whatever, don't exist by themselves. For example: the town blacksmith is not just an anonymous figure who exists for the purpose of selling weapons and armor to the player. He's a former soldier from a far away land that deserted the army when his people warred with the land in which the game takes place. Because he's form the land of the enemy, he's distrusted or looked down upon by the people in his town, though they respect his work.
  11. Whether you should create the scene then cut it into tiles, or just make tiles and use some tricks to make them fit together visually depends IMO on what you want your scenes to look like. If you're reusing the same scene elements over and over in different parts of your game world, it makes sense to create your art in terms of tiles instead of scenes. If your scenes are unique, but you want to use a tile system for movement or whatever, drawing the scene (perhaps using a tile outline overlay so that you can make things like up nicely) is going to look way nicer IMO. The latter "scene" approach is not terribly common, but it is used. For whatever reason, graphically, the Inifinity Engine games from Bioware actually use tiles "under the hood" even though the each scene appears to be one giant unique image.
  12. People learn in different ways. There are people out there who can read a book and intuitively grasp the concepts. For me, personally, I think I learn better by doing, and then referencing a book, forum, or website when I get "stuck." As I try to implement ideas I have for a game, I'll run into something I don't know how to handle from a coding perspective. But I know what I want the game/code to *do* so I can then search for how to do what I want. That helps me understand how a particular programming concept can be applied to situations I might encounter as I engage in my hobby, rather than try to learn a new concept that I can't visualize because the examples are unfamiliar or uninteresting. I found trying to implement text versions of various simple board, dice, or card games, or even "porting" old text-based games I played into my language of choice (C++) to be a huge help in terms of getting a handle on basic concepts. Not every game you write at this stage has to be commercial-worthy. Create a simple text-based interface so that you can make sure the game is working as intended, then move on to something else. When you want to start graphics, realize that most of the programming concepts are the same regardless of the API/API-wrapper you use, rather than getting caught up in which is better or getting overwhelmed with memorizing lines of initialization code and trying to figure out where to stick it. That got me hung up for a good couple months until I decided to simplify some with SDL. Once I got into learning SDL, I had the epiphany the various initializaiton and basic graphic elements of my games were essentially the same regardless of exactly how I have to implement them in SDL, DirectX, OpenGL, or whatever.
  13. In all the time I've spent on forums discussing games over the years, players don't seem to typically respond well to a global "time limit" where the world "ends" if you don't stop the villain in n minutes/hours/days (although in my own experience some of my favorite games employ a time limit for all or large parts of the story). One thing you might consider along the lines of your option #4 is "wrapping" the time limit in game events, such that at a certain point events conspire to send the player's character through a sequence of (mostly) unavoidable conflicts that lead up to an end that sees the player fail spectacular or die a hero -- which IMO is ultimately a better solution than having the player simply keel over. No matter what the solution it's important to give the player a reasonable opportunity to equip himself with the knowledge/skills/weapons etc. that will give him a fighting chance to "win the game" whether he played the first forty hours with that in mind or not. If that requires holding his or her hand through some major world events to obtain the necessary tools, so be it. IOW, if the player reaches his last few months of life, you probably still want him to have some chance of completing the game's main objective without having to reload a save from "thirty years ago." And incorporating option #3 into any other path is a classy and reasonable way to handle a time limit IMO -- it alerts the player that "Hey, you don't have forever to do this!" without just sticking a countdown timer in the corner of the screen.
  14. IMO it's hard to argue that filling up the XP bar, increasing one's level number, gaining new abilities, earning quest rewards, etc. are not the driving forces behind the level grind. If they simply enjoyed the process of exploring the world and killing the same things over and over regardless of the reward, then we should see max-level players continuing with much of the same behavior they did when leveling up. There would be no need to level an alt because absolutely nothing is stopping you from taking a level 80 character and going back to Goldshire and killing 10 kobolds, then heading to Westfall to kill 25 murlocs, etc. etc. In fact, that type of playing behavior is not very common. Why? IMO because for a max-level character the *rewards* for killing low level monsters are insignificant. It's simply not "worth it." Which suggests that many players are looking for some value over and above the satisfaction of killing things, or even their meager loot droppings. (In the case of WoW, Blizzard introduced the Achievement system that offered "rewards" for going back to complete old quests in the form of Achievement points, titles, tabards, etc.) The fact that so many people do have alts rather suggests IMO that they enjoy the psychological "high" of being periodically rewarded for repeated actions. Incidentally, that's the same psychological principle behind training animals. It took me 4 80s and 3 other 70+ characters in WoW to realize that I was heavily addicted to the effort->reward mechanism that that game had to offer. Of course, there are still a significant number of people who only care for end-game content, and will either "buy" or want to start off with an equipped max-level character...but these people are generally looking to avoid the leveling grind altogether, not just trying to start with a powerful character.
  15. One thing I see already...be especially mindful with your "Tough" trait. I don't know what your defense and regen models are, but consider whether defense and health regen are also acting as "effective HP" in combat by increasing the number of hit points a character can take in damage over a given time period. Make sure you aren't creating a situation where dumping all twelve points into "Tough" results in a slow-killing but immortal character, or at the same time resulting in a character that will be killed by any hit if you don't put any points into it at all. Some other thoughts: -I personally would use the word "Focused" instead of "Accurate" given its presence in the Mind category. -It appears a ranged attacker can get all the offensive stats he needs by dumping stats into the Accurate trait, whereas a melee attacker needs to split points between Accurate and Strong (for "Hit" and melee attack power). If damage is completely determined by melee or ranged "attack" values (as opposed to damage associated with a weapon), melee characters could wind up at a huge disadvantage under the current setup unless you have modifiers included in your damage and hit calculations that balance melee out. At the same time, moving "Ranged Attack" to the Agile trait, which might seem logical, couples it with attack speed, which is not necessarily desirable either, again, depending on how your hit and damage formulas are set up.