Better late than never to get started in the game jam! So for this first game of mine, I'll be working with the theme "Dreams". The basic premise of the game is you are Mr Sandman and your task is to put all the kids in the neighborhood to sleep with good dreams using your dust. You'll be racing against the Boogeyman who's giving the kids nightmares. Here are some of the other challenges you may be facing:

1) You cannot confront the Boogeyman. He will corrupt you and it's game over.

2) you have limited dust to which you need to regenerate (still wip on how to do this)

3) kids have a level of sleep. they need to be in a certain level (5 z's for example) in order for them to start dreaming. you will have to wait for them to be in a deep enough sleep before you can start giving them a dream.

4) some things may hinder them from  going to sleep like ("maybe a monster in the closet or under the bed). you'll need to  deal with those before they can start going to sleep more soundly.

5) kids already with nightmares must be transformed into having good dreams. this takes more dust and time to change. So you'd want to get there first before the boogeyman starts giving bad dreams to (haven't decided yet) either get a better score or better time.

That's it so far with what I have. Now on to coding! more to come soon!

Update 1:

So the day was spent mostly getting the setup (window, keyboard input, putting images on screen) working as I learn a new library. I guess this is a good time as any to also share some of my goals and intention for joining the jam.

• I wanted to take a chance in trying to work with just frameworks/libraries in order to build a game. As I wanted to take a break from using C#/Java (of which I use heavily for work), I wanted to get my hands dirty with C/C++ again. 
• Prior to this jam, I've been heavily inspired by the awesome stream (Handmade Hero) to make my own engine and make a game from that. Of course two weeks is not enough, but I can at least get there halfway by using the language I plan to learn and get comfy with it.
• If it were any other jam (which usually are 48 hours), I believe I wouldn't have really the opportunity to join one where it's safe for me to experiment too as well as learn and be able to talk to others in the same boat as I am, making their first game. 

So with that in mind, I have decided to use C/C++ as my choice of language with SDL2 as my main library to help me make this game. The entire day was spent really getting used to the library and seeing how I may be able to achieve things. So these are the first few steps I have been able to achieve for today:

• Create a Window that i can display things and also close correctly:

• Learn the different primitives I can draw with the library (Line Draw, Rectangle Draw, Point Draw)

• I started trying to get inputs from the keyboard and just print it on the console to see that i'm able to read them

• and finally get my first image from file on screen

Also, I've finished setting up my source control system (Git on Bitbucket) to setup myself for success and ensure that I won't lose any work that I have already done, or can undo something if I've screwed up my code badly.

Nothing really exciting done today but just the foundational drudge work that needs to happen for me to get to the more interesting parts. But with every small step I take, I'm enjoying it a lot!

Things I plan to accomplish tomorrow:

• Get an animated placeholder character on screen
• Get to move said animated character based on keyboard input (and hopefully controller too)
• setup basic collision between two objects
• make some placeholder artwork to place into the game
• get a rough small room/floor setup to get a feel of what the game will look like

Something to Consider down the road if there's still more time

• consider procedural generation for the neighborhood and home setups.
• if there is procedural generation, allow to keep the seed to regenerate the same setup so that players can share the same setup with friends and compete for best time/score or something like that.

Till the next update!

UPDATE 2:

Man, today was quite a lot of work. Had to cram as much as I can do because tomorrow is a Monday and that means I'll be mostly in the office doing work. But I feel pretty good with what I have accomplished today! Also, I'd really like to take this short opportunity to say how awesome the MFGJ community is! I feel energized to really get to work seeing much of the support people give and encouraging me on my journey to learning to build my own engine. Also Shout out to everyone in the discord server who are always there to help each other when someone needs it. it's a truly awesome environment to learn and share some stuff too at the same time!

Small side-note that may be beneficial to the rest that are doing their dev blogs. I ran into an issue during my first update where i had to reload some of my old code versions just to create screenshots and gifs. if you do find something interesting during the dev process and like the output you made, make the screenshot/gif then and there so that it makes the update much easier later. :) 

So here are the things I was able to accomplish today:

