[Event] Cape Town Community Night - 25 October

edited in Events
This event happens monthly, is free to attend, and anyone may speak at the meetup - just comment beneath to let us know! This is for anyone and everyone interested in making games of any shape, size or type. Come join us!

Test games! Talk games! Make games!

When: 18:30 until around 21:30, Last Wednesday of the month

Where: Bandwidth Barn - 68 Albert Rd, Woodstock, Cape Town, 7925

If you have a demo you want played, bring a station on which people can play it, and set it up before the meetup begins!

- 6:30 - 7:00 - Meet and greet
- Rapid fire intros (10 min)
- Community News (5 min)

Talks - 2 x 20 min slots:
- Performance pitfalls of hash tables by @ChristopherM
- Open discussion on publishing, led by @damousey

Focused Feedback - 2 x 10 min slots
- Shattered Realms
- TBD (this could be you!)

Open Demo Floor

Facebook Event: https://www.facebook.com/events/370817150021584/

If you'd like to give a talk or show something to get some feedback, please post below!
Thanked by 1pieter


  • edited
    I could do a talk about the performance pitfalls of hash tables, but only if @Stray_Train can't commit to giving his presentation on tweening. In which case I'll save it for November.
    Thanked by 1francoisvn
  • I've just recently been informed that the Bandwidth Barn will have some renovations underway during the meetup. We are still scheduled to go ahead with the meetup as usual, although there might be some background noise, hopefully not too much.

    It's quite short notice for this month, so I recommend we keep the venue for now, unless someone has a better idea for a venue we can secure in less than a week. We might want to have a quick discussion at the meetup about November and see if we'd like an alternative venue.
    Thanked by 1damousey
  • Could we nab a feedback slot for Shattered Realms?
    We're getting close to the demo that we intend to use to secure future funding etc and some fresh eyes, or even previous players revisiting it would be nice.

    We could also chat about how to approach publishers.
  • Im planning on bringing along a small prototype Ive been working on for the last little while. Definitely don't think it is far along enough for focused feedback but some playtesting never hurts...
    Thanked by 1francoisvn
  • Thanks everyone for playing and giving feedback on Shattered Realms.

    There were a lot of "Why the hell did we not think of this!" suggestions, which are definitely making it into the game.
    Thanked by 1francoisvn
  • Thanks for organizing another great meetup, @francoisvn!

    Here are the slides and script for my talk "Hash Tables and Dictionary<TKey, TValue>: Use With Care" in case anyone wants them. When I have time I'll turn it into a blog post and put it on Gamasutra.

    slide 1 (title)

    - First some background. Let's take a look at the generic IDictionary<,> interface.

    slide 2 (IDictionary<,> interface)

    - What we're most interested in here are the methods that take key arguments, requiring the table to perform a lookup.
    - Now let's take a look at the generic Dictionary<,> class.

    slide 3 (Dictionary<,> class)

    - Dictionary<TKey, TValue> is .NET's generic implementation of a hash table, sometimes called a hash map in other languages.
    - The strength of hash tables is that lookups are, in the average case, constant time operations.
    - Or in big O notation: order of 1.
    - For those of you that remember your big O notation from Computer Science, what does "constant time" tell us about a method's performance?
    - It tells us that the method's performance is independent of the size of the problem domain, which in this case is the size of the collection.
    - Does that guarantee that a method is fast?
    - No, because it tells us NOTHING about how much overhead a method may have regardless of the size of the problem domain.
    - In fact, let's take a look at some simplified disassembly from Dictionary<TKey, TValue>.

    slide 4 (Dictionary<,> disassembly)

    - First a hash is generated from the key. Then the hash is used to determine which bucket the key belongs in. And finally the bucket is traversed for the key.
    - if you're not clued up on the inner workings of hash tables, don't worry.
    - What's important to note here is that GetHashCode and Equals are not only virtual methods, but their performance depends on the key type and the comparer object.
    - GetHashCode and Equals on string for example are linear time operations! Which is why string makes a terrible key type for tables.
    - Also of note is the fact that there is a loop.
    - So two virtual method calls and one loop means that an absolute minimum of 2 branch prediction failures occur with every lookup!
    - 3 minimum if the key is not present and if there are collisions in the hash table, then there will be many more!
    - So now that we've established that lookups have a non-trivial overhead, even in hash tables, one of our goals when using hash tables should still always be to minimize the number of lookups that are performed.
    - Let's take a look at some bad code samples that I see far too often when programmers use hash tables or even tables in general.

    slide 5 (value retrieval bad)

    - The item property getter throws a KeyNotFoundException if the key isn't in the dictionary, so I often see code that first checks that the key is present before retrieving the value.
    - Of course this causes two lookups of the same key. So what should you do instead?

    slide 6 (value retrieval good)

    - The TryGetValue method does the check and retrieval in a single lookup.
    - So if you want the value to a key that may not be in the dictionary, use it!

    slide 7 (value setting bad)

    - In this example, the programmer wants to change a key's value if that key is already in the table, but add the key if it is not.
    - In either scenario this code will also have to perform a lookup of the same key twice.
    - When I see code like this, I do this:

    slide 8 (facepalm)

    - Why?

    slide 9 (value setting good)

    - Because all of that logic is already encompassed in the item property setter. It says so in the documentation to IDictionary<,> and Dictionary<,>, so there's no excuse!
    - If a method's behaviour isn't crystal clear from its signature alone, RTFM!

    slide 10 (enumerating bad)

    - In this example, the programmer wants to do something for each entry in the table that requires both the key and the value.
    - If you do it like this, a lookup is performed for every entry in the table. When I see code like this, this happens to me:

    slide 11 (rage)

    - So how do we avoid that?

    slide 12 (enumerating good)

    - By enumerating the table as a whole, which gives us generic KeyValuePair objects that group keys with their values. Now NO lookups are performed during the enumeration.

    slide 13 (the end)
Sign In or Register to comment.