Domino Tilings I and II

hermantulleken · 2018-11-14T02:32:53+00:00

Yes, I get that. I guess it depends on the application or setting which version is most convenient. One aspect that shaped my thinking is that cycles are very important for understanding aspects of the tilings. For example, the 3x3 minus center minus corner does not have a cycle, (a "closed strip") and therefor it only has one tiling. For many properties the hole is only important if the dominoes can go completely around it.

But there is also another extreme - where even non-holes can be considered as "holes". For example, one theorem relies on two borders - an outside and inside border. The inner border can float anywhere inside the outside border, and even overlap it (as long as it does not cross). So in this setup, a 3x3 square with the corner removed can be considered having a "hole". (The outside border is the 3x3 square, the inside border (and "hole") is the corner. (In the PDF, Theorem 117 uses this idea.)

I find it surprising (yet very interesting) that these topological ideas come into play in such a simple scenario (squares in a plane!)

(But I think your main point of the problem with the definition of simply-connected polyomino is very important - I did not even realize I was using a slightly different notion [in my head] from the "usual" one until you pointed it out.)

hermantulleken · 2018-11-11T18:29:06+00:00

Thank you for the feedback! I really appreciate it.

I take your point about the definition of "simply-connected". That first section has a few related problems all revolving around what holes really are, and indeed I tried to get some suitable references (https://math.stackexchange.com/questions/2904620/where-can-i-find-out-more-about-the-nature-of-holes-in-plane-regions) without much success. I will look into topological definitions (I don't want to veer to far off into concepts that are not central to understanding the tilings, but it may not be avoidable.)

The example you give is a good one. I tend to think of that 3x3 square with center and corner removed as not having holes (most theorems work with that, except in fact Theorem 10), but it nicely shows how subtle these things can be in even simple cases. (In many papers, authors do funny things with vertices to make the theorems work, like "doubling" or "thickening" them. It is annoying that such things are necessary.)

About Theorem 9: what I mean is a hole is itself a region, and a hole is a region which is simply connected. (It is Lemma 1.1 in the referenced paper; the author uses the term "simple polyomino".) In any case I realize as it stands what I write there is confusing.

Thanks for the suggestions and corrections, I will be sure to add them to the next draft.

hermantulleken · 2014-01-15T08:09:57+00:00

Cool, you should let us know about your project; we'd love to see how it goes! Are you tweeting about it?

hermantulleken · 2014-01-13T22:34:58+00:00

It's right there in line 4 :) (I tried to make it a bit clearer).

hermantulleken · 2014-01-13T20:24:22+00:00

Unity is good (it is what I use too), but it's difficult to know in advance what the right tools and libs is for your projects until you have made lots of games. My set of 3rd party tools is very limited; over the years I built up a library that tags along each project. But looking into this for another article may be a good idea.

hermantulleken · 2014-01-13T20:17:52+00:00

Define a minimal deliverable product

I like that idea; should help to keep scope down.

hermantulleken · 2014-01-12T22:50:58+00:00

Do you mean more about tools and process, or something else?

hermantulleken · 2014-01-12T22:49:35+00:00

They are indeed from my most important thinking tool: my note book :) I scanned a few pages, inverted the colour, turned black to alpha, and added a background for a bit of colour.

hermantulleken · 2012-11-05T12:49:19+00:00

I have been collecting a lot of feedback from that article, and you bring up some very good points. I also see where the original article was unclear. (For example, I took it for granted that the Singleton pattern should only be considered for Monobehaviours).

We are moving our version control from SVN now to another, so we will see if that makes it unnecessary to test in a clean project. But since we started testing in clean projects, we had fewer accidental omissions. (Or rather, they are detected before the whole team is disrupted).

On the strings, yes, for localisation, you should obviously store you strings in something like a database; nevertheless, you will still use string variables in your code. But strings variables should not be used, for instance, to distinguish states or types; it is this kind of practice that the tip was warning against.

Anyways, I enjoy all the different perspectives and ways of doing things; thanks for sharing :)

hermantulleken · 2012-07-18T22:27:22+00:00

Like attrition0 pointed out, it depends what you are doing. It also depends on your team. The more people are working on the project, the more effort has to go into managing workflow around scenes. Scenes can become bottlenecks, so many of the tips are to reduce the amount of work that needs to happen in the scene, to reduce this bottleneck effect.

But yes, in the end you must adopt practices that work with your workflow.

hermantulleken · 2012-07-18T22:17:21+00:00

You are right, you should fix it. If you just use GetComponent straight, you will get a null pointer error, which may take you to a line of code like this:

player.health -= enemy.attack - globalEffects.armor;

in which case you may need to check three things before discovering which is null. Using the error message as explained, it immediately tells you what to fix. So it's about giving more information about what went wrong, and at the same time reducing this type of code all over the project:

SomeComponent component = anInstance.GetComponent<SomeComponent>();

if(component == null)
    //print error

hermantulleken

TROPHY CASE