• 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

198 Neutral

About MaelmDev

  • Rank
  1. Hmm...the mega-corporation thing could work well, provided I don't come across as a complete libertarian bigot.  Possibly the idea of corporations evolving into kingdoms?   Thanks for the recommendations, but I'm not aiming to create this level of science fiction, and the games are quite dissimilar to the roguelike genre.       Perhaps I should have specified that I'm not aiming for full-blown galactic civilization science fiction.  It's still high fantasy in terms of being set on a parallel Earth.
  2. I would avoid trying to find a solution that works for massive mirrors in one fell swoop, and split up large mirrors into smaller, simpler surfaces that can get away with texture coordinate distortion for curvature.
  3. I'm currently designing a roguelike that aims to capture the high fantasy gameplay concepts and present them in a very different setting.  This futuristic setting stars a world that is populated not by dragons and magic, but by machines and technology.  Some concepts I've already envisioned in this new setting are: Mythical creatures such as dragons, giants, and other assorted monsters are now represented by a network of sentient, biomechanical entities Different humanoid races like orcs and elves are "modern" humans with biomechanical or mutant characteristics Magic is replaced with electromagnetic, nanotechnic, or chemical weapons and tools (possibly separating these disciplines?) Undead creatures are machines or cyborgs controlled by a necromancer, or hacker Potions are very similar, instead being injected rather than ingested Dungeons are abandoned underground facilities (including actual prisons) Melee weapons are relevant because armor technology has surpassed firearm technology Arrow and bolt weapons are railguns/coilguns; ammo is large but able to penetrate armor, unlike conventional bullets   Things I've picked out but haven't been able to translate yet: Treasure (chests) Deities and worship (maybe just keep this?  but how would I explain the effects) A relatively small population and medieval social structure   If any of you guys could come up with ideas, especially for those concepts outlined at the bottom, it would be really helpful.  Thanks!
  4. I would separate the vertex buffer itself from the vertex attributes.  This will decouple the vertex buffer from a program, and allow you to spread attributes across multiple buffers.
  5. Try to work out what features you want to implement before anything else.  Start with general ideas and work your way down to specific features and requirements.  Once you have all of your features in a list, you can start to design your architecture to implement these features, making sure to find solutions to dependencies between them. (this can be the hardest part!)   Don't bother with any pseudo-code after you've finished the architecture, as you've got all the elements needed to begin coding the actual game.  When you do this, make sure to always write code that doesn't depend on a feature you haven't implemented yet.  This should help you keep your game testable and cut down the amount of coding you need to do in between new builds, which will keep you motivated.
  6. I would use an additive rather than a modulative approach to animation layering. Each frame, the skeleton will be reset to the bind pose. Then, the whole skeleton will be transformed by the lower-body animation pose. You can then transform the skeleton by additional poses to add on a shooting animation, a waving animation, and so on. In this way, the upper-body animations won't affect the root bone as long as the pose keeps the root static.
  7. [quote name='crancran' timestamp='1356028230' post='5012870'] You could create your game where there are two types of game data on the client end. The first is the stock static game content that ships with the game itself. This often includes terrain-specific data, often data to help aid in physics client-side determinations, placement of world static geometry like bridges, trees, etc along with area trigger definitions, music associations, and the actual music and visual binary files. This is the content that in a client/server approach, shouldn't be modified and if a modification is detected, the server & client will handshake and exchange the right file from the server's repository to avoid clients from changing the expected behavior of the game based on the server side simulation. The second type of static content is your addons/mods which the server doesn't care about. These simply use some exposed API by the client to provide either enhanced UI options or extend the UI well beyond the shipped version for the player's experience. In the case of where you can create your own maps and play with your friends over a network, usually the map has to be installed on both ends by players before they can join a game together. Usually this is done by some lobbying mechanic that makes sure both clients agree on simulation details before starting the match. [/quote] I know that the client and server need to exchange files somehow, but what is the best way to know how and when to do this? You don't want the server sending every data file to the client... [quote name='crancran' timestamp='1356028230' post='5012870'] [quote name='MaelmDev' timestamp='1355957005' post='5012622'] but if I was to use client-side prediction, I'd still like to be able to get everything synced up. As well, the server may have added entities that the client may not have on its computer, so the problem of downloading the content still stands. [/quote] What you describe above is often referred to as game state data and not necessarily "content". In networked games, the server's simulation will need to be synchronized with the client's simulation. There isn't much in the way of a standard practice here other than the notion that you want to minimize your bandwidth footprint, transmit multiple packets of data in one delivery if possible and with client-predication in place, carefully being able to interpolate between latency differences of state transmission to avoid the rubber-band effect so game play is relatively smooth. [/quote] Well, you know what I mean. But in order for client-side prediction to work, the client and server need to be using the same physics data (collision hull, friction, restitution, etc.) which may have been changed on the client machine.
  8. I can think of how this would work visually, but not the steps needed to produce the transform matrix. What I see is an orthographic frustum with the "near" side squished vertically to make a trapezoidal prism.
  9. You're right, I didn't factor in the differences in client-side vs. server-side simulation. Your mods wouldn't affect other players, but if I was to use client-side prediction, I'd still like to be able to get everything synced up. As well, the server may have added entities that the client may not have on its computer, so the problem of downloading the content still stands.
  10. I'd like my game to support both multiplayer gameplay (in a client-server architecture) and content modifications. This presents a problem: what should happen if a player tries to connect to a server that loads different content? Anything in this game can be modified or added, including scripts and entities. The easiest solution is simply to reject that player if his content doesn't match. This would be done by comparing checksums of all the client files with the server files, and, if they don't match, that player is not allowed to connect. There are many drawbacks to this system, because a player can easily get himself locked out of online play if he accidently modifies a file associated with a published mod or the vanilla game. There's also the solution in which the files are compared to the server and then downloaded if they do not match (or if they do not exist at all). This is the more attractive of the two, at least in my case. What is the best way to manage this? Should each server create its own local mod on the client's machine?