I started off with where I left off during Update 1, which is where I had an image on screen. What I wanted to do next was to set things up such that if I had a spritesheet (a set of images of a character/object that are compiled into one image), I'd be able to display only a portion of it because the others are not ready yet to be displayed, and how funny would it be if you see like a big chunk of sprites moving when they're not supposed to be on screen? hehe so the objective was to get this sample image below to be displayed each separately at each corner of the screen:

Another challenge is that as you can see in this image, there's a colored background. It's going to look ugly if all our characters were encased in some colored background and it would be visible in the game. Thankfully! SDL2 has already something to help with this (SDL_SetColorKey). Simply define the color you want to make transparent. Be aware though, if you use that same color in your artwork, it will be turned  transparent!! So I got that working and was successful in getting them on screen without backgrounds and they're displayed separately on each corner.

Yey! half of the problem done! Now i just need a series of some image to animate. a stick man! Since I have a few givens:

• I have the dimensions of the image and the sub-images in it
• I have the number of images in the spritesheet

I can create some array that has all the information of a series of images that i'd like to display one after the other to present the animation. So I did that and boom we have a stickman walking:

Well "walking"? I realized the speed at which OBS/Lice cap is recording, I couldn't get what it actually looks on my screen at 144FPS Any suggestions/tips on how to capture GIF/videos at high framerates would be appreciated! Since I only had a 4 frame walking stickman animation, and my monitor was running at a 144hz, you could imagine how many times it could run the animation in a second. So I now have playback issues. Next thing I thought to myself is, well at that time I didn't know if i was running at 60fps or more. Nothing really out of the box to show it right away. So I decided to implement a FPS counter for me to observe what was going on.

But there was one thing I needed to accomplish that first before I could display that on screen even if I've finished computing for it. I needed to learn how to display text on screen! so It wasn't much work on my end. SDL just needed to know where to get my TTF font and i could feed it some text and display it on screen just like an image:

Text to screen - CHECK!  So now all i have to do is compute for the frames per second. Good thing that SDL2 provides a lot of things that the OS could like a good timer. So SDL provides a time in milliseconds as soon as the window is created. all i have to do is capture that time and towards the end of the game loop record the time elapsed and the rest is some more math (ms to seconds, etc):

As I suspected, I was running at around 144FPS and the number of frames for my animation was too small. also, I should probably not be using the same pace for my animations and have a separate pacing for it. But for now I decided to park this problem. Since I was having issues with framerate related things, I realized that once I started doing movement, I will also run into timing issues where I would go super fast and others that run at lower FPS will run at a smoother/slower rate. So one thing that i have noticed with most game engines, they are able to cap the framerate. While i feel like i don't want to do that at all. I wanted to make sure that option is available for me to do when I've exhausted my other options. In order for me to do that, I had to time the game loop. how long is my loop taking at the moment? and how many milliseconds am i suppose to spend in a given frame if i had a fixed framerate. after doing some math and more time keeping, i was able to figure out if i had excess time, i could then use SDL to somewhat sleep/delay (SDL_Delay(uint32 milliseconds)) so that my code remains in sync with the target framerate. at the moment it's very easy to meet any target framerate well simply because my game loop is very small. It's barely rendering anything on the screen. 

So I'm able to now control the FPS (Yes the animation is still fast. LOL), so when I go into do more time-sensitive stuff i have an option of using frame-cap to help out. So now, I have code that allowed me to animate (somewhat) and some more features that would help me moving forward.I needed something very relevant to my game, and that's movement based on keyboard input. i'm halfway there since i have already gotten the key inputs.  but this time, i need to do two additional things:

• My current key read repeats the key input when the key is down. if the key is down, i only it want to read it once, no auto-repeat
• I need to update the position of my player representation on screen.

Thankfully again, SDL2 saved me from doing the first point on my own. it has an attribute you can check that if this a repeat key already. so if it is, you can ignore the key input. next was just for me to keep track of a few things for my Player. where it was, its velocity, and its speed at which it would move. given the key input just update the velocities and after key input handling update the Player's position, then render its texture on screen.

Success! but it because my window was pretty small, and increments were by 10, I decided that i had to make sure that the player would stay within the level. so I had to add some boundary checking so that i'd make sure that the player would not leave the screen!

