# dmatter

Member

2743

4849 Excellent

• Rank
Contributor

## Personal Information

• Website
• Role
DevOps
Programmer
Technical Director
• Interests
DevOps
Programming

daveagill
• Github
daveagill

## Recent Profile Visitors

19620 profile views

1. ## Issue re-arranging equation

The closely-related nature of multiplication and division means that this is simply not true. Any division can always be re-written as a "multiplication of the numerator value with the reciprocal of the denominator value" and vice-versa. Which is just a fancy of saying this: a / b == a * (1/b) We can apply this rule to a more complex example: (a * b) / c == (a * b) * (1/c) Notice this is now the same shape as your equation if you just substitute: a == 4, b == sin(theta)^2 and c == x. Ok, so the next step is to know that multiplication is associative. Meaning that it doesn't matter which order we use to collapse terms together (e.g. (2*3)*4) == 2*(3*4)). Since the order doesn't matter we can safely discard parenthesis for associative operators like multiplication: (a * b) * (1/c) == a * b * (1/c) The other useful property about multiplication is that it is commutative. This simply means that we can safely re-arrange the sequence of operands without changing the result (e.g. 4*5 == 5*4): a * b * (1/c) == a * (1/c) * b The final step is to recognise that we can convert a * (1/c) into simply a/c by applying our original rule about the relationship between multiplication and division, only in this time reverse. This gives us: a / c * b Let's replace a,b & c with your terms to arrive at your final result: a = 4, b = sin(theta)^2 c = x a / c * b == 4 / x * sin(theta)^2
2. ## Slow pathfinding problem (A*)

^ This. No need to recalculate a whole path for each enemy. Basically if you've got 50-100 enemies all trying to find the same player then you can just score all nodes based on their their distance/cost to the player node; do that just once and then each enemy only has to move to the lowest-cost node adjacent to it. You only need to recalculate the node costs if the player moves or the world changes.
3. ## Looking for advice on Java game server

I am going to answer specifically for Java & Websockets. I can't tell you whether this is the best technology choice or not for your game that's entirely up to you. There is no correct choice here but there are a variety of solid options available to you. And by that I mean they're tried, tested, well(ish) documented and have active communities using them so you can ask questions online and reasonably expect someone out there will know the answer. This is not an exhaustive list mind you. Just some of the more common options to help you evaluate: Use a full-blown JavaEE appserver like Glassfish, Wildfly, TomEE, Weblogic, Websphere. This is the enterprise way to go, you have everything and the kitchen sink available to you. This is particularly useful if you think that you'll want to use other JEE standards for the purposes of managing logic & state, transactions, databases, etc. Use a JEE servlet container like Tomcat or Jetty - Good if you are only interested in the web subsets of the JEE (like servlets & websockets). These can also be embedded so that your application can run standalone. Here's an example I found of Jetty embedded as a websocket server. Use a JEE server generator like Wildfly Swarm - This lets you pick and choose just the bits of the JEE that you need and lets you link them into your application so you can package the whole thing up into a single jar. Allowing for more light-weight servers when you only need a few JEE dependencies. Use the JSR 356 (websockets) reference implementation - If you are simply only interested in running a websocket server using Java's websocket API but without any other JEE gumpf then this is how to do it. Use the Play Framework - This is not JEE, it's not 'standard'. It's a Java & Scala web framework with a fresh and modern air to it. This is probably the newest player to the field. Use Spring Boot - Spring has always been the main alternative to JEE. JEE has come along way in recent years but historically where JEE has been lacking features or was complex to use then Spring was easier, cleaner and more feature rich. You can use the Spring Boot websocket starter to get up and running quickly.
4. ## What am I not understanding about programming?

