• 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

180 Neutral

About PSvils

  • Rank
  1. "The system_manager object gets passed to onInitialize, onActivate, onDeactivate, and onDispose"   :) So yes, systems get references to the system manager.
  2. By what is needed, I meant it passes a list of class references to its super constructor.   The system manager uses this list when you add the system to the manager, and checks to see if all systems in the list already exist in the system manager. If yes, it activates the system, if not, it doesn't. It rescans this every time you add/remove a system to the manager.   The system itself can only access the other systems through the system manager.   Systems being dependent on each other can happen for different reasons. A bad reason (one which I use though) is performance. Sometimes direct access to system specific data is faster, and easier. An example would be a PhysicsSystem and a BulletSystem. The BulletSystem would require the PhysicsSystem, and get a reference to it when activated. That way, it can directly do raycasts on the physics space within the PhysicsSystem, as opposed to somehow raycasting through creating entities and components etc.   It's both faster, and probably more understandable / debuggable.
  3. Unity

    Not sure if this topic is still relevant, but I'll just toss this here:   http://haxe.org/ using the framework http://kha.tech/   In short - Haxe is a language very similar to Flash's Actionscript and Java in syntax. It compiles to other languages though, including C++, Javascript, C#, Java, Python, PHP etc.   For game development, this is handy. The Kha framework (and other ones in the language's ecosystem) compiles the source code to Javascript for HTML5/WebGL, or C++ for all desktop and mobile platforms. Currently, this means 1 codebase gives you all these targets, and they run in a native way - the only overhead is an implemented garbage collector for the C++ target, but this is less than a VM.   It also does some cool stuff that transforms your shaders written in GLSL, to target specific shaders. Basically, for many parts of the development process, you truly write once, deploy everywhere.   I think it's definitely worth a look, I use it for my own projects!   P.
  4. I've explored the ECS route for a while now, but haven't yet completed anything substantial - just a tip, my main bottleneck was trying to structure really low-level concepts within the ECS, I even tried to have VertexBufferComponents at one point, that was a dark period in my life. I now aim to have an engine running without the ECS, and the ECS is a high level layer over the concepts in the game engine. Now I have a SpriteComponent and either ImageComponent/ColorComponent, which is still relatively low-level, but works for now, trying to minimize that further.   1. I think the most important concept to understand in ECS, is that an Entity isn't an object itself, conceptually. It's main purpose is to just be an ID that ties groups of components together. How this expresses itself in my design, is that much like the systems/entities concept, which is the main/popular attraction of ECS for most people, the same inversion of control applies to entities and components. I have a ComponentManager that has arrays of all component types (I use the class name itself, via reflection (not C++, but this still applies)), and each of those arrays are sparse arrays, where the component for an entity can be accessed via the entity id. The result is a 2d arrays, though I have a specific manager for each component type as well. In the simplest form, component access is: `var componentA = types[componentA_ID][entity_ID];` where componentA_ID is the id assigned to the ComponentA type, and entity_ID is self explanatory.   At this point, entities are purely integers, which is the case in my engine. They aren't objects. I have a helper class that wraps an entity id, and gives convenient component setters, but this is just an optional utility. I don't think "an entity OWNS components", but "there are components, and they are assigned to the same ID". Maybe that can be phrased better.   This way you have more control over component storage, rather than them being tossed around in Entity instances. Also, this gives you a centralized entry point into your components. In my system, View objects "attach" to the component containers directly, which ever ones they need: `var view = new View<ComponentA, ComponentB>();` That view would go to the component manager, and get references to the containers responsible for the ComponentA and ComponentB types. Whenever a ComponentA or ComponentB is set on an entity, the view is notified of the change, and it checks the entity if it's valid (in this case, if it has both ComponentA and B assigned to it). This way, setting ComponentC on an entity has no effect on the view, it doesn't care.This combined with keeping a bitflag for each entity of what components it has, means any changes to entities get propogated immediately to views, and only ones that care, for minimal cost.   To sum up my gibberish, component access is direct, no looping or anything, via the component_type_ID and entity_ID. (entity == entity_ID in my case). Views selectively subscribe only to relevant component change events to keep a list of valid entities. (so, also no looping through entities at runtime to get the relevant ones)   2. Sort of relevant to the above, the concept of ECS for me is really just EC, and the S is an optional helper for structuring functionality. Technically, systems don't need to be actual objects, they just refer to pieces of logic that process entities (you could have an ECS-based game written totally in your main function, but that would be messy).   Anywho, I do have a system API to keep track of things. They extend a base class, and have 5 callbacks: onInitialize, onActivate, onUpdate, onDeactivate, onDispose The system_manager object gets passed to onInitialize, onActivate, onDeactivate, and onDispose, and the delta_time gets passed to onUpdate. The initialize/activate things are sort of specific, but initialize gets called when the system is added to the system_manager, and activate gets called when the system will actually start running. This is important, because my system_manager handles system dependencies - when declaring your system, you call the super constructor, passing in a list of system classes it requires. When the system_manager has all required systems added to it, then it will call the activate callback, at which point your system can get references to the required systems through the system_manager...did that make sense?   Generally my systems have a bunch of the above View objects, and they get initialized in the onInitialize callback, so I don't need direct references to the entity_manager (which is accessible through the system_manager). (BTW - the entity_manager holds a reference to the component_manager, so essentially: system_manager->entity_manager->component_manager)   This way, the system purely cares about itself, codewise/internally, but gets the references to the outside world and other systems through the system_manager, passed to the init/activate callbacks. If a system doesn't need the references during its update callback, then it doesn't even store a reference.   Not sure about your 3rd question, I haven't personally used octtrees in-depth.   I hope my splurge helps you...it's basically a raw braindump. I am by no means an expert, but I've gotten to this structure over several iterations of trying to make something with an ECS - the direct system to system communication was a big one, earlier I tried to do a pure hardcore approach where ALL inter-system communication should happen via components.   P.
  5. If you really want to have a dynamic system where you could cook up a few basic behaviours, but have the player combine them etc., I'd suggest using some sort of a component system. You could attach the RainComponent to the spell, and a FireComponent, and the RainSystem would create more entities with a copy of the FireComponent, and then you process that onwards.   That would be in the case of you using an Entity System all throughout, but simply maintaining a list of Components for each spell, and having the behaviour defined in components should be an easy and natural way to stack different behaviours. (They seem to split nicely, you have components affecting the way the spell is generated (ball/rain/etc.), then you have components affecting how the generated thing moves (could have a VelocityComponent with x/y/rotation and accelerations for each), and then the type or some other sort of modifiers (PoisonComponent/FireComponent etc.)) Graphics and particle effects can also be generated from the set of components.   P.
  6. From what I understand, I'm feeling that this game would be really cool! And it really could work as a card game, except with just not as many cards/options, but yeah, the concept is really cool I think! ...Can't offer much more than that Inspiration is a bit low at the moment to give any real feedback or suggestions, other than that it sounds really interesting and you should definitely get a playable prototype out there!
  7. [quote name='PyroDragn' timestamp='1349264601' post='4986348'] how do you deal with people that join a group late, or swap guilds for perks. [/quote] Each clan perk can have a certain level. Each player has a "clan level" or "clan ranking", that grows the more the battle with a certain clan (battle with, as in participate in battles on that clan's side). The higher clan ranking, the higher level clan perks the player gets. Everytime you switch to another clan, you have to build your clan ranking from 0, which would make players commit to a certain clan to finally be able to access the high level perks. I can imagine jumping into a fight with my clan, and there's some clan perk device that heightens all players health for a period of time, but it doesn't affect me since I joined recently, and don't have a high enough clan ranking. That would make me want to belong to the clan more, and really try to get to that perk level by winning points for the clan. P.
  8. You mix lots of things that it is difficult to understand your backing points... First, you say that a player will play the first FPS they buy, but after playing many, they'll throw them away and not want to play anything similar. Then you admit that lots of players like FPS's, CoD and Battlefield, etc.. that don't have much challenge in learning (though they still have lots of challenge that is expressed through situations that happen because of the game mechanics (Unique stand-offs between players in some random location)). Rather than seeing that as a problem, I simply see that as defeating your argument. Second, you get into the tangly world of "real games". How can you define a real game? Why isn't a real game the infinity runners, the physics shooters, the physics construction? Even while I don't agree with your definition of a game, Angry Birds still qualifies. The player learns the mechanics of the game, and what to do, and later on, the many levels are all tests on how much he has learned the mechanics. Your definition is extremely non-exclusive, but in my opinion at the same time limiting, since it enforces the common view that all games are meant to be built around being FUN, ENERGETIC, and CHALLENGING! (some are, some aren't at all) P.
  9. [quote name='Gle4se' timestamp='1349163432' post='4985982'] -A good gameplay with great mechanics -A great story with an awesome voice acting -I'm an Art guy so, graphics, unique, artist and "realistic in its own way" -Competitive Multiplayer - And for last, in single player games, Affection for the characters... the thing that I like the most in Metal Gear Solid. [/quote] Your idea to make a great game is "to make a great game"...You haven't even brought any ideas to the table yourself yet. Do you really think that all game designers and developers try to make another CoD? Have you seen any of the amazing, unique indie games already out there? What I'm trying to say, is "making a great game to bring back PC gaming" isn't a crazy new idea you just had, it has been the main goal of 99% of developers since gaming started. Offer something specific, or this thread has absolutely no point at all.
  10. Another option is to again go for the real-world realistic scenario, a child follows in a father's footsteps. So every game tick there is a chance the total amount of soldiers will go down, or up (the upper limit could be set by the player in terms of a budget, so their army's upkeep doesn't get unexpectedly high). This could work with each profession, so that they all more or less stay the same, with still some fluctuations. The player could then have abilities like "Advertise Military", and in that way people join the army on their own. Something like that, so the player can direct how many people are working where indirectly... Not sure what the rest of your game is, the above idea might be too different! P.