Two weeks of programming

Well, it’s been two weeks since my last post, so I’ll go through what I’ve done the past weeks.

Last week we were introduced to network programming, which I’m very interested in and have been ever since I played Diablo II with my best friend, wanting to learn how it ticked.
It isn’t my first contact with networking in practice or theory, back in high-school I went to a networking course where we learned the OSI-model among others. even if it was mostly practice related with Linux, it was plenty of theory as well; how TCP and UDP works, how a connection is established with a three-way-handshake (in TCP) and that UDP is pretty much fire-and-forget, you either get a response or you don’t (though the program we used sent another package if it didn’t get a response in a timely manner). So the first lecture was not anything new for me, though it was very refreshing to hear again, with a more programmer-oriented point-of-view.

The following lectures were not so confusing except that I had to rewrite a lot of the code to work with my Mac. I don’t have to use WSA startup or shutdown for example, as it is Windows specific. I also don’t have a Socket class, but instead use a generic int to point to the socket (like a index). Sockaddr_in on Mac doesn’t have the address split up into 4 octets (chars) either, but rather use inet_addr(char*) to get the binary equivalent of that address, so a string ”192.168.1.5” would be passed in with .c_str() to get a int value which would be in binary ”11000000 10101000 00000001 00000101. This could probably be improved for better readability by using a struct of 4 char or int:8, which I believe WSA does.

Other than that, it’s only some minor name changes (closesocket is just close) and I have to include more libraries.

During the weekend I fixed a Linked List class, it took me about 2 hours to create and another 2 to refine it. I decided to take another 2 private members to the class, an unsigned int for index and a pointer for the last node in the Linked List. The last node was just to ease the pop_back and push_back functions, push_back was easier since I could add the new node unto the last node and then reset it to the new node, which is more efficient when adding (the bigger the List becomes the longer it takes to get to the last), though it doesn’t do much for when you are deleting. Index was just to ease when calling for size, as it doesn’t have to loop through the elements to find the size. It is more efficient at the small cost of 8 bytes per Linked List, it do stack eventually, and can become several kilobytes in very big projects, but a few kilobytes to improve efficiency is a good tradeoff in my opinion.

This week (last week as of writing) we worked on rendering with DirectX. I’m biased when it comes to the DirectX vs OpenGL war, as I am using Mac and Linux quite frequently (as of last year, I’m only ever using Windows to play games ( which happens less and less too)), I am heavily in favour of OpenGL. It is not that I particularly like OpenGL, in fact, I think it worse on several aspects, but the one restriction that put DirectX low on my list, it is Microsoft only. Since I tried out Linux 10 years ago, I’ve been in favour of cross-platform, and after using Mac OS X for a year now, that feeling have only become more intense.
The reason I want to learn and am interested in network programming is because I eventually will work with it. Wether it be MMO or MO. If it has a dedicated server, the only OS that comes to my mind is Linux, Windows is too… flashy. A lot of the resources goes to waste providing the desktop, this, in my opinion, is very counter-productive. A server should be the bare minimum for background applications and the resources should be dedicated to the software it runs, not be wasted on a desktop you won’t see anyway.

I can’t say much about 3D rendering yet, it is a complicated topic, especially the shaders. Our group have decided on using DirectX (though it was close that it would have been OpenGL, hadn’t I advised them to start with DirectX). I will take the theory behind the 3D rendering with me, and I’ll help my teammates in any way I can, if they get stuck. I will however try to apply this knowledge to OpenGL as well. My expectations of myself is to make an engine that can render with DirectX on Windows and OpenGL on other systems, as DirectX is superior in many ways.

Finally, this weekend I’ve been working on Binary Search Tree, I have it pretty much figured out, but I’m still struggling with how I’m going to do most optimally when I remove a node. I’m thinking that if i remove a more value, I’ll link the less value of it instead and it’s more to the less value, it’s confusing just writing about it.

Back to programming!

So I’ve not been programming much the past few months, and this Monday we got a wake-up call with a sudden contest; we were to make a program that compress an image and then decompress it to it’s original state. I came to the same conclusion as the others within a few minutes after looking at the image, break it down into blocks of identical pixels, check the next pixel with the previous to see if they match. Then count it up until they do not match, and create a block of ”color” and ”amount”.

