Jump to content
  • Advertisement

Ungunbu

Member
  • Content Count

    33
  • Joined

  • Last visited

Everything posted by Ungunbu

  1. Ungunbu

    Atomic components in ECS

    But how would you address having multiple components of the same type representing different things?   Example: class Position { public Point Coords; } class TargetPosition { public Point Coords; }
  2. Ungunbu

    MonoGame effects and Windows 7

    MonoGame uses DX11 so I'd stick with it even for Windows projects.   Did you try the new Pipeline Tool for building your assets? To get it download the latest development branch and install it. You'll find Pipeline.exe in C:\Program Files (x86)\MSBuild\MonoGame\v3.0\Tools.
  3. Try to research "Cellular Automata"
  4. Ungunbu

    DigitalRune Engine Opinions

    And I already used XNA in the past. Btw paradox is somewhat inspired to XNA in the way it's core framework is structured. If has a Game class and Game Systems (which are similar to XNA Game Components). The devs should add some tuts and best-practice articles about Scripts (based on c# async programming) and the RenderingPipeline (looks like a collection of renderer objects each one representing a rendering pass). Their asset import tool seems pretty powerful too. Too bad they weren't able to add more docs. Anyway they are still in alpha so I expect more to come on this front.
  5. Good day kind community members,   I'm considering the DigitalRune Engine for my new game project. Taking a look at the site it seems pretty feature-rich. They have an affordable indie license too. I'd appreciate if you could share your opinion about this engine.   Many thanks 
  6. Ungunbu

    DigitalRune Engine Opinions

    Yes it's for a new game. I don't need anything fancy, really:   1) c# 2) Ability to procedurally create meshes 3) Animated models (basic skinning) 4) Decent material system allowing me to use custom shaders if I see the need 5) Lightweight and easy to use   I found the Paradox3D engine. Seems powerful (and it's free) but the lack of tutorials was a "no-go" for me.   Any suggestion is much appreciated, cheers
  7. Ungunbu

    Random smooth movement

    Maybe this article can help you:   http://gamedevelopment.tutsplus.com/tutorials/understanding-steering-behaviors-path-following--gamedev-8769
  8. Ungunbu

    ECS

    Why don't you google "open source entity component system"?
  9. My first post here!   How would one handle Game State Management in the context of an Entity Component System architecture?   In all my previous games I've used an FSM-based approach where each Game State is an object with its own Update and Draw methods. Each Game State would mantain a local list of Game Objects to update and draw.   When it comes to ECS I can imagine the following:   1) We still have Game States as individual objects   2) Each Game State has its own list of Entities (probably some kind of "EntityManager")   3) Game States have their own initialization logic: they can create their own entities during init. This logic is executed when the Game State is created or when it becomes active. We have a GameStateManager object to manage Game States life cycle   4) Entity Systems belong to the Game (not the Game States) but they only process those Entities that are contained by the currently active Game State   Please share your thoughts
  10.   I think he meant a button with an additional label on it... and by "texture", I imagine he meant an icon, not the actual button background.   Actually I meant a label that can be clicked. Imagine clicking on the "New Game" text in the main menu.   Btw, I see how a complex UI would need a completely dedicated set of components. This still doesn't mean it can't be done in ECS. I suppose the common approach is having Widgets organized in Tree data structure and a traditional inheritance chain (i.e., a *LARGE* Widget base class). I did it like that in the past and it worked (of course).   Also, I think you'll probably agree with me if I say that Game Objects should not need to access the UI layer. I tend to keep game logic separated from presentation (kind of Model-View separation). It's the UI that can read the "Game World" state and update its widgets with correct values. In extreme cases an observer pattern could be implemented to keep the UI in sync with the game objects (maybe a bit cumbersome for a game).
  11. The point of that architecture is to escape the god-class or a lot of (mix-in) inheritances. It is based on a standard software technique named "composition". Another such software technique is called "inheritance", you know. Both are suited to drive code re-use in some way, but nevertheless they are not equally well suited in each situation. See e.g. this wiki article for a short introduction.   Notice please that code re-use maximization is not the holy grail. If the code base has been advanced enough then you'll be much more happy about maintainability than about anything else. And that is not obtained by code re-use but by separation and abstraction. This means, for example, that graphical rendering can be well structured by division into layers, and the lower layer (responsible for the actual rendering) does not know what a scene object is or what a widget is. It is sufficient if it knows what meshes, textures, and similar stuff is. Then adding another source of such stuff can be done without touching that render layer at all. Using sub-system (e.g. in the meaning often discussed in the context of ECS) is another tool for separation, this time on a higher level. Otherwise, the more coupling exists, the greater is the chance that editing due to a new feature will break something in the overall complexity.   If you're trying to fit everything into one architecture you are on the same way that once yielded in the now classical scene graph where really everything is expressed as a graph node. Look at the comments nowadays about its usability. And notice please that ECS is "invented" as one way to overcome the shortcomings of a scene graph as well.   I don't say it is wrong to model widgets by using something like ECS (although the term "ECS" is normally used to express a game object architecture, and using it in another way may cause confusion; this thread is already an example for that). However, I say that it is wise to choose a tool that is suitable for the given situation.   Just my 2 cents   Actually I found composition is well suited for UI too:   Label draws some text PictureBox draws a texture Button clickable and draws a texture TextButton clickable and draws some text ComplexButton clickable and draws a texture and some text   Can you see it? That's why I think I could reuse my existing ECS framework for the UI/Hud too.
  12. Say dx = horizontal overlap and dy = vertical overlap You can adjust player position with the following snippet: if (dx >= dy) {     // VERTICAL COLLISION     player.y -= dy * SGN(player.velocity.y); } if (dx <= dy) {     // HORIZONTAL COLLISION     player.x -= dx * SGN(player.velocity.x); } It handles the corners as well because both if statements will evaluate to true if dx == dy (corner)
  13. I already know about that sample, I'm discussing about Game State management in the context of an ECS architecture.
  14. OK finally I'm returning to this post...   I'd like to clarify my vision.   In my design the ECS handles pretty everything, from UI widgets to game "actors" (e.g., player, enemies, items). The reason to do so is to maximize code reuse. Position of UI Button on screen can be a component that I can reuse for Position of Player. No difference. A system rendering 2D stuff can be used to render both UI widgets and game specific entities. I think this is the point of this kind of architecture.   When I talk about "Game State" I mean things like: "Main Menu", "Settings Screen", "In-Game" or "Paused". Modelling each Game State as an entity container just makes sense: "Main Menu" will mainly contain buttons and text labels (we already said they are entities too), "In-Game" state will contain more game specific stuff.   I prefer to add Entity Systems to the game and make them always be active. This is easier and, if you think about it, the fact that your collision system is idle when inside the Main Menu is not that huge problem performance-wise.   Your opinion is much appreciated
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!