The description for Tortuga sucks.

Tortuga is a 2D multiplayer JRPG featuring permadeath (deletion of a character upon death). The emphasis of this game is on multiplayer cooperation, exploration and customization. The game runs on customizable server software that can support up to 150 simultaneous players or more.

It’s a horrible jumble of keywords, something that has been pointed out to me (quite rudely) in the past. The reason for this is that there isn’t a definite genre that my concept (I’m using concept here to represent my mental model that I’m aiming for at this time) doesn’t really fit into one specific type of game, but rather pulls from a number of different areas and experiences that I’ve had over my lifetime. 

Some of the most influential events in my life are:

  • Following Minecraft’s development cycle for years
  • Following Elysian Shadow’s development cycle for years
  • Discovering and witnessing the rise of the gamedev culture
  • Being largely isolated from said culture
  • Inability to afford a number of high profile games
  • Katawa Shoujo, Christine Love, Thorbjørn Lindeijer, Extra Credits and Rachel Morris
  • Harassment, abuse and abandonment from people I once looked up to

…and that’s just gaming and design related. I’m nervous about this interview tomorrow, that’s unavoidable. But I’m confident that I can show who I am, what I can do, and that I can impress them. Wish me luck.

I’ll be glad to get back to Tortuga tomorrow night.

I’ve got a job interview in the morning…. yeah, I’m nervous. My mum reminded me though, that they contacted me. They wouldn’t done that if they weren’t impressed with my skills.

This is a game development job, BTW, one of only three hiring studios on the continent. So if I miss out on this, it’s back to square one. No, think positive. 

I failed the test sent from Zindagi games, but I did send them the post mortem email. Since I try to be open about my programs, here it is.

Container.h

ContainerTest.cpp

After three days of searching, I must concede: my implementation does not pass the unit test, and I don’t know why. Regardless of my failure, here is my post mortem.

Time log:
24/7/2014: 6:30pm to 7:00pm (interrupted)
24/7/2014: 7:40pm to 10:40pm (coffee run)
24/7/2014: 11:00pm to 12:00am (basics finished)
26/7/2014: 10:20pm - 11L20pm (could not replicate assert error, line 145)
26/7/2014: 11:20pm - 27/7/2014 3:50am (bug hunting, failed)

Since I decided to implement the sorting algorithm, I worked with these restrictions in mind:

1. All storage management data structures must use the buffer.
2. All return addresses must remain the same; requiring no data movement.
3. Implement the sorting algorithm; requiring element movement.
4. It must be scalable and efficient; operator[] is used in various loops.
5. Maximize the number of elements possible, but 65536 is acceptable.

Rule 2 and 3 offered an interesting contradiction, and my answer was to create a lookup table, requiring only two bytes of overhead for each element. The unintended downside of this was O(n) complexity for CContainer::Remove(T*), which is enough to fail a test such as this. The only workable solution would be to store an element’s index next to it in memory, which would require another two bytes of overhead and complex bookkeeping code.

The issue that has threatened my sanity, however is the constant assertion failures at lines 145, 179 and 187. 179 could be the cause of a faulty sorting algorithm, but inspection of the container shows this not to be the case, but rather that all elements of the lookup table are pointing towards the same element. 145 and 187 are caused by a non-allocated element finding it’s way into the container.

I must end this now, in the hopes of preserving my last shred of sanity. I don’t expect you to try and solve my issues, but I’d still love to know what the cause is.

Yours,

Kayne Ruse

something-cubed:

moopington:

something-cubed:

moopington:

Can someone explain O(n) better than Wikipedia does? I’m confused.

Are you confused about the big picture of what it is, or the nitty gritty of how it works?

Big picture. I saw someone talking about it, tried Wikipedia and decided…

Dang, this is way better than mine, props.

Thanks. I’m gonna brag and say that this is the second time in two days that someone else was impressed by something I’ve done, while also understanding it too ^-^

moopington:

something-cubed:

moopington:

Can someone explain O(n) better than Wikipedia does? I’m confused.

Are you confused about the big picture of what it is, or the nitty gritty of how it works?

Big picture. I saw someone talking about it, tried Wikipedia and decided the article was over my head.

Let’s say you’ve got a structure of elements (be it a list, hash table, array, etc.) and various operations you can perform on it (shuffling, sorting, searching, etc.). Big O notation is simply shorthand for the relative effort needed to perform an operation on that structure. Here are some examples.

O(n): The time taken to perform an operation increases proportionally with the number of elements added.

O(n^2): For each element added, the time taken is squared. That is, a structure with 3 elements will take 9 units of time, whereas a structure with 4 elements will take 16 units. Think of it like this:

for i = 1 to 100:
for j = 1 to 100:
if array[i] == array[j]:
//do stuff

O(1), however takes the same amount of time to execute regardless if theres 10 elements or 10,000. You also get things like O(log n) and O(n log n), which usually do something on the inner loop that skips certain elements, like this:

for i = 1 to 100:
for j = i to 100: //starting from i instead of 1
if array[i] == array[j]:
//do stuff

The purpose of big O is simply to compare the effectiveness of extremely disparate algorithms against each other.

You can use this, if it helps: bigocheatsheet.com

So of the most perplexing issues:

  • Why isn’t this working?
  • Why is this happening?
  • Why does this only happen when X unrelated conditions happen?

Namely:

  • My test application’s custom container class
  • One element is apparently having it’s destructor called, but it’s not being removed from the container (that is, it’s index isn’t being swapped to a position above the count pointer… it’s complex).
  • Why is this happening when there are exactly 13 elements, and it’s always the first element that is having problems. Edit: The number of adds and frees is the same as well. So it’s not just random, something environmental is causing it.

If you don’t love this, then we can’t be friends.

Me learning new programming concepts.

"What the fuck is that? I’ve never heard of that before."

"Oh wait, I’m already doing this."

There is no reason why this sanity check should be failing. It is literally this:

assert(pObj == pObj->GetAddress());

The object’s address is stored internally upon creation, so it’s returning the “this” parameter received by the constructor. Why is it failing? IDK.

Son of a bitch. The unit test is failing on the address part. That is, the internal address saved from the constructor’s ”this” parameter is different from the object pointer. I think it has something to do with the placement new, but… I’ve actually never used that before, so I have no idea what I’m doing wrong.

A second problem is that the container’s remove method has an O(n) loop, which makes the unit test slower the more elements are stored in the container. As a result, it isn’t scalable, so I’m going to need to find a way to fix this.