Tag Info

New answers tagged

1

I 'll try to manage InputController changing its behaviour at runtime (in c# can use some kind of delegates) Examples : if activated in_game state then InputController.processInput = logic1 if activated menu state then InputController.processInput = logic2 if activated inventory state then InputController.processInput = logic3 Logic1..N are alternative ...


1

In instances like this I use a stack of input maps. You already have certain buttons doing this or that while playing the game, if you can group that logic into a map (array of button/key => some event) then you can make multiple maps for the different states you have. From there you just need 'some event's that can be used to push and pop the maps from a ...


1

You aren't over complicating it at all. This is a great way to think about a game. It keeps the game flexible for any changes you want to add in the future (say a stats screen). The first place I would look is using the Strategy Pattern: Wikipedia Determine what input triggers you would need and add them to an abstract interface. Then, implement the ...


1

ECS doesn't make miracles and not all the problems should be solved by it. In some point you will need especific code about the specific logic of your game. You can put an "Invulnerable" flag inside your health component and a flag "PenetrateInvulnerability" inside the atack message and your system combat manage then.


0

Not knowing the language you're using. Create a property in the Entity Class bool invulnerable; Create a public method in the Entity Class Public float ApplyDamageAndReturnHP(float dam){ if (! invulnerable) return this.HP - dam; else return this.HP; } In combat system object, when evaluate a combat event, instead of using (I ...


0

I would create a bytecode interpreter for this, see: http://gameprogrammingpatterns.com/bytecode.html for a lot of details. Keep in mind that the bytecode is an example, but you can easily write something similar on your own using more readable instructions. The basic idea is the same though. So you write a bunch of small programs for each card effect. Then ...


0

In Java you can not have a class that is inherited from more than one super class. you better use Interfaces, because you can use more many implemented Interfaces. Interfaces are objects similar to classes. in Interfaces you can have variables and and methods, nut defining and giving values to methods and variables should be done in the class that ...


1

Note: I'm playing fast and loose with the pseudocode here, so let me know if anything is unclear. Ideally, the player shouldn't be special - just another set of components. The main function of entities is to group components. You might think of it this way: components get updates, not entities. From the good old Evolve Your Hierarchy article: Updates ...


0

Yeah, it's not necessary. When you detect a collision between A & B you should do something like: if (detectCollision(A, B)) { A.resolveCollision(B); B.resolveCollision(A); } This may not be how you do it, but you get the idea! If it is a problem that A has had it's values changed after resolving collision with B you could store the variables ...


0

You can write your engine in super classes. Have a game, an entity, etc. Then to make a new game, extend the game class which has your game loop. To add an entity, extend the entity class. So the game class would have a generic game loop. Your game would extend that game class and override the parts you need. The game class can be coded to handle the ...


0

One way to do this is by having the game be a dll and the engine being the executable. There are side benefits to this as well. If your main menu / matchmaker etc screens are in the engine and only actual game sessions use the game dll, you end up completely tearing down the resources used by the game between matches. This can help with memory ...


3

The answer to the question "Is it possible, or even feasible, to have graphics engine completely decoupled from game logic?" is "yes". I would say it is even "advisable". But in general, you'll find a lot of your game ends up tied to the engine you choose for other reasons, like input handling or use of their facebook integration or other cross-platform ...


3

It's OK to have component dependencies. And the more explicit the dependency the better. There's nothing worse than dependencies hidden behind useless layers of indirections. Your case doesn't look like a dependency hell to me. No circular dependency or unclear ownership of data: consider yourself lucky! Now I still believe that you need to reverse your ...


2

In my experiences there aren't too many ways around the fact that, you're right, all your different game entities and their components need to be aware of the state of the game and their own state. It's a mess unless you design with state machines in mind. The best way I've found to deal with it is to make sure that components are all doing small pieces of ...


0

You could develop a bytecode language for this. Take a look at this: http://gameprogrammingpatterns.com/bytecode.html Instead of spells as in that example, see the commands as 'walk to' and 'display message' and so on.



Top 50 recent answers are included