No the player is free to move anywhere within the bounds of the screen. While i was happy with that, I realized hmmmmmm I want my levels to be bigger than just the size of my screen. So like other top down games, I aimed to achieve some scrolling. So that would by standard mean a "camera" would follow with the player at the center, however when reaching the end of the level, it will stop at its bounds and just allow the player to move freely to the end of the level. This is when I felt a deep sense of appreciation with what others have done in creating engines for all of us to use. Cameras nowadays are built-in to the engine and they give you a relatively easy way for you to make it follow the player around. Granted you still need some work to do to make that feel really good and polished, still at least you didn't have to make it on your own. I took this as a challenge, hunkered down, and started to work on it. so in SDL, what i needed to do is to define a rectangle that I could tell it to only display what fits in it to the window, wherever that was on top of the huge level, cut the rest. The math wasn't so bad in computing also where the player was on the rectangle and on the entire level. After a series of trials and errors, I have this:

This is where my development stopped today. All in all, a good days work. I did get a bit of collision detection work in by constricting the player within the bounds of the level, but nothing else. I wasn't able to get to doing some art work either today. But one thing I noticed today is that while we have these high-level milestones we want to achieve, we'd get some surprises that we need to make/problems we need to solve in order to get the whole milestone done. I feel all right some of my other goals were not met for the day.

So I'm not sure how much I can get done, but perhaps maybe in the office, i could do some sketches and some game design planning during my downtime/break just to make good use of my time. As far as the engine and game code is concerned, i'd like to get into some of these tomorrow:

•  player interactions, with objects in the room/house and with other entities like kids and the boogeyman. 
• start getting the player to give kids good dreams
• implement if and when the player and boogeyman collide, it's game over. 
• I'd like to consider already multi-floor homes, so interaction with stairs or even elevators (heck, kids can be in apartments/condos/even hotels right? hehe) and how to keep track of the events on each floor.

Something to ponder about:

Somewhere today, I was wondering whether I should make this top-down game realtime, or something like a when you move, everything else moves. kind of like rogue-like/rogue-lite games do. on the one hand, i feel it's much more exciting because you then feel the rush of having to beat boogeyman and well stay away from the boogeyman. But on the other, I can also see that, hey maybe i can give the player some finite amount of time to think and strategize. That way now it feels more like a puzzle. I'm still leaning towards the realtime due to the rush I feel when i imagine it. But, for anyone that's reading this, if you got something to share on what you think fits more, I'd like to know and weigh it in on my decision!

Till the next update! Keep up the awesome work everyone!

UPDATE 3:

I'm back for another update! Just as expected, yesterday had a lot of other things I had to finish and wasn't able to do much for the game. Today though, I was able to do a lot of stuff. Not everything I hoped to achieve from the last post. But I'm well setup to be able to start implementing those.

So here's the run down:

Today's work was mainly on collision detection. But, given where I left off last time, I didn't have very much to go with. There are a few things I had to consider before I started working on it. 

• The game is top-down and somewhere down the road, I wanted to put procedural generation of the rooms/homes/neighborhood. but for that to happen, I would need to build the levels by tiles to achieve most of what I want. This may mean that i can have information on tiles where I can say if i'm about to land on this one tile, i can check if that tile is allowed for walking or not. else i revert back to my previous position.
• If it weren't for tiles, collision detection could probably just be putting boxes around things in the game to which if i intersected with one of them, we can revert to the previous location again.
• I didn't have a proper level to test it on.

Bottom line, I had to build a suitable level where I can test all my collision. So let's build a level!

Building My First Level

For this game, I've decided that it would be best that my level will be using a tile map. So we need to make a few things for this to work:

• While this is somewhat optional (since you could technical just hardcode these things inside your code, but it's going to eat so much space in your files, that it's going to be hard for you to read your own code), but I opted to create a file format for my level. I've established in my code that I have a level of some width and height, and that i'm expecting a fixed size for the tiles (64x64 is what i used), and that would help me compute how many tiles I am expecting for the level size.
• Each of the tiles will have a numerical representation which simplifies my level file to something like this:

01s represent walkable tiles

04 are non-walkable tiles

• Together with this, I needed some placeholder tiles to represent these. I figured when I was drawing a bunch of squares, I ought to just make some extra ones in case I could use them for something while testing.

