• Advertisement

hyyou

Member
  • Content count

    51
  • Joined

  • Last visited

Community Reputation

225 Neutral

About hyyou

  • Rank
    Member

Personal Information

  • Interests
    Programming
  1. I have a game loop in Entity-Component-System architecture (heavily simplified) :- spawn some enemy Turret, only in some timesteps; every Turret : try to shoot -> create new Bullet(); every Bullet : destroy itself if lifeTime = 0; every Turret : destroy itself if hp = 0; entity_component_system->cleanUpAsNeed(); It works, but to make it complete, I am supposed to delete entity at the last time step myself. Thus, I add many condition involving ☁lastFrame☁ :- if(!☁lastFrame☁ ) spawn some enemy Turret, only in some timesteps; if(!☁lastFrame☁) every Turret : try to shoot -> create new Bullet(); every Bullet : destroy itself if (lifeTime = 0 || ☁lastFrame☁); every Turret : destroy itself if (hp = 0 || ☁lastFrame☁); entity_component_system->cleanUpAsNeed(); It works but it is very dirty and error-prone. I imagine that this will also happen when room/scene changes. How to solve it elegantly? How do good games solve this problem typically? Are there any related "design pattern" I should read? Is it already OK, i.e. am I too nervous? Some days, I had nightmare because of it .... ... a nightmare that my code become ☁lastFrame☁-flavor spaghetti.
  2. That totally sounds reasonable, thank.
  3. Thank. As a follow-up question, assume a below situation :- Mr.B1,B2,B3,..., and Mr.B1000 signs contract to use a game engine from Mr.C. In the contract, Mr.C get 10% of revenue of every game that Mr.Bx developed using the game engine. Mr.C send header files and .lib to every Mr.B via email. Some Bs successfully deployed the game and paid C, but some Bs abandoned and used other engines instead. However, B1 is different from other Bs. Using C's game engine, B1 has developed a game without any collaborator. (^ Thus evidence is very hard to find.) After finishing the game, Mr.B1 wanted to cheat. Mr.B1 obfuscated C's header and .lib, and sell a game using the engine without paying C. Furthermore, Mr.B1 accidentally leaked C's obfuscated game engine in the internet. A random Mr.D found the copy. Mr.D knew that it is actually C's, but decided to use it. It is free. How can C detect such case? It is practically impossible to detect, right? Reason :- C can't access to source of every game in the market, including B1's game and D's game. Suppose that C can, there are a lot of game sold every day! If C's engine is also open-sourced (not free; it is like some contract of Unity/Unreal; easier to obfuscate), possibility to detect is almost zero. Correct?
  4. Questions :- To sell a C++ game library/framework/engine, does it usually have to be open-sourced? For a C++ template class (real template), it is quite hard not to be open-sourced, correct? If it is open-sourced, how to protect the copyright? How to enforce people to just use it, but not copy? ... I think it is practically very hard, because people can see the source code, and "rewrite" it. Does a shop like Unity's asset store make thing safer? If so, how? Arrogant assumption :- The game library/framework/engine is high-quality, well-documented, and it would be marvellously sell well. Besides some free libraries like Bullet and Ogre, it is developed all by myself. The library/framework/engine is not bound to any legal obligation (e.g. the most restriction is MIT). I have these questions after reading a news :- Muhagames develop a game named Thea Awakening (C#). The company use its own Honey Hex Framework (C#) as a library to develop the game. The company sell Honey Hex Framework via Unity's asset store to boost its financial position. There are also others old examples e.g. Unity itself or Unreal, which is now open-source ... How do they protect it? Actually, I don't plan to sell any library. I am just curious.
  5. Writer looking for team

    If only you show your previous works ...
  6. I am trying to encapsulate a Physics Engine (to support fracturing). I want to know whether my below semantic is bad smell. [Approach 1] My current design is :- Programmer can create 2 types of Physics body : Parent, and Child Parent is a body that can't have any shape or mass, but can contain some Parents or Children. Child is a body that can't contain any other physic body, it always has shape and mass. For the implementation :- Both Parent and Child are inherite d from a class PhysicBody. PhysicBody has some fields. One of them is mass, as an example. Mass of a Parent is the total mass of every children. Mass of a Child is the mass of itself. Suppose that I want to simulate a jar that can explode into several pieces. I will :- Create a Parent named x Create many Child that denote fractures e.g. y1 y2 y3. x.add(y1); x.add(y2); x.add(y3); The steps are very similar to BulletPhysics's. So far, it works well in all demos. Coding is easy and fun. Today, I want to implement a tank like this :- (a crappy tank shown in top-view) Here is how it can be created :- x is a Child : x = createCube(); y is a Child : y = createSphere(); z is a Child : z = createCylinder(); p is a Parent : p.add(x); p.add(y); p.add(z); It works, but I think it is counter-intuitive :- The tank is p which is an relatively (too) abstract physic body. [Approach 2] Thus, I plan to make it like :- x = createCube() y = createSphere(); x.add(y); z = createCylinder(); z.add(y); The new sematic demand me to re-design Physics class, e.g. to be :- Old parent and child will become the same type - all of them can now has shape, mass and contain children! I think it would work well, but I am still too scared. Question Is it make sense to allow non-empty physic body to contain some other physic bodies? Are Approach 1 and Approach 2 bad designs? Can Approach 2 be considered an improvement? Did you spot something (potentially) wrong? How to improve it? Am I a problem myself?
  7. Hi! From the video, It looks like a demo-reel of a game engine / pre-alpha of a game. The mentioned idea and graphic is similar to many games in the genre. Thus, it depends how well it is executed. Hope to see more progress when it is more done.
  8. I don't know much about the "commandblocks", but .... Here is an opensource Minecraft-like game engine (Terasology) I found several months ago :- https://github.com/MovingBlocks/Terasology/wiki/Entity-System-Architecture Here is a related discussion about it :- http://forum.terasology.org/threads/block-entity-behavior.792/
  9. 3d Physics and 2d Game-objects

    I mean ... Do you want a thing like this :- ? If so, use an external physic engine (e.g. Box2D) would probably be more suitable. If you just want a thing like :- It is not so hard to write physic engine yourself. (But I will still use Box2D for this case.) Just a random concern : AABB is not the hardest part of a general-purpose Physics engine. There are a lot of different way to do it. It depends on format of your 3D transform and 2D transform ... and your taste. First, let try your approach. It is not hard. You probably don't need any transform matrix to do that. If you face any specific difficulty about it, feel free to ask more.
  10. 3d Physics and 2d Game-objects

    It doesn't sound bad. Ray-cast is not so hard to code either - I believe it is a correct approach.. Is it your own game engine, and what is the physics engine that you selected? Will you implement the Physics yourself? .... Beware that if you happen to need proper collision response (bouncing cube , not snap to grid), it can take a lot of time and there are a lot of problems on the ways. I am not sure what you mean. Is 4x4 matrix OK for you?
  11. I never thought of this approach. Yes, Bullet doesn't support it, but it is possible and not too hard. Thank!
  12. Thank you everyone for many useful advises. Thank. It is my "default" mindset. I had implemented like this. It is very easy to understand and debug. However, in some rare cases (10% for me), the deletion is required to be delayed. For Bullet physics engine, it is the best to invoke collision callback in a batch manner. - update game logic --- MARK delete a rocket - propagate the MARK to physic object - update physic --- collision callback -> discover that the manifold between ... ... physic object p1-vs-p2 is no longer exist -> invoke Physic::collisionEnd(p1->userData,p2->userData) - delete every thing that was MARK-ed I believe that the correct approach is to delay to deletion of everything. Otherwise, the p1 can be a dangling pointer. It is also very handy to know for sure that p1->userData (which is Rocket instance) is not a dangling pointer. Thus, I adopt the "delay deletion" practice into everything. An alternative simpler approach is to let a system that handle rocket 1.broadcast and 2.invoke object deletion manually (like your example), but I prefer a more automatic way. I am not sure how game engine should support ownership relation that need the delay. I may think too much. The question makes me reconsider about many things. Thank. I am using semantic like this. It has run-time assertion. I am OK about it, but not sure if it is good :- relation_ownership->add(rocket, physicTriangle); relation_ownership->add(rocket, graphicWing); relation_ownership->add(rocket, barrier); relation_ownership->add(barrier, graphicLightSphere); I try to avoid share_pointer, because it is quite notorious - hard to debug / circle reference / slow. I also don't need it because I know the clear ownership.
  13. Thank 0r0d. I agree std::shared_ptr and std::weak_ptr are less error-prone. I didn't push the functionality to the entity because I am still too scared by this idea. There are a few cases that delete-flagging is more useful. First Reason : safer callback Suppose that :- A rocket E1 owns a physic body E2. The physic body E2 owns a Bullet physic internal entity E3. In a std::unique_ptr-style : a user delete a rocket -> E1 E2 and E3 will be deleted immediately (in reverse order). After E3 is deleted, the Bullet physic engine will still has a dangling pointer to the physic body (btRigidBody). It is quite hard to workaround this issue. Collision callback (collision-end) will be a mess. 2nd Reason : more multi-threading friendly By using flag, every entity is ensured to exist until the end of time-step. Component iterator is easier to implement and require less mutex lock. For me, such assumption make various parts of gameplay easier to code. 3rd Reason : cache friendly (not sure) With flagging, deleting is executed as batch.
  14. In my Entity-Component-System, every entity has Com_OwnerShip component. Com_OwnerShip = can own [0,∞) entity / can be owned by [0,1] entity For example :- a rocket OWN 1 physic object + 3 graphic object a rope OWN 10 physic object + 10 graphic object a physic object OWN 1 Bullet(R) physic internal object a game chunk OWN 16*16*16 blocks Here is a way to implement it (can be optimized further):- class Com_OwnerShip{ std::vector<Com_OwnerShip*> ownees; Com_OwnerShip* owners; }; At the end of every time step, I list every owner that was marked as to be destroyed, then mark all corresponding ownee entities as to be destroyed. The process is propagative. Then, I delete all "to be destroyed" entity in a batch-style. I have used it in a few prototypes and always find that it is very convenient. However, I feel that it is probably a bad practice. It probably share the disadvantage of Base_Game_object in OOP. (?) It costs a little more memory, not modular, too wildcard, too "duck-typing". It is a dirty-design (?). Nonetheless, it is better than Strong-Pointer (std::unique_ptr) because I can control entity/component deletion very easily. Is it a good practice? What are alternative approaches? Am I too nervous?
  • Advertisement