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).