• I decided that when i'm parsing the Tileset, I would go Top-Bottom, Left-Right. With this, you could guess already that 01 which is a walkable tile is going to be brown, and 04 is red for not walkable. 

I now had all the components i need to make a level, So the next I needed to do is to render this on screen. Loading the tileset is simple since i've already been able to load pngs, so nothing new there. loading a text file however, we don't have that functionality yet. Thankfully, C++ has some libraries we can use (fstream). using the library we can call ifstream which conveniently allows to loop over our text file on chunk at a time, so for every ready i do, I takes one tile information at a time, left to right, top to bottom. Rendering just required that we loop as well through the entire list of tiles and place them into their respective positions.

We now have the level loaded in, and we can walk around the level, but it isn't as interesting yet since we're walking through walls. So our next task is to be able to stop our player from going through walls. 

Implementing Collision Detection:

I had several iterations for the collision detection code, I'll go through each of them and explain how I got to what I now have as a working collision detection for my player. 

As mentioned in the previous part, I've defined some properties for the tiles and in this case only 1, which is walkable. so 01 (brown) tiles are walkable and 04 (red) are not.  I needed to know though if i'm at a tile that's walkable or not. We can represent a tile as Tile(x,y) where x is its column number and y is its row number. so if my player is at (0,4), Tile(0,4) is a 04 Tile, which means you cannot move into that space, cancel the movement update and revert back to your previous position. Since my Tiles are represented in a 2 dimensional array, this was easy for me to check. But this inherently has a problem. How do I move smoothly from one tile to the other? noticed that we're using whole numbers (i.e. (0,0) (0,1)) to represent the tile location. If i make my movement like that as well I'll have a grid-based movement which would jump from one box to the other.

I can probably smoothen it out by some lerp (linear interpolation) function so that it moves nicely from one tile to the other. but it feels clunky. For a game that you may be racing against the boogeyman, you want crisp and responsive controls. So this won't do at all! Thankfully there is a way to still know where you are in the tile map but still have free movement. In order for us to do this we need to understand that SDL2's origin point is not at the center. it's at the upper left corner, meaning to say if I say an object is at position x, y what that  means is that the upper left tip is at position x,y

We know that each tile has an area of 64x64. All we need to figure out is whether the point is in a walkable tile or not. After some trial and error, I found a way to compute this to allow me to freely move around the level:

Dividing the target position i wanted to move into by the scale ( in our case its 64 because tile size is 64) allows us to get our whole number notation of what tile we fall into. so it's a matter of now just querying our array if it's walkable or not. Problem solved!

WELL! almost! turns out i forgot to account for the origin. so i also have to check the other corner depending on the direction. 

But I ran into another problem. what if i was in the middle of two tiles and i moved in half with an unwalkable tile and the other walkable? what do you know... It goes through! This was not acceptable! I tried debugging and couldn't get it to work. I needed some help. I consulted the web and some books. I learned of something called AABB collision detection (Axis aligned bounding box). and its method is pretty simple. Given two rectangles that are aligned in both x and y axes, we just check if any of their axis is not intersecting, if both are intersecting, then we have a hit! this wasn't all that hard to do so i went to work at it and got my desired result!

I have my free movement and i'm not going through any walls! finally! While my solution is working, it's worth noting that I had a trade-off here for anyone that may choose to do it the way I did. For this method, I had to iterate through the whole tileset and check whether i get a collision or not. 

int Collided = 0;
      for(int i = 0; i < TOTAL_TILES; ++i)
      {
        if(!Pieces[i].IsWalkable)
        {
          SDL_Rect A = {(int)Player.X, (int)Player.Y, Player.Width, Player.Height};
          SDL_Rect B = {Pieces[i].Location.x * TILE_SIZE, Pieces[i].Location.y * TILE_SIZE, TILE_SIZE, TILE_SIZE};
          if(TestCollision(&A, &B))
          {
            Collided = 1;
            break;
          }
        }
      }
int TestCollision(SDL_Rect *A, SDL_Rect *B)
{
  if((A->y + A->h) < B->y)
  {
    return 0;
  }
  if(A->y > (B->y + B->h))
  {
    return 0;
  }
  if((A->x + A->w) < B->x)
  {
    return 0;
  }
  if(A->x > (B->x + B->w))
  {
    return 0;
  }
  return 1;
}