My group struggled to make the program work and compress it (I assisted them and tried to organise the work between them). When it was about 1 hour left, I started doing my own version so that we would have something to show, as it had derailed completely. However, I started too late, and I could only manage to do the compression (and start of the decompression) into a binary file. We managed to compress it to around 6kb.

The purpose of the contest was to give us a ”oh, shit” moment of realisation that this is going to get hectic. A point well conveyed as no one managed to do the decompression correctly during the contest.

The following day I finished the decompression, by reading the file stream of the compressed file and from that data reorganise the pixels in the same order they came in (first in, first out). The result was the original image decompressed.

We also learned about templates, we learned about it’s pros and cons, the pros being that you don’t have to make a struct and or function for each data type (float, int, char, short, long, string etc.), it also won’t make a struct for int if there is no call for it in the program, this happening at compile-time. The cons were the drawback to the previous statement, it happens in compile-time, which means that it has to check all the code for calls to that template, each time you compile. This can greatly increase the time it takes for the program to compile.

We were taught about dynamic lists, binary search tree and linked lists this Thursday. However, I was home with an upset stomach and missed the lecture. I feel like I’ve heard it before, but I have to read up on it during the week, I believe one of them is the last in first out principle, but I’m not sure.

System analysis of Arkham Horror

Week 3, and our second game to analyse, Arkham Horror. I was sceptic that I would like the game, as the only time I have heard “Arkham” have been in the Batman series, which I am not too fond of. I was gladly surprised to see they got no connection what-so-ever, and I actually enjoyed this game quite a lot (though the games could drag on for a very long time).

The game is a co-op turn-based PvE. I will go through the objects first and later their relation.

The game board consist of streets and locations as well as rifts, the streets are connected to other streets as well as locations, and you can reach the rifts by going to a location that has a rift marker on it. It also has terror level down in the corner.

There are several decks divided by colours that are called encounter cards, when you stop your movement on a location on the board or in a rift, you draw a card from the corresponding deck. There are 5 different inventory (sort of) cards, Spells, Common items, Unique items, Skills and Allies. The first 4 of them can be acquired by buying them, Allies are acquired from encounters.

Mythos cards are drawn each turn, and spawn a rift/gate most of the times, if it tries to spawn a gate on a place where there already are a rift, a monster surge happens instead, where there spawns a monster on each open rift.

The character cards are the players avatar, it has speed/sneak, will/fight, lore/luck sliders on it, increasing 1 lore will decrease 1 luck, you may move the sliders each turn, by the amount of focus the character has. It also have stamina and sanity (high sanity is good for closing gates and for spell casters, while high stamina is good for monster hunting).

Clue token, randomly appear on the board and can be picked up by the players. Five of them are needed to seal a rift, a rift can always be closed.

Seals, put on sealed rifts, rifts can not be opened there anymore.

The bank (basically just a pile) have money markers, stamina markers, clue tokens and sanity markers.

The last object is the mythos creature you are trying to prevent from spawning, it has a doom counter, once it reach max, you fight him (never happened to us). Each Mythos creature have different passive abilities as well as active abilities. Cthulu, for example reduce all players max sanity and stamina by 1.

The phases could also be considered an object, but they are more a dynamic, each turn, you start by drawing a mythos card to see what happens, after that is the upkeep phase, where all players move their skill sliders and/or use items/spells that can be used on any phase or the upkeep phase. Then is the movement phase, where you can move around the board, sneak past enemies and the like. Finally is the encounter phase where you draw an encounter card, if applicable.

There are 3 ways to win the game, sealing all the rifts, closing X amount of rifts, or beat the mythos creature.

The properties are the following:

Game board: locations and terror level. The locations have colours and names.

Player: Character card, which in turn have: money, clue tokens, items, skills and allies. Each character card also have Stamina, Sanity, speed/sneak, will/fight, lore/luck, focus and a unique ability.

Monster: have a horror check (ranging from -3 to +3) and sanity damage, health, combat check (same as horror check) and damage as well as a sneak modifier (same as the other two)

Item: descriptions, cost and type (common, magical, unique, spell).