I suspect you're hitting Analysis Paralysis by getting too hung up on doing things the "OO way". Pong is really no different to any other kind of application: It gathers input It processes that input into some state It presents that state as output The only notable variation is that for a real-time game those 3 step needs to occur every single frame. So all we do is wrap them up in a game loop like this: World world; while (true) { Keys keysPressed = checkInputs(); // input update(keysPressed, world); // process render(world); // output } World maintains the state of the game (paddles, players, scores, ball, etc) and its public methods model the interactions that you have available to you when playing. In the case of Pong it might have a method like: movePaddle(amount). The update() function knows how to convert inputs (keypresses) into actions that modify the world. For example it knows that if you push the right-arrow key then it will invoke: world.movePaddle(1); The job of the render() function is to translate the state held by World into something visual. If the process of rendering requires state all of its own (textures, shaders, models, etc) then a simple render function isn't enough. That's fine. Just make it a method in a class: renderer.render(world); This class can now hold all that rendering gumpf, available only to the render() method. Of course as you scale this up to larger and larger applications/games you'll find that these pieces become bloated. At which point you'll want to start sub-dividing ("refactoring") them. For example you can move code out of your World class into Paddle and Ball classes and World just glues them together. Or you might move code out of render() (or Renderer) into renderPaddle, renderBall, etc. This "refactoring" process helps keep your code organised and maintainable. But it's not where you start. You start simple and you subdivide structure into it only when needed. This is how we all do it! With lots of experience we developers can sometimes foresee what sort of factoring is appropriate and then shoot straight for that. But in reality it's an unreliable process (because we're only human, we stumble across pitfalls or we learn something new or requirements change). Ultimately it's a skill that you will never master and you will never stop improving!
5. ## Day 2

WoA? What's going on here? Are you making this game for real or purely theoretical?
6. ## WoA: Too disappointed to participate again?

Yes why not be a judge yourself next year? Re Rant1: Personally I don't believe a judge would need to play a game through to completion to accurately award the categories. Ideally they would play more than the bare minimum, sure, but attaining 100% might not even be feasible. Re Rant2: While tis unfortunate jbadams was unable to submit his scores before the cutoff don't forget that it affected all entries not just yours. Imagine if 3 judges had been the plan all along then you wouldn't even feel slighted. So maybe don't sweat the small stuff? I do agree more judge scores would likely reduce the influence of anomalous results on the overall average. Having said that, a small number of judges who bias against various traits adds a dynamic to the competition. For example Riu is obviously a graphics guy and conceivably you could exploit that fact or it could sting you hard! If we had a bio for each judge it would help with that. You guys made a good game. It has flappy-bird-esque difficulty, good graphics, it's entertaining to watch other people play, the idea is novel, it's complete and bug-free! Don't be disappointed, be proud!
7. ## WoA V - Afterparty/Judging thread

Congrats all!! There were some very exceptional games made this year that people can be pretty damn proud of! I just want to give a huge shout out to @slicer4ever for running the show, to his fellow judges (@riuthamus , @Alpha_ProgDes and @jbadams) for their valuable time and to Slicer, @jpetrie and @Lactose for their valuable cash into the prize pool. A very generous bunch of people! As always that was a lot of fun!

9. ## Object-oriented vs loop-based programming?

^ Exactly. If you're dispatching behaviour per-type from a pure-virtual-interface, then you're probably on steady ground with inheritance (†). But if you're trying to "common stuff out" with inheritance according to what you perceive is common between classes then you're probably doing it wrong. The design of interfaces should actually be driven from the needs of the caller: What behaviour do callers need to dispatch in a type agnostic way? † Unfortunately inheritance forces you to make an up-front decision about which interfaces you want to implement, at the author-time of the class. Then the dispatch is performed at run-time. Most mainstream languages work this way. But that can mean that inheritance is still a poor choice for certain use-cases.
10. ## Object-oriented vs loop-based programming?

