Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 08 Mar 2000
Offline Last Active Yesterday, 10:25 AM

Posts I've Made

In Topic: Unsure of What is Intellectual Property in Games

Yesterday, 10:11 AM

Ideas are not a form of intellectual property. Complex processes and mechanics can, in some cases, be protected by patent. But a simple game design mechanic like the one you are describing cannot be protected under any IP system I know of.


It's possible that a combination of a certain mechanic along with certain visuals might combine to form a violation of 'trade dress' laws if your game was so close to another in appearance that it could be argued that you are likely to confuse potential customers into thinking they are playing someone else's game. But merely "jumping below a block and hitting it with your head to make some sort of bonus item sprout from it" is not enough for this to be the case.

In Topic: Unity Software Architecture - how to make reusable UI classes that inherit fr...

Yesterday, 03:56 AM

Is this some weird sort of sprite animation? I can't see any other reason why you'd be trying to switch a texture every frame.


If you want to hide a UI element in Unity, then you disable the object itself or the canvas.


It looks like you're trying to make a direct 1-to-1 translation of your old code, but the new system isn't meant to be treated that way.

In Topic: Assigning slots in formations

Yesterday, 03:47 AM

I don't know about documented approaches but it's often enough to apply an iterative improvement algorithm to these problems. e.g.

attempts = 20; // or whatever
while (attempts-- > 0)
    auto unit1 = pick_random_unit_from_formation();
    auto unit2 = pick_random_unit_from_formation();

    if (unit1 != unit2 && paths_cross(unit1.current_path, unit2.current_path))
        swap_destinations(unit1, unit2);

It's not optimal, but it is cheap, and often that is good enough.

In Topic: TDD and predefined models

Yesterday, 03:11 AM

What is your experience?


My experience is:

  • unit testing is great. It's especially good for ensuring you don't break things during refactoring.
  • not everything lends itself easily to unit testing - but probably more does than you think.
  • make as much of your codebase unit testable as is practical - but no more. Don't break otherwise perfectly good encapsulation and interfaces to make something more testable.
  • test-first approaches seem like a waste of time, except in the small subset of areas where you're writing something well-understood where the boundary conditions are clear. They also seem to me like they give a false sense of security, given the emphasis on the pass/fail state of the test rather than the correctness of the code it is testing.
  • Wherever possible I like to write a new unit test when I discover a bug, and fix the bug to make the test pass. This way I know that the time on the test was worthwhile because it is covering code that was proven to be tricky!

In Topic: Commiting persistent server data

20 October 2016 - 03:42 AM

I don't think a single sorted file is the way to go, because they are not very practical. Hplus0603 already gave one good alternative - a file per user/entity/player. That way, the file system is your sorting mechanism.


If you really want it to be all in one file, with quick access to arbitrary parts of the file, then there's software that will do that for you, and it's called a database. Again, Hplus0603 mentioned some names above.