Mythos creature: special rules and doom level, it never actually appeared so I do not know how to to fight it or what it have for stats when you do.

Encounter cards: colour and special events (or sometimes nothing happen)

The relationships are the following:

Mythos phase is related to the rifts on the board, as well as the monsters. The more monsters on the board, the more the terror level rises, making the game and some monsters harder.

Upkeep phase is related to the player’s character and their skills.

Movement phase is related to the board directly, and indirectly with the encounter phase. It is also in this phase you fight monster if you run into them and can not sneak past them.

Encounter phase is related to the encounter cards and rifts, nothing happens if you stand on a street, unless the Mythos phase says otherwise.

The encounters are related to your characters skill sliders, which is related to how many dices you get to throw to make a skill check, the more you get to throw, the better.

The mythos creature is related to the game board or the characters most of the time, but sometimes only to his/her own encounter, depends on the creature.

The player is related to their character which is related to the board, they also have an inventory, which makes them related to the inventory cards. The inventory in turn have different relationships depending on the cards, some give a bonus to skill checks, some give bonus utility (ability to jump out of any rift, even if the original one is gone), while some give you the ability to move further in the movement phase or can be used in any phase to affect the board or enemies in some way.

From those points, I can with little doubt say that the core system is the phase system, as it connects all the other systems. However, if it was not for the other systems, the phase system would fall apart, remove any of the other systems, and the game would be very lacklustre.

The mythos system changes the dynamic each turn, and provides with special events.

The upkeep system allows for changing the outcome for the upcoming phases on this turn by giving an advantage or disadvantage on some skill checks, for example, you used your 2 focus to decrease luck and increase lore, turns out you needed luck this encounter phase, you are at a disadvantage.

The movement system is related to the board and monsters, which in turn is related to the combat system.

The combat system is fairly simple, the player’s will against the enemy’s horror, the player’s sneak against their perception, the players fight against their fight, the player have to throw X amount of dices and score Y amount of 5 or 6 to defeat the opponent, where X is your fight – their modifier for fight, and Y is their health.

The skill check system is very simple, your skill + any modifiers – encounter modifiers, and you need at least one of the dices to be a 5 or 6.

The encounter system is related to the players positions on the board, to determine which cards should be picked, these cards usually contains a skill check, but not always. If you succeed a skill check, you are often rewarded (if you are given an option to roll for a certain skill) or saved (if you are forced to do a skill roll), or both.

One thing that works on most of these systems, are the clue tokens, they allow you to re-roll a dice for skill checks, damage on enemies and seal gates.

I think the demographic for this game is varying. It is not overly complicated mechanics-wise, but complicated enough for a very young audience to drop it, I think the age group is somewhere around 11 to 40. It is a co-op game (well, intended to be), so this game is more likely to appeal to players that like to work with their friends to a common goal, rather than boast about their superior skills or kill each other (not for the PvP player).

The turn start with the mythos phase, where you draw a mythos card, sometimes it gives special events on the board, like giving the ability to get clue token, at the chance of being devoured (your character dies), other times it gives certain conditions, like increasing sneak or decreasing movement, other times enemies swoop down on players in the streets. Most of the times a rift spawn, or it starts a monster surge, spawning new monsters in the already open gates (if a rift is trying to open where there already are a rift), when a rift spawns, it always spawn one monster to defend it. enemies with a certain symbol will mov in a specific pattern.

Once mythos phase is done, the upkeep phase begins, here the players choose if they want to change their skill sliders, use items that are allowed to be used in this phase, if you don’t plan on moving from a place in a while, you might just as well decrease your speed and increase sneak, never know when it might come in handy.

Once the upkeep phase is done, the movement phase begins, in this phase, the player may move a distance equal to their speed (unless the have the deputy car which can travel to and from any place) + modifiers (like the motorcycle). If the player moves to a rift, they will enter it and be moved to the dimension it is connected to. If the player move to a location where there are enemies, they either have to make a sneak check to move past them, or fight them and end their movement (also applies if the monsters moves to the player in the mythos phase)