Ah but even that's not what I consider to be a good use of inheritance! Here you just need two free factory functions: Solider BLU_Missile_Soldier(); Soldier RED_Rifleman_Soldier(); (You also don't need a virtual destructor because you have nothing to destruct in the subclasses). (You are also potentially leaking memory in that snippet - but that's unrelated to inheritance).
11. ## Object-oriented vs loop-based programming?

Yes I agree with that. But not all tools should be used equally. If inheritance is your hammer then everything will start to look like a nail. Really it should be that tool at the bottom of your toolbox that you get out begrudgingly sometimes while muttering noises about how C++ should just have better constructs to solve the problem at hand. (Even though you know that's never gonna happen for C++) (Note, just to reiterate: I'm not talking about pure virtual base-classes or interfaces or protocols or traits or whatever your favourite language calls them. I've few gripes with those. I'm talking about any other uses of inheritance). Sure! I mean call it whatever's fashionable, I just call it a list of bounding volumes E.g. in C++: std::vector<BoundingVolume> (emphasis mine). I honestly don't see the problem with that. This isn't something I would be trying to 'solve' my way out of. In my games that happens all the time! Usually I'm not interested in just testing "if there was a collision", usually I want to know what was collided with so that there can be different behaviours in response to different kinds of collision. For example I want different behaviours when my player hits a solid wall compared to if they hit water or lava or they get hit by a bullet or they get a health pickup. That's 5 different object types (Wall, Water, Lava, Bullet, Health) with 5 different reactive behaviours for my player upon collision. One way (but by no means the only way) of handling this might actually be to loop over each type of thing separately (psuedo code): func processCollisionsWith(things, interaction): foreach thing in things: if collided(thing, player): interaction(thing, player) processCollisionsWith(walls, HitWallInteraction) processCollisionsWith(water, BeginSwimmingInteraction) processCollisionsWith(lava, BurntAliveInteraction) processCollisionsWith(bullets, TakeBulletDamageInteraction) processCollisionsWith(healthpickups, HealthBonusInteraction) This also means that I get to decide the processing order, for example if I want all health-pickups to be handled before anything that might cause damage (like bullets) then I can make that happen easily and explicitly here.
12. ## Object-oriented vs loop-based programming?

My default setting is anti-inheritance as a rule-of-thumb. It's fine to inherit pure interfaces, no real problems there, but once you start inheriting implemented methods, data-members, any multiple-inheritance whatsoever, etc. Then it's a slippery slope towards brittle code and poor reusability. There are times when it makes sense of course, but in my experience most people will tend to abuse it. In fact where I work we monitor any and all use of inheritance closely and we treat it with suspicion in code-reviews of newly written code. So with that in mind... Are you though? Inheritance is not the only way to share or reuse code. If that was the case then languages without any inheritance would be seriously screwed! One option is if you have a list of bounding volumes then you can just write 1 loop and check against all those volumes. That will work regardless of how many object types there are in the world (no inheritance needed either). This is similar to how a physics engine would do it. Alternatively, maybe for each of those 10 different object types you want 10 different behaviours for when there is a collision. That means 10 different implementations anyway, so why not just have 10 different loops!
13. ## Object-oriented vs loop-based programming?

That probably works in your favour, there's a lot of people out there just itching to teach you bad OO in exchange for money! The only problem here may be the size of your World class so you might just want to carve it apart somewhat. For example If you find you have a bunch of code in there just for managing projectiles (spawning them, recycling them, detecting when they've hit something, etc) then factor all of that out into a ProjectileSystem and have World hold an instance of that. In principle though, having something that represents the 'active state of your game' along with update() methods that transition from state(t) to state(t+1) is a good design choice. Just don't overload it with other responsibilities such as rendering, audio, etc. If you treat or process player[0] differently then better to move it out of that array: Player player; Player ai[10]; No issues there! This is also fine! I do the same thing myself. There is no problem with this thinking. In fact there is a recent trend towards that kind of thing because uniformly processing an array of same-kinded objects in sequence is good for cache coherency and branch-prediction. When you start hitting up objects that are allocated all over the heap and invoking virtual methods on them all, then performance starts to take a hit. (Although Moore's Law is always hard at work to mitigate this!).
14. ## WoA V - Afterparty/Judging thread

Sure I'd be happy for that! (You'll probably do a better job at formatting it than I've done on my own site )
15. ## WoA V - Afterparty/Judging thread

Hi All! Here is my Post-Mortem of "Invasion of the Liquid Snatchers!" http://www.gilldave.co.uk/2017/08/week-of-awesome-5-post-mortem/ I've had a few people reach out to me about the fluid simulation and I've seen some of the community reviews speculating on how it works. So I've also written up a technical article dedicated to that: http://www.gilldave.co.uk/2017/08/fluid-rendering-with-box2d/