• 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

4437 Excellent

About LorenzoGatti

  • Rank

Recent Profile Visitors

18999 profile views
  1. I suggest simplifying drastically the small version of the card images: no text, larger illustration and larger title. Words, icons and numbers should be as large, or almost as large, as their counterparts in the full-size card, which is presumably readable enough, or omitted completely. As important as card text might be, players can easily read it by hovering the mouse on a card miniature. Privileging the elements (name and picture) that make cards recognizable reduces player frustration, reduces mistakes, and allows familiarity with cards to gradually reduce lookups of the full card text.
  2. Pathfinding

    No, the eikonal equation defines what is a shortest path. "Traversing the areas" is what algorithms that compute solutions of the eikonal equation, i.e. shortest paths, need to do somehow. In the case of chapter 23 of Game AI Pro: Maintaining a list of active wavefront cells looks definitely like a "brushfire" algorithm. Are you confusing this basic building block of multiple source/single destination grid-based pathfinding with the full pathfinding solution described in the book (tile-based architecture, portals, caching, LOS special case, specific flags and data structures, etc.)?
  3. Just separate rigorously an enum type for the parts of your bitfield and some unsigned integer type for the values. Only the latter type has operations. typedef uint8_t videoFlagsValue; enum class videoFlag:uint8_t{ useWindow=1<<0, useOpenGL=1<<1 } public bool isset(const videoFlagsValue v, const videoFlag f){ return v && static_cast<uint8_t>(f) } public void set( videoFlagsValue & v, const videoFlag f){ v=v || static_cast<uint8_t>(f) } public void unset( videoFlagsValue & v, const videoFlag f){ v=v && (! static_cast<uint8_t>(f)) } static void openGlWindowFix(videoFlagsValue & initFlags) { if (isset(initFlags ,videoFlag::useOpenGL)) { set(initFlags,videoFlag::useWindow); } } int main(int argc, char **args) { videoFlagsValue initFlags=0; set(initFlags,videoFlag::useOpenGL); openGlWindowFix(initFlags); .... return 0; } It can be improved with a class to tie everything together (maybe a template that can be used as a base class) and a constructor from a std::initializer_list<videoFlag>.
  4. Your local git repository and the git repository you host on GitHub act as a backup of each other by design. If GitHub closes down, is hacked etc. clone your local repository on some other hosting service; if your computer passes away, check out the GitHub repository on any number of replacement computers. No commands fancier than clone, checkout, push and pull are involved. For further redundancy you need three or more copies of your repository (in addition to your own local one and the GitHub one), which could be a traditional backup of your computer (including your local repository directory, and if possible the whole working directory for completeness and convenience); restore by simply overwriting files other contributors, each refreshing their working copy on their respective computers from the same "central" repository other hosting services, with you and other contributors pushing the same changes to each shared repository For greater reliability you need automation. For example, a periodic task running on a internet facing server with its own git repository can pull changes from the GitHub repository and possibly push them to another public git hosting service.
  5. What's important, from a design point of view, is making the whole system (file format, writer, reader) oblivious to pointer size. You shouldn't have the 32 bit version and the 64 bit version, but a single implementation that compiles correctly and behaves identically on all platforms. Offsets are measured in bytes and represented as 32 bits in the file because the file is limited to 2 or 4 GB and file content is unaligned (two assumptions that in some cases could be changed to allow smaller offsets), not because pointers are 32 bits. Pointer arithmetic in code needs to convert a 32 bit integer, (i.e. int32_t) to a ptrdiff_t and vice versa, at worst using type traits from the standard library (numeric_limits<ptrdiff_t> from <limits>) to check for overflow.
  6. Narrow and Condensed are widths, not weights: they are traditional adjectives for variant font families that have a smaller character width than the normal font and a similar design. Wider designs are usually called Expanded, Extended or Wide For example typical Windows fonts include Arial (main design) and Arial Narrow, and Arial Narrow has the same set of weights as Arial, e.g. Arial Narrow Bold that looks like a narrower Arial Bold. If you use FreeType, why do you bother with matching a different API? What use do you have for descriptions of the font weight, except to report in some debug log or end-user report interesting details, found in the font file, of the fonts you are using? None of this data has any relevance to using the font to render characters. In case you are letting the users select fonts interactively, you can conservatively group them by name heuristics, without trying to guess and sort weights and widths.
  7. A space empire lends itself very naturally to a feudal hierarchy: central government, star systems (almost isolated from each other), planets and asteroids in a star system, separate colonies or nations on the same planet. As Polama suggests, federal bureaucracies are the natural "enemy" of feudal power, and they are supposed to be on the emperor's side; however, they might be defeated or intimidated or subverted. To avoid civil war, the feudal powers could be purposefully crushed by difficult tasks (e.g. defend your piece of the frontier from aliens) and competing for limited resources rather than directly conflicting with each other. Also, the purpose of the emperor should be to remain in power and make the empire prosper, not necessarily to replace an explicit and healthy feudal organization with secret influences and plots to control bureaucratic organizations. Depending on how the empire forms, the "nobles" might be: recently appointed by the emperor, and possibly temporary (e.g. a military governor) leaders (or more impersonal governments) of politically united planets or systems that join a federation and retain autonomy, also, leaders of megacorps, crime syndicates, political parties etc. various organizations that have (or once had) the resources to have a space fleet and "own" the particular planets they explored/conquered/colonized (maybe recently, maybe a long time ago) inflated from small-scale origins (e.g. the brother-in-law of the first emperor became viceroy of an important planet, and centuries later his family is wealthier than many alien empires; two or three Earth nations, the only ones with space colonization programs, have expanded to fill tens of planets each while the others merely provide exotic foreign tourists)
  8. The Flash browser plugin is usually updated to fix bugs that can be exploited by merely accessing hostile objects; it's an outstanding security risk, far worse than more properly sandboxed Javascript. PHP, on the other hand, helps putting your servers at risk: assuming hackers will attack you with malicious HTTP requests in any case, the bad design choices and the plentiful bugs in PHP and many accompanying libraries make their attempts more likely to find something useful. Avoid PHP. Not a real question. Iavascript with WebGL is more likely than Flash to be efficiently rendered and to make good use of hardware acceleration, but look out for bad surprises (particularly with libraries that offer Flash-like entities and scene graphs).
  9. Visual Studio 2015 or 2017 should be supported enough. Git support in Eclipse would be another well-supported option. The "command line" git tool actually includes git gui and gitk, two simple and serviceable GUI tools. The Magit plug-in for Emacs has many fans, but I've been unable to install it on Windows due to its assumptions about paths; it should work fine on Linux and OSX.
  10. If you reread your question, you'll realize that it doesn't explain enough. What is this "Souls" game you are imitating? What are you copying, and what do you intend to do differently? What's the role of sets of normally singular items like weapons and armor? Are the "too much" and "too little" you are worried about a concern about excessively good or bad equipment making the character overpowered or frustratingly weak, like in most games with roleplaying elements, or about more unusual aspects like the number of items found in the game, the number of item types, the cardinality of item sets, etc.?
  11. The gravitational simulations you are talking about placing in your game are extraordinarily difficult and expensive, and unlikely to improve any sort of game I can think of: if you don't convince me that your game benefits enough to justify the effort (and so far you haven't described any benefit at all) my advice can only be to avoid gravitational simulations or approximate them as cheaply as possible. Instead, you sound like you want to simulate gravitation because you have celestial bodies in your game and anything less than a physical correct simulation would be somehow bad. This is an almost guaranteed way to suffer without producing a game. While you need to justify your decisions to yourself, not to me or someone else, your decisions about allocating finite resources to the development of your game should be rational and based on what's needed to improve the game, not on what you'd like to work on or on abstract ideas and tastes.
  12. No, I'm arguing about specific examples. You are arguing about different examples of different situations. In the case of chess and checkers, you neglect that the "same core mechanism" is the same only if its important aspects are the same, not if two games fit in the same branch of an arbitrary classification. In pinball, there is only a game mechanic that matters, using flippers to keep the ball in play and hit stuff, and any rules layered on top of that merely provide superficial differences in how to score. Consider that if a pinball machine is damaged (e.g. a bumper becomes inert) the player can adjust to the new rules during the same game, whereas if a piece is moved arbitrarily in chess or checkers the game in progress loses all meaning. Is every sport in which a ball is used to score points and the team without the ball defends against the scoring attempts of the team with the ball the same? No, they need at least the same ball, the same team size and a very similar playfield to have a chance of being compatible and comparable. Did anyone successfully combine chess and checkers in nontrivial ways? No, because games about "moving tokens to capture enemy tokens and avoid losing your own" are so strongly dependent on piece movement and placement rules that any change disrupts their "chore mechanism" producing an essentially different game, with different strategies and techniques, and chess and checkers are particularly different instances of the genre. There are cases in which less different games share some skills, for example familiarity with traditional Shogi pieces that are featured in many variants and in similar starting configuration, or similar positions in different sizes of checkers, but it is an exception to the general need to reason about each game position piece by piece and move by move. In the case of speedruns (I'll limit the discussion to glitch exploitation and skillful play, excluding tool-assisted speedruns), you forget that the discussion in this thread is about the game designer, not about formally different or formally similar games. The possibility of players attempting a speedrun is only relevant as a group among many of requirements involved in evaluating the opportunity to write a more or less composite game. For example: Are speedrun-rewarding and speedrun-enabling features (e.g. bosses with hard to hit weak spots) a good idea for all players? In all parts of the game? Are there parts that do not allow speedrunning (e.g. strategic orders between action battles)? Would they be harmless, or even a welcome lull, or disruptive and annoying for the speedrunning player? Do the different parts of the game share similar control schemes and general glitch types? Unlike a typical player with plenty of time to adjust, a speedrunner might find the game too diverse.
  13. Penalty kicks are not a different game, they are only a specialized form in which the ball is kicked into the goal unusually fast and intercepted by the goalkeeper with unusual difficulty: not only the same skills, but the same rules as normal play. The same applies to second-playfield pinball games, where the player uses button-controlled flippers and plungers to avoid losing balls in both: what you call "different rules" in the two playfields are simply two branches of a single system of ways to score and places to hit with the ball. Even in extreme cases like the physically separate mini-pinball in Shrek multiple playfields are only a mild novelty, less jarring than gimmicks in which the regular ball does something strange. A videogame example: Micro Machines offers multiple vehicle types with different handling, control systems and special features, but you use them all for full-contact racing, often on the same tracks; general skills (e.g. looking at, and memorizing, the tracks; bumping opponents; not crashing) and universal rules are much more important and "larger" than specialized ones (e.g. shooting with tanks) so the game as a whole feels varied but coherent.
  14. Changes within a game need to be slow and simple enough for players to play effectively while they take place, without misunderstandings. On the other hand books, and to a lesser extent film, can disorient the audience until the changes are accepted and/or understood. Games have a formal structure of rules, which cannot be ignored, while narrative media have much more elastic internal coherence standards. If an airplane pilot is shot down and rescued by locals, in a story it is a reasonable and realistic development of what happens of a character, while in a flight simulator game it's the end (at least until the pilot returns to service and the rules of the flight simulator game apply again). Games containing multiple "forms" need to embed the respective rules in a rules superstructure (for example, trading simulations and action games can be combined meaningfully by acquiring equipment for use in the action parts and by looting trade goods in the action parts). This is far more difficult than simply making things happen in a story.
  15. High quality random starfields are scientifically plausible, as are randomly drifting close stars. Anything more accurate and more expensive needs to be justified by a concrete gameplay need; the simulation anxiety that makes you afraid to pretend and approximate isn't important enough to justify effort and (as already noted by others) it exceeds the practical mathematical/computational limits of what is feasible. If you really desire to go all-in on accurate gravity simulation, you might drop the action or adventure elements and adopt the niche but established genre of interplanetary ballistic simulators: shoot a projectile with such a direction and velocity that it hits another planet. To keep chaotic dynamics under control all examples I've seen are 2D, turn based (i.e. a succession of individual shots), with fixed planets (to allow trial and error) and with passive projectiles of negligible mass that are the only thing that moves.