Once the movement phase is done, the encounter phase begin, each player that ended their movement on a location (or encounter square?) draw an encounter card during this phase, players in a rift draw a rift encounter. The encounter cards usually have a skill check, but not always, sometimes they are just events or choices (which may require a skill check). Most of the time when you don’t get an option to do a skill check, the bad result is losing health, clue tokens, sanity, all of the above or sometime be put in jail/lost in time and space. I think it is in this phase you seal or close a gate too, but I do not know if I caught on correctly on that.

System analysis of Capitals

Introduction

Our group (3) played Capitals, a tabletop card game, where you race to build 8 (or 7) districts and have the highest score at the end. To achieve this, you get to choose among 9 different heroes (with a set of 2 different heroes ranged from 1 to 9), the lower the number, the earlier you get to play your hand.

When it is your turn to play (unless you’re assassinated), you get to choose an action, which is either draw 2 district cards and keep one, or 2 gold. Secondly, you get the option to build a district (if you can afford it and aren’t bewitched or are the navigator).

The crown (who pick a hero card first) is given to either the one who plays the King hero card, or given to someone else if the Emperor card is played.

At the end of the game, everyone that built 8 districts get bonus points, as well as the gold for each district and a bonus if they have one of each of the districts colours.

Objects

Players, they are portrayed as either a lord in the capital, or rival countries trying to race for power.

Districts (cards), they are the foundation for the game, there are 5 types; religious, trade, noble, military and special (or non-defined).

Gold, the games currency.

Hero cards, with varying abilities and numbered 1 to 9.

The bank, it take care of the gold that the players do not have.

District deck, it is shuffled at the start of the game and hold all the district cards.

Graveyard, where the discarded district cards are thrown.

The crown, it determines who start the hero drawing phase.

Properties

Players:
A hand (of district cards).
A “wallet”, holding his money.
A hero (chosen each turn).

Districts, built ones.
District cards:

Color.

Special abilities, like removing another players district, ending the game early (at 7 district), being any colour at the end, so on and so forth.

Gold:
None.

Hero cards:
Number ranging from 1 to 9.
Color.
Special Action.

The bank:
Money.

District deck:
District cards.

Graveyard:
District cards.

Crown:
None.

Behaviours

Players:

At the start of the round they pick a hero card to represent them for that round.

Once it is their turn, they get an action, either drawing cards or get gold.

After their action they can use their hero’s special ability, and then choose to build a district.

District cards:
If it has a special ability and is built, it may execute that ability when the requirements are met.

Gold:
None.

Hero cards:
Execute their special actions, unless they’re bewitched or assassinated.

Bank:
Gives and take gold.

District deck:
hold the district cards.

Graveyard:
Hold the discarded district cards.

Crown:
Starts the round.

Relationships

Gold is the resource of the game, you need it to build districts, and some hero cards let you either build for free or give extra gold.

Districts gives bonuses to certain heroes depending on their colours, like the Abbot gaining a bonus gold for each religious (blue) district you own, or the King a bonus gold for each noble (yellow) district you own.

Heroes determines how early you get to play, and the first 3 (Assassin/Witch, Thief/Tax collector and Wizard/Magician) usually target another player. Getting to play first can both be considered good and bad, a Witch cannot build during it’s turn, but when (and if) the player he bewitched does play, he also gets this hero’s special ability.

Number 1 is designed to hinder other players.

Number 2 to gain gold.

Number 3 are related to looking at/trading another players cards.

Number 4 is to move the crown and related to the noble districts.

Number 5 is related to religious districts.

Number 6 is related to gold either gaining it through trade (green) districts or keeping it from building districts.

Number 7 is related to the players action and build phase.

Number 8 is related to the other player’s districts and gain bonus gold for each military (red) district he owns.

Number 9 is a miscellaneous card, being very situational.

The bank gives the player money, and takes them when the players want to build a district.

District deck, the players draw district cards from this deck.

Graveyard, the player’s discarded district cards are thrown here, some might be retrieved through special districts abilities.

The crown is passed on through hero card number 4, and it determines which player pick a hero card first, there are a certain district card that makes a player loose his turn if they don’t say a line when their turn starts (and the crown bearer with the district notice it).

A typical round

