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

Gasimzada

Members
  • Content count

    32
  • Joined

  • Last visited

Community Reputation

206 Neutral

About Gasimzada

  • Rank
    Member
  1. Do I offset that while generating the new position or while checking the collision?
  2. This is my first time working on a Pacman game and I have come to a difficulty that has stopped me from being able to go further in my project. My Objects (Pacman and Ghosts) were moving too fast, so I thought I would add time based movement for them but I can't get the collision working quite right. Here is my TileMap: // 1 -> Wall, 0 -> Empty, 6 -> Base Gate, 2 -> Base, 7 -> Portal, 5 -> Pacman Start position [1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1], [1,4,0,0,0,0,0,0,0,1,1,0,0,0,0,0,0,0,4,1], [1,0,1,1,1,0,1,1,0,1,1,0,1,1,0,1,1,1,0,1], [1,0,1,1,1,0,1,1,0,1,1,0,1,1,0,1,1,1,0,1], [1,0,1,1,1,0,1,1,0,1,1,0,1,1,0,1,1,1,0,1], [1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1], [1,0,1,1,1,1,0,1,1,1,1,1,1,0,1,1,1,1,0,1], [1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1], [1,0,1,1,0,0,0,0,0,0,0,0,0,0,0,0,1,1,0,1], [1,0,1,0,0,0,0,1,1,6,6,1,1,0,0,0,0,1,0,1], [7,0,0,0,0,0,0,1,2,2,2,2,1,0,0,0,0,0,0,7], [1,0,1,0,0,1,0,1,1,1,1,1,1,0,1,0,0,1,0,1], [1,0,0,0,1,1,0,0,0,0,0,0,0,0,1,1,0,0,0,1], [1,0,1,0,1,1,1,1,0,1,1,0,1,1,1,1,0,1,0,1], [1,0,0,0,0,0,0,1,0,0,0,0,1,0,0,0,0,0,0,1], [1,0,1,0,0,0,0,1,1,1,1,1,1,0,0,0,0,1,0,1], [1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,5,0,0,1], [1,0,1,1,1,0,1,1,0,1,1,0,1,1,0,1,1,1,0,1], [1,4,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,4,1], [1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1] Here is the update code: http://ideone.com/SRIymz   EDIT: I couldn't embed the code in this editor. After 4 failures, I added a link; sorry about that.       Here is the full source code with the demo: http://projects.gasimzada.net/pacman/dev   I want to make the pacman to be at the center with regard to the other plane. So if the pacman is moving in direction UP and DOWN. I want the pacman to be center in LEFT-RIGHT direction. Also, If I hit a wall, I need it to stay at one tile behind it instead of getting inside the walls. I know it has something to do with the Game.roundPos but cannot figure out how to implement it. Any advice will be appreciated? What other methods can I use to round the position to the next correct tile?   Thank you for your time!
  3. Thank you for the help! I was thinking in the wrong direction but not it all makes sense.
  4. I am designing window management for my engine and I have a dilemma. I don't know if I should make the Window Manager part of the engine, or keep Window Manager as an gateway between user and the engine which sends window events to the engine. And the engine does all the work.   In my current design, there is an Engine object, which on its own is a FiniteStateMachine, so its responsible for changing the game states. It also performs the main loop in my game. Then I attach a WindowInterface to my engine (can be SFML or SDL or whatever). The MainLoop of an engine is implemented this way: int Engine::run() { Timer timer; while(running) { auto event = window->pollEvents(); if(event) { if(event->getName() == "closed") stopRunning(); peekState()->sendBeforeUpdateEvent(event); } peekState()->update(timer.getElapsedTime<Timer::seconds>()); window->preRender(); peekState()->render(); window->postRender(); timer.reset(); } return 0; } But I am thinking maybe this design would be vise-versa, where the window sends events to the Engine instead of Engine receiving them from the Window, and the loop happens through the window instead of the engine.   So, every simple implementation (whether its SDL or SFML or something else), the "run" function must be implemented over and over; from programmer point of view it sounds more work. But It makes more sense to have something similar to that from Engine Design point of view, instead of more code writing point of view.   Please give me advice on this situation. I don't know how to keep it. Its not about anything but the actual Engine design.   Thanks, Gasim Gasimzada
  5. Thats how I do it now, I have a "World" class that holds component holders holders and the systems act upon those component holders. The World doesn't care about the existence of any manager or system. I am still thinking about making design more cleaner as I am deciding whether a system should know about the state dealing with resources or does the system only act upon the world where the world is coming from, either from a state or from somewhere else.
  6.   What do you mean by "Except where it doesn't bring anything"? Why would you use C array in a C++ code? With zero optimizations, I don't believe the performance would be so much different, as std::vector is just a wrapper around C style array? However the functionality you get with STD arrays is totally worth performance.    And to answer your question about templates, of course learn it. Templates can be scary (it was for me); however once you get comfortable with it, you can write codes that are very flexible. 
  7.   Do you register observers to the systems to do some system specific codes. Thats why I have a different update function per system. Like BulletSystem update: //Bullet.cpp void BulletController::update(World * world) { btDynamicsWorld * dynWorld = world->getHolder<BulletHolder>()->getBulletWorld(); dynWorld->stepSimulation(1/60.0, 0); } //HordeController.cpp void HordeGraphicsController::update(World * world) { for(auto component : world->getHolder<HordeNodeHolder>()->getNodes()) updateComponent(component); } //HordeCameraView.cpp void HordeCameraView::render(World * world) { for(auto component : world->getHolder<HordeCameraHolder()->getCameras()); h3dRender(component->getHordeNode()); } For me doing view vs controller is just a conventional thing. I just split the system into Controller and Views, where controllers do update while views do render.
  8.   The controller needs to know how its going to update the holder: bullet physics updates the holders in its own way, the graphics controller updates it in its own way; same with the Views. As for the subclassing of holders, I only do that for having less amounts of castings to the needed type. Instead of casting every component to the right type, I just cast the holder to the right type and access its elements. How would you do it? I don't really understand how its possible to have generic holder, view, and controller classes while still preserving flexibility of the state machine.     For me there is not meaning behind States as there is no meaning behind Entities. They are both just containers with ID. The way I think about both of them is like a Storage Unit - by themselves, they are pointless; but once you put the things in it, they get valued :P The State Manager I want to implement is very different than most I have seen in the internet; the ones I have seen always inherit from a base State class to a PlayState or MainMenuState. For my state management, there is a generic State class; that is handled by any sort of state machine - whether its FSM, HFSM, or BT. Then, there is a special case "GameState" where its used for changing menus or whatever. This container itself consists of "components" = managers, controllers, views. The systems are identified by "name". The main difference between controllers/views and managers is that, each state has its own created manager, while each state stores only the reference to the particular controllers/views. The controllers "don't care" about the existence of a state, they run in separate threads and update/render whatever is given to them. I have had Managers, Controllers, and Views working altogether but I want to change that and separate the controllers/views.      I just realized that I want to build something similar to what you have :) The moment I have a working version of what I want to achieve, I am thinking of getting rid of the entity class all together because it has no specific function than be a "middle man" between the components, which I think components should do directly. For me it makes sense to have a State because of transitions in the State Machine. But for Entity, I would rather change it to a sorted double linked list of components (or maybe a set. i'll figure it out when its time); where one can find the other components by comparing IDs. One question, about Entity Managers? what are they? Are they basically a World or are they the creator of the entities? Or are they both?     My main problem is not the implementation of the state machine but the design of a flexible and generic GameState (MainMenu or Play) that can be created into anything.     I really like the idea of the world. Can you please give me an idea of what a world is? What can it do? What does it store? How is it compared to my ComponentHolder? Is it just a container of component holders?   I think this topic isn't about state management but more about "Designing a world object"
  9. I have asked a question similar to this before but I cannot move forward with my engine without fixing the State Machine. In my old design, the systems hold the needed components and updated them as needed and the states hold the systems they need. Like "Play" holds graphics,physics,input,ai,gui; the "MainMenu" holds gui,input. Also, the states are not hard written to the engine; one can create any type of a system they want with the needed components. The problem was that new systems are created for each state; for example there would be multiple input systems in the lifecycle of the application if more than one state has input system.   As my engine become more complex, I decided to change the design to something similar to Artemis Framework. So, here is the new design:   The systems are created ONCE only and their pointers are passed to the needed states. Each state holds a component map. The first parameter of the component is the pointer of the system. The second parameter is of type ComponentHolder. A component holder is basically an abstract class of different lists of components. For example a GraphicsComponentHolder holds 3 lists {list<GraphicsComponent*>, list<CameraComponent*>, list<LightComponent*>}   Example Snippet: class GameState { private: std::map<Controller*, ComponentHolder*> mControllers; std::map<View*, ComponentHolder*> mViews; public: void update(Real time) { for(auto &controller : mController) controller.first->update(time, controller.second); } void render() { for(auto &view : mViews) view.first->render(view.second); } }; class HordeCameraController : public Controller { public: void updateNode(SceneNode * node) { //... } void update(Real dt, ComponentHolder * holder_) { auto holder = static_cast<HordeComponentHolder*>(holder_); for(auto graphics : holder->getGraphicsComponents()) updateNode(graphics); for(auto camera : holder->getCameraComponents()) updateNode(camera); for(auto light : holder->getLightComponents()) updateNode(light); } }; class HordeCameraView : public View { public: void render(ComponentHolder * holder_) { auto holder = static_cast<HordeComponentHolder*>(holder_); for(auto camera : holder->getCameraComponents()) h3dRender(camera->getNode()); } }; Is there another way I can build this? Or should I do it this way? Should I just update the component holder when state changes or do something different. I am very noob at state management, so I really need help on designing on.   Thanks, Gasim
  10.   Being honest, I don't like the way Artemis deals with it. My entity system looks similar to yours, but I store lists of needed components in my systems. For example, a list of CameraComponents and Graphics Components. This way accessing these components is simpler hence I know the type from the beginning.   Problem I had with cloning was a design flaw from my point of view because I had logic in my components. When I changed component to a data storage with utility functions for easiness, the cloning got fixed immediately.   Thank you for the help! I finally have an OK working entity system
  11.   That makes sense. Finally everything is starting to fall into pieces. My design right now is so overcomplicated because of my not clear understanding of the situation. Simplifying it is going to take some time but the design would be understandable eventually. Thanks!
  12.   It takes the state from the entity, the entity's state gets assigned during entitiyManager that stores which state is was created.     I understood how entityManager can add the components to their right systems but can you please give more details for the latter. I am going to start with initialization through the entity Manager then it would be easier for me to port it to the systems. And one more question, how would you deal with the cloning? Cloning copies everything from an existing entity to a newly created instance. If i remove initialize function, I would only be able to do modify the object after it is added to the scene and is used; or at least I don't see how i should be able to do that. Can you give me a hint on how to deal with this problem?
  13.   It wasn't really a problem but more of a theoretical question. But I sometimes confuse the fact that I am working in a sequential environment. Now I know even if I add multithreading support, I would keep the entity creation (not initialization; read below) and state changes in one loop while the subsystems in another loop. Or lock everything during state change. Its an idea for the future as I am not implementing any multithreading until I have something thats stable.     99% of the time I do that for initialization. The reason for that is that, the component creation does not rely on the system. I just don't like that idea. This way the components are created through the entity factory but they don't get initialized. In order to initialize them i need to call "entity->initialize()" which goes through all the stored components and calls the "initialize" function of each of them. A typical component initialize function looks like this: void InputComponent::initialize() { getCurrentState()->getSystem<InputSystem>()->addComponent(this); } When an entity is initialized, the systems will start doing their jobs on them. I think of the above function as this shared space between component and system that is used only once. This helps me with a lot of things with one being cloning, so I don't use objects the moment I create them - for example I can move the entity to a position and create it there.     I am not subclassing entity but each component has its own initialization and cloning code, whereas I also provide a generic solution with one function call.   When it comes to the question of this topic, there is doubt about the way the state machine should be working. I have implemented a very generic and broad state machine where each state machine can have their own systems etc. So far it works great and makes sense but I don't have any predictions for the long run.
  14. that makes. I was thinking of making everything an entity, even the gui but now I realized what's the point.
  15. I have implemented game state machine (Main Menu, Play game etc) into my engine. I have some questions regarding the relation of the states to the entity design that I have:     In my current draft implementation, each state holds a list of systems that need to be updated,rendered,or used for input. For example:   The "gameplay" state holds Physics System, Graphics System, and Input System, while the "main main" state holds GUISystem and InputSystem. The input systems do not hold the same address. They are created separately and hold the components they need for each other. This way when I call update, only the needed systems get updated. So far, everything seems to be making sense...   But I have one problem with connecting these states to components. I need that for one reason: Sometimes components can talk to the systems. For instance, the components get added to their corresponding systems during entity initialization (the initialize function gets called. And from there I can write whatever I want in that function).   When I had an engine with only one system manager, it was easy to handle systems. Currently, the active state is stored in the entities the moment an entity gets created. But what if the state gets changed when there was an entity getting created? The Entity will be added to a system in a wrong state or if the state doesn't have the system the game will crash. Also, wouldn't it be inefficient in terms of memory to store all the resources of the inactive states?   Design wise this system makes sense to me but efficiency-wise i don't know. What do you think? Is this approach even good? I know there is usually no universally accepted way of doing this but I don't want this system to be horribly bad. So, please criticize it as much as you can.