GameLabX is a compilation of my experiments in construct 2 over the summer of 2017. How it worked was simple: figure out if I can do something, and if so how?
A basic text based interface was the first thing I made, though its not much more than a barley functioning interface.  I moved on from that rather quickly.  
The next day I made a simple racing game. The goal here was to finish within an hour- which was easy enough. At this point I began to imagine connecting these funny little games together into one- an escape-style  point and click kind of thing, where the seemingly useless mini games each hold a secret. For example, in order to win the race, you'd have to wait at the finish line until the timer exceeded 100 seconds. 
My next project was a memory match game. The icons on the cards were art I did for a spring game jam at school. Anyhow the randomization gave me some issues, thus leading me to learn more about how arrays work in construct- which isn't all bad. Next, I disabled half of the randomizer to go off of the point and click idea. the goal for the memory match would be a perfect score. The trick to this lies in the fact that matching cards would always be in the same location- for example the cards in the upper left and lower right corners might always match, regardless of what symbol was on them. 
After that I made several icons at once for several ideas: One for a musical rhythm game, one for a fishing game, one for farming, and one for drawing- the last of which was my next project. This included a basic color pallet, multiple brush sizes and shapes, and HSL sliders. I tried to use an array to deal with the drawing canvas, along with several other methods- I really did. However, I couldn't get any of that to work, so I ended up with the worst possible method: Each pixel on the drawing canvas is its own object, storing its own information- a red box with HSL shifts applied. This is slow at times and horrible programming technique but it worked. Later, I added in the ability to save the canvas as a jpeg, which is a neat function. One of these days ill go back in and add a box and line tool, and reprogram the canvas, and several other fixes.
The chess game that I made ended up being far more difficult than I initially thought. Think of it like this: whats the hardest piece to program? The knight moves relatively to itself, so that's easy- and the king is the same.  The bishop and rook- and by extension, queen- were slightly harder, since they cannot bypass other pieces, but it was still simple enough. Thus, the pawn- the least powerful piece in the game- was the hardest. why? Because it cannot take pieces in front of it, can only take pieces diagonal to it, and cannot move diagonal otherwise, it can move two spaces if it has not moved yet, and finally when it hits the other side of the board that player may swap the pawn out for one of their lost pieces. In addition, later in the project the pawn became buggy for no apparent reason. Eventually fixed that however. The next tricky part was flipping the board around after every turn, but after the pawn the oddly confusing equations needed didn't seem so bad.  
If I ever go back to this one, I'd add a check and checkmate checker- which promises to be a slight headache. 
As proud of my chess as I was, my crowning achievement on this project was something rather simple, yet equally amazing. Construct is a 2D only engine, but I made the crates and room appear to be 3D.
   This started when I went to tie together the mini games into one- which was supposed to be simple. and i did a simple version sometime before the chess game. However, after that I got a funny little idea- one that would frustrate me for weeks. 
The first step was forcing construct to draw lines. in this version, it does this by stretching a single 4x4 pixel object between two 'point' objects. from there, it was just a matter of assigning points to crate corners and making thicker lines to fill it in. those crate faces move much like a parallax would based on a lerp equation of the player and it's starting position. All of this involved a lot of instance variables and a total of around 25 objects per crate moving about each time the camera moves. I could cut that down by taking out the 'point' objects, and the code needs to be cleaned up- but it works, and looks pretty good. Unfortunately, more than 8 or so crates will massively slow down the program, but at the same time there's a lot that could be done to fix that.  I have a new version somewhere with corrected floor and backdrop movement, but deconstructing the side walls so they shift too is something I don't have time to do properly right now. 
After all of that, I dropped the point and click idea due to a lack of time.
My final summer test was in the farm game- which was never finished. The clock and calendar is in there, as is a moving character- a slime. (i was playing slime rancher at the time)
Anyhow the biggest thing here was the Pokemon-like tile based movement. this is achieved via a grid, calculated by flooring (eliminating the decimal) the result of the players position divided by the grid size, then multiplying the floored result by the grid size again. if that number is the same as the players position, then the player is aligned with the grid and can stop or change directions. The issue? the character wasn't lining up with the grid when i used construct's built in movement! Why? Well, construct doesn't actually move things. it teleport them a bit each frame- and thanks to the acceleration and such built in, that never aligned with the grid. Therefore, i had to manually do movement by moving the player a 16th of a tile every 16th of a second, and it worked! Unfortunately, school started soon after, so the farming piece itself never happened.
Back to Top