First the player with the crown shuffle the hero cards and then put one card face-down and 1-4 (depending on the amount of players) cards face-up, which can’t be played that round. He then choose one of the cards that are left, the players following each drawing a hero card until the last player, who also can draw the face-down card.

The player with the lowest number then start their turn, doing an action (1 of 2 cards or 2 gold), playing their hero’s special ability (assassinate with the Assassin 1 Card) and (unless they are the Witch, in which case the first have to bewitch someone) choose to build a district (if they have enough money).

Then the one with the second lowest number plays their turn, unless assassinated. If bewitched they can’t use their special ability nor build that turn. If they played the Navigator, they may take two actions, but may not build.

repeating up until the last player have played their hero card.

Good parts

It is a very tactical game, you have to weigh between trying to bolster your own advantage or trying to put a leg in front of another player to give them a disadvantage. If you play the Assassin or Witch, you have to accurately determine which player is playing what card to be able to put a disadvantage on that person, Witch can’t even build if they fail to bewitch someone. During the picking phase, you have to consider that the Witch, Assassin or Thief might target you, and have to weigh whether to pick a beneficial or another hero card to not be targeted by them. Playing mind-games on the others are a crucial and well-implemented feature of the game, making the game play out differently each time you play it.

Not-so-good parts

Number 1 Witch have a decent drawback, making it much less useful if you can’t predict which card is going to be played. Number 1 Assassin have a similar benefit (playing first and destroying for other players), however, it doesn’t have a drawback if you can’t predict the other players cards, except you can’t make them lose a turn. It kinda felt like an overpowered card.

The same goes for number 2 Thief/Tax collector. However, they are still somewhat balanced, as the Thief might be able to steal all money from someone, though if he fails, he won’t get anything, while Tax collector don’t have to choose a target, he get one gold from any player that build anything during that turn.

Number 9 seems very situational, it would be a card you play if you do not want to be targeted by the Witch, Assassin or Thief, as you normally wouldn’t want to pick this card, as you get to play last and they provide meagre benefits. If this card got some better benefits, it would feel more worth picking, as it would be a high risk, high reward card, right now, it is a low risk, low reward. Compared to the low risk, high reward card Assassin.

Interesting parts

The tactical part of the game was definitely the most interesting part of the game, the feeling of “yeah, I did it!” you get when you manage to decipher what card the one you want to destroy for has, or when you avoid being struck by their attacks by picking the card they wouldn’t think you have.

Target audience

The game seems to be mostly centred on males who like mind games and strategy, as the theme is mostly on wars and intrigues, though girls who like to play mind games on others could probably like this game as well. People that want fast-paced gameplay will most likely not like this game, as a majority of the time is spending time figuring out your competitors.

Summary

It is a very strategic game which put your person reading abilities to the test, the hero cards does a good job of raising the strategic value of the game. However, the district cards are very much less so, there isn’t much strategy regarding these cards, and they will be built whenever there is money to build them, the exception would be the purple cards, but their strategic value is much less impactful than the hero cards. The Armoury is a strategic district card as well, giving you the ability to destroy an opponents district card, and when not played, give the other players something to fear.

Finally, the hero cards are somewhat unbalanced, number 1 is almost always preferred over anything else, there is no penalty for using the Assassin for example, which makes it rather boring, the Witch is a high risk, high reward card, and the high reward outweighs the risk pretty much all the time.

Number 2 through 8 are mostly balanced, some could need some more penalties (the Alchemist could maybe return half the cost, instead of full refund when building), number 9 however is too situational and would need some better benefits to outweigh the drawbacks, or making the rewards at a much higher risk (if no one plays card X, reward, else, punished, or the inverse, someone plays card X, reward) and improving the benefits greatly, so it’s a high risk, high reward card to play.

Week 9 – With Intent

Almost at the release, and that persistent sickness that haunted me last week is now gone, which means my productivity increased as well.

This week I’ve mostly been working with the SoundManager (or more accurately: the SoundEntity and MusicEntity), the version we had was working up ti’ll Beta, but in the final, we need a listener for the sound, otherwise the sound of the guards steps would be heard from anywhere on the map, that would just be…. strange.