I kind of made it efficient in the sense i only dealt with unwalkable tiles. but If i was able to make the first method work, I only would have to worry about 1,2, or 3 tiles only. But for my case for this game, and the two week period i only have to make this happen, I think it's an acceptable trade-off. Also another undesirable effect of this method is well you get snagged at corners, you'll have to fully slide of the corners. Again, a fine trade-off for this jam. But if i have more time, I can continue to improve this. We shall see. there's still more to do. Lastly, as the method suggests, I can't do any rotations. It's fine though, because i can just swap a diagonally moving sprite image. So in my case, an okay trade-off.

Now that i have some form of collision detection, I can move on to working on interactions with other things in the level.

Till the next update! Good night!

UPDATE 4

Today's update is going to be short. This time around, my aim was to allow the player to interact with other things (i.e. kids and boogeyman). In order for me to do this, I had to decide how i'd like to interact with them.

• I originally wanted directional movement to serve more than one function, and that's when i keep moving at a direction where i'm block by an object/person i can interact with, it will activate a "use" function.
• Thinking about it and planning how to achieve made me realize perhaps i can continue with that after the jam, but for this one i feel that a more simpler option would be to press and hold a button to allow player to interact/use

The way I wanted to go about it is that everything i can interact with would have besides a collision test, another box that would trigger a property that would allow for interaction. A trigger box if you will. Implementing this, I did it in two steps. First, let's ensure that my player is unable to pass through these objects.

This should be simple as the I can just re-use the same logic i've used for walls. Next part is to create a new bounding box around it and for debugging purposes, being able to render this.

So as long as the player is detected to be in the trigger box, he/she should be able to press and hold the space bar to use/interact. 

When in interact mode, I have decided to disable any other movement input. While i can already go into interact mode, the main bug/problem i'm having currently is that upon entering into the trigger box and i have not released the movement input, and then hold the action button, once i release, i seem to be teleporting after releasing the action button. My code continues to compute velocity and movement during the action phase. henced once i release the action and i'm still in motion, i'll update the position afterwards. i suspect that this is due to my statekeeping. I'm unable to solve it right now. So my next update will be about fixing this and implementing more on top of this such as kid's sleepiness and the dust mechanics.

Until the next update! See ya!

UPDATE 5:

Today's update is going to be a pretty short one as well. I realized I've been coding for a couple of days now. And the way I code is I pretty straightforward. I tend to write lots of usage code first and then start yanking stuff out as I see it being reused somewhere in code. I don't create functions thinking it will be re-used. It just makes my flow of thought easier and faster. But doing that makes my main pretty long. So I did have some code I could already turn into functions, so I spent most of my time reviewing it and refactoring where I can. Nothing really interesting there.

After that, I had some time left to get into looking into my previous bug, which was when i was holding the action button while moving, upon release i'd teleport because my velocity was still being computed. This had me thinking whether i really like the idea of locking the player's movement while in action mode. When I think about it, if I'm racing against time or the boogeyman, I can be impatient. It seems fitting that if I moved during action mode, it would cancel the action time that's happening currently and reset the timer if i'm still within bounds. This forces the player to be patient and careful when trying to dust the children. Too quick to move, then you have the penalty of redusting again.

So first things first, remove the lock on the player's movement. next, I need to create a timer specific for action use. and record it as long as i'm within the kid's bound, I'm pressing the action button, and i'm not moving at all. 

Decided to just print it out first in the console and check if i'm capturing time correctly and if it's resetting on move, and on action release. We simply had to re-use the SDL_GetTicks() from before when we computed for frame time but capture it specifically for when we are in action mode. so a few new variables and state-keeping was necessary for this. Next step is to add a new property on the kid, a Sleeping property. I've hardcoded for the moment that it would take 5 seconds to dust a kid to sleep with good dreams. so if my timer reaches 5 seconds uninterrupted, I update the Kid's property to sleeping and no longer let the player able to interact with the kid. also it would be nice for us to see all this in game, so I added some more code with some simple check that if i'm dusting i show the timer on screen, and when done, the kid will display some Z's for sleeping.

All in all, I'm feeling really happy with this update, because this is starting to feel like a game now! i have my first gameplay mechanic down!

Till the next update!