Now to the problems that needed solving; we needed a position for the sound for the listener to work (I will go deeper into this soon). A minimum distance of the sound as well as the attenuation (the rate at which the sound fall off past the minimum distance). I also needed a way to see if music was muted (the music would play even if it was muted in the menu), so I created a MusicEntity that worked similar to the original SoundEntity. And a listener, being the players ears.

The first problem couldn’t be solved without revising most of the original SoundEntity. As the SoundEntity originally held both the buffer and the sf::Sound, and we would only allow one SoundEntity of the same type to be loaded into memory, this meant a sound could only have one position as well, the result; ”teleporting” sound for EACH step a guard took, it would then jump all over the place. To solve this, I changed it so the SoundEntity held the buffer only, and contained a function to create a new sf::Sound linked to the buffer, so that new steps would create a new sf::Sound with the same buffer. Each holding their own position.

The second problem is the minimum distance and attenuation; a buffer can’t hold these values, so I had it stored in two variables in SoundEntity. This led to the CreateSound() function (originally it just returned the buffer to use on your own), that set those values before passing on the created sf::Sound. It takes one argument, a sf::Vector2f, being the new sounds position.

The third problem was the absence of control over the music, I created a MusicEntity to help with that, it did most things that SoundEntity did before the revision; holding a static bool telling us if music is muted or not. A new static volume variable to give a consistency of the volume. A Play, Stop and Pause function, doing little less than calling the sf:Music’s respective functions, except Play which check if it’s muted before playing. And finally functions to set and get volume as well as switching between muted and un-muted, and a bool check if it is muted.

The last problem was the listener, I had to decide where to put the listener, and finally decided to add it to the SoundManager class, it being closely related to each other. We also pondered wether we should use targeted listener (i.e. directional sound), but decided against it, as it would feel odd to hear the sound coming from the right speaker when the cause of the sound is on the left side of the screen (should you go down). The SoundManager was largely untouched except for the addition of the listener as well as a Toggle/Mute sound and music function, and some minor changes inside the functions (mostly name changes). The listener’s position is changed in the Update() function, now taking an argument, the players position.

I’m probably well over 400 words now, but I still need a picture, I’ll add a (hopefully) descriptive image:

The sounds position is at the footstep (where it’s created), it is heard at full volume until the first circle, and gradually gets weaker as it reaches the second circle (actual distance and rate of fall-off can be adjusted), the sound can’t be heard past the second circle. The listener (the player in this and most cases) is within the second circle, but past the first, which means it would be heard, but not at full volume, giving the impression that it’s far away.

Week 8 – With Intent

Hello and welcome back, The last week has been a real pain in the ass. I believe I mentioned last week that I got some work to do the then upcoming weekend, I did, and received my payment for it. This also means that I was pre-occupied this weekend and thus my productivity reached a minimum.

This monday I already started to feel the cold lingering closer to it’s eruption point, I had hoped that it wouldn’t break out, and if it actually did, not to such an extent. This Tuesday I couldn’t swallow because of the throat pain, any attempt at doing so warranted in a cough attack worsening the pain further to the point where I coughed blood. This Wednesday the throat pain had lessened but I was confused to say the least, my second attempt at doing something worthwhile resulted in me going to get some cough drop, only to stare at my deodorant and for a minute wondering how I should drink it… yeah…

tl;dr
I’ve been busy working or sick for the last week.

Now to what I actually achieved this week, aside from deciding that drinking deodorant probably wouldn’t make the throat pain go away.

After working with the SoundManager, I felt it lacking in it’s functions, Songs and Sounds being vectors would mean that I’d have no way of confirming wether the sound had already been loaded or not, which would result in a memory leakage unless we made sure that no sound was loaded twice. I felt that this was lacking, and so I decided to change it a little.

First I changed the vectors to maps and linking them with a string, to prevent them from being loaded twice (you can still load a song and a sound with the same file name) and made them private members, since that is what I’ve been taught to do. I then created some functions to do what the public members did before, and changed the newSound() and newSong() functions to return a string instead of an int. This takes some more space in the memory in short-term, but saves up a lot in long-term since there will be no duplicates, and a string is easier to use than a number. For example: it would be easier to type the filename like ”../data/song.ogg” than to remember that this particular file has the number 4 or 3102.

The new functions are GetSound/Song GetSound/SongCount, Set/GetSound/SongVolume and ToggleSound/Song. ToggleSound is already implemented on SoundEntity to enable and disable sound, but sf::Music doesn’t have a Toggle Function yet (so the music still plays outside the StartMenuState even if muted). Gustav and I also fixed the volume for new sounds to match the first element, so that the volume is consistent throughout, though it was not implemented in the latest version for one reason or another.

Finally, how can you take a screenshot of ”Sound”? I’ll just settle for this one.

Week 7 – With Intent

There isn’t much I can write about this week, since I got a sudden call this Tuesday. I’ll be taking the ferry back to the mainland tomorrow afternoon, I’ll earn some money from it and the traveling expenses is being paid, I couldn’t really pass up on that now could I?

During the last weekend and into Monday, I’ve been working on the Collision Manager, Unlike the first version of the collision manager that took 2 arguments (position and radius), the new one takes only 1 argument, a sf::Sprite, since sf::Sprite contain the position (as well as means to calculate the center of it, which is the previous position) and the variables needed to calculate the radius to the furthest point in the rectangle (one of the corners). The only exception is the collision with furniture that also has the Furniture as argument. Unlike doors, you can collide with two or more different furnitures at the same time, so they can’t return the object it collided with (it won’t check the collision on the objects after it).

After looking into DoorManager and showing it to our Producer, Henrik ”Stickan” Forsman, asked if the use radius of the doors could be similar to the keys use radius (declining intensity), and after looking into it, I decided that it would be easily done if I just used the same principle as with the key; pre-rendered light using the Light Engine, as shown in the picture below (it’s a little hard to see since the light is still kinda disturbed on Mac)

The rest of the Monday and Tuesday I’ve been working on the GUI (or HUD, we can’t seem to decide what to call it). As you can see in the Picture above, the key up in the right corner is the same colour as the door’s light. As I mentioned in my earlier post, the keys and doors are connected by sharing the same colour, this not only gives a wide variety of keys we can use (16 777 216 different combinations to be exact), but also provide an easy way to connect the colours for the player; a player wouldn’t try to open a door with red glow if he only has a green key.

There is a lot of different distinguishable colours that we can use: Red, Green, Blue, Cyan, Magenta and Yellow, just to name the colours RGB and CMYK use, the former commonly used in technology (where the light is emitted) and the latter for printing (where light is reflected). SFML, as many other libraries, use RGBA (A standing for Alpha, which is opacity). 

Week 6 – With Intent

This week Have been pretty harsh, the Light Engine ”Let There Be Light” is obviously not optimised for OpenGL properly, so put out more than 2 update-able lights and you get some serious bugs on OS X.

I see no way around this unless I reconfigure the whole LTBL library, which I don’t really have time for right now. For testing Purposes with less lights I can still test the code on Mac with the Prototype, for the full game I simply have to rework it on Windows. I’ll return on this at a later date when I have spare time to fix it.

 

The Keys have a separate Light Source, so that they give off a glow (right now even in the dark), we wanted the Keys to give off a glow to be easily recognised as something you want to pick up (which kind of contradicts our philosophy that all light is harmful). The Key’s color match the color of the door it’s connected to, so if you find a key with a green glow, you know it’s the green door it opens. Initially I had the Pick-up radius visible (as the glow effect was suggested a little later), but now it’s only used to see if you are close enough to pick up the key, since the glow have the same radius.

lastly, Ive found another annoying difference between Mac and Windows, Windows use not only CLRF, but it also does not use UNICODE per default (saving the file from C# still does). Which means that special characters like § have different keycodes if saved from notepad for example, since the Encoding is different. I could go around checking the Encode, but I fail to reason that way, since UNICODE have been the universal encoding for many years now. There is no reason to use anything else. I could also check for either of the keycodes, but that may give unexpected results in case the keycode is used for other characters on the opposing encoding (which is likely).

Also, something saved on Windows have an extra line-breaker ”\r” (which Windows compilers ignore) that have to be removed on Mac for it to be read properly, but removing it breaks on Windows in case there is nothing to read (an empty row). I can get around this by using #ifdef __APPLE__ for code that’s unnecessary on Windows, as can I use #ifndef __APPLE__ for code that’s needed for Windows but breaks or don’t work on Mac.

Week 5 – With Intent (group 4)

This week I’ve been working on the Furniture Manager and the Door class, I’m going to work on the Door Manager tomorrow.

The furniture have 3 light modes (2 are shown), mode 1 is see-through, mode 2 is semi-transparent (bottom one) and mode 3 is solid (left one).

I did encounter some trouble making this manager, since sf::Shape doesn’t move the vertices when you set rotation for the image, the Hull Manager took the position of the original vertices, which resulted in the shadows staying when I rotated the shape. Add that to the fact that y = 0 for the Light Engine is the bottom of the ”view”, meaning that the y-axis is inverted.

I solved this problem by using cos and sin, since y is inverted I had to invert the rotation as well.

vector.x = (hull->m_vertices[i].x * cosf(-rotation * (M_PI/180)) – hull->m_vertices[i].y * sinf(-rotation * (M_PI / 180)));
vector.y = (hull->m_vertices[i].x * sinf(-rotation * (M_PI/180)) + hull->m_vertices[i].y * cosf(-rotation * (M_PI / 180)));

This is the code for the Door class I worked on this morning, haven’t tried if it actually works, but I’ll explain the reasoning behind the functions.

Update() change the transparency of the use radius, because a static coloured circle seemed boring, I was reluctant to add another bool to check if it should increase or decrease the transparency.

Draw() draws the use radius and the door shape, easier than to call for the individual objects, they are connected anyway.

Open() tries to open/close the door, if it’s locked, it calls the Unlock function to try and unlock it, if it’s the wrong key, it will return false and won’t open the door. We decided that the use radius should have the same color as the key it’s tied to, so the player will be able to see if he has the key before trying to open the door (failing to open a door would make sounds), or which key he needs to find if the player doesn’t have it.

IsOpen() returns a bool weather it’s open or closed, I thought ahead here, if the guards can open doors, it could get ugly if he runs into an open door and close it, so with this he won’t close a door, only open it.

Unlock() is called by Open() if m_locked = true, if the keys color match the doors, it’s unlocked and return true to Open(), which then proceed as normal. I decided to have it a private function so that it only can be called by Open(), so you can’t bypass trying to open the door (and less code in the program later).

Escape grupp 4 – Light and Collision

My name is Robin Holmgren, and I work in group 4, aka. ”Boring warriors” on the concept ”Escape”.

We choose Escape because we felt it would be the most challenging to make, and most of us felt that we could actually want to play the game after it is done, the Light engine in particular drew our attention.

My primary job in the group so far has been implementing the light engine and some different managers, like Hull manager and Wall manager, as well as being QA for most of the programming artefacts in the project.
My secondary job is making the game cross-plattform, seeing as I use Mac for programming (so I see if the game compiles in both Mac OS and Windows).

We are using the library ”Let There Be Light” for the Light engine, with some modifications. We choose this library because it did what we wanted; limiting vision, soft spread on the edges, cast shadows from objects like walls as well as working well with the noir style we are aiming for the game to have. There were some difficulties implementing it though, it being outdated for the latest SFML as well as being painfully complicated to setup without much (up to date) documentation to go on.

 

 

 

 

 

 

 

 

I made the Light manager to link to an object, for example the pointer to the player (or the manager itself) or guards, making the light ”belong” to them, so to get the light associated with the particular object, you just have to send in the pointer or adress of the object, and it’ll get the light for you, if it has any.

Similarly, I made the Hull manager to link to shapes, so if you change a shape, you can get the hull by sending in the pointer to the shape (if it has a hull) as well as a load function to load a map (with all the hulls and shapes) directly to the manager.

This recent time I’ve been working on the Collision manager, I’ve made a collision check for the walls vs circles, and circles vs circles (untested but should be working), though it only returns a boolean if it collide or not, it only write out if it collide or not in the console window (bottom right). The walls vs circles go through all the vertices of the shapes in Wall manager, checking if any line penetrates the circle and returns true if it does. this isn’t optimal for very small circles (like those of a bullet might have) that has a high speed, as the circe might skip past the line between the frames (there is a solution for this, but this’ll do for the alpha).