The first level I designed for OP GO. Looking back, maybe I should’ve built a level editor…
I’m done with the game’s “engine”, so now I have to focus on polishing the game’s looks and adding content. As for content, I finished designing the first level! You can see it in the picture. Since I don’t have that much spare time I haven’t made a level editor, so that’s why I’m using just plain pen and paper. There will be five levels total, including a tutorial that will showcase the broad collection of enemies and tactics that can be used to beat the game.
Typing a post on a smartphone is NP-Hard, man.
IT’S SO FABS
Was a FABS day today, making some solid progress on the game AI. Expect a blog post about it soon, mwuahahaha. Or follow my progress on the repo: https://github.com/bobismijnnaam/sgoat.
Next on the list: raycasting! Much to my suprise, it wasn’t that difficult. So I won’t be ranting today. I’m so glad it all worked out nicely, I expected this to be a very difficult task. Not so difficult that I couldn’t finish it, but I was kind of worried about the time it would take me to finish it. To be honest, testing the system I coded for raycasting was harder than actually coding the system itself, haha. At some point I had to hop back and forth between on-screen- and world-coordinates and messed up a few lines. That, combined with the fact that sometimes my brain switches around variable names (for example l1x turns into x1) gave some unexpected results. After an hour of explaining how the code works to my rubber duck and making a special function for converting on-screen- and world-coordinates the prototype worked.
“A picture says more than a thousand words.” They say. Well, to lift the word count of this blog a bit, here are some “pictures”.
The red line represents the ray. The blue cross indicates the point of collision.
It also works with the borders of the level!
And it indicates where the collision occurred first. This is important, because there occurred two collisions here: one with the border and one with a wall.
It’s nice that implementing raycasting was really easy, because I can now finally move on to the interesting part of my project: the AI! The AI needs raycasting for their field of view. Later on I will (hopefully) also be using the raycasting system to display the field of view of the guards, and also maybe the field of view of the player. But I’ll only be able to implement that if I have enough time. So we’ll see.
Damn, that was a lot of work. On schedule today was sliding collision. This was on schedule because, ofcourse, it is weird if you can walk through walls and can’t slide past walls. I have always struggled with collision, though I’m not sure why. I have implemented a lot of collision detection systems in my prototypes in the past, but every single time I have had major problems with it. For some reason I didn’t have a bad feeling about the task at hand when I started coding this morning. I was almost looking forward to it. Nostalgia I guess. Naïve nostalgia.
I ended up coding for almost the whole day, working for a long time on a system that in the end is incredibly simple. I’ve tried about 5 different systems for (rectangular! -.-) sliding collision detection. And altough I got the collision detection working (with more work than expected), getting sliding collision working seemed like an impossible task. At some point I lost hope, because I had already tried 5 collision systems, all of them not working properly (altough the code looked perfectly fine. It’s depressing). I decided to take a break, go outside for a moment and buy some drinks for tonight. When I came back I had a striking epiphany. A true “EUREKA!” moment.
So I got back to work, and in mere minutes everything was working as intended. It turned out I was hopping back and forth between floating point numbers (numbers like 4.89) and integers (round, natural numbers like 2, 6 and 800) in an important function. That function in turn somehow messed everything up. All five of the systems couldn’t handle this little error. Which is ofcourse, expectable. Lesson learned.
I’m exrtremely happy but also extremely irritated at the moment. Collision detection gets to me every single time. I guess you could say collision detection… Is my kryptonite.
It’s halfway february and just like last month the end of the month is steadily coming closer. And altough I haven’t written any blog entries, I have been writing code. I’m working my way to finishing the core of the game so I can start adding some levels and polish the game with (hopefully) better graphics and ofcourse a gripping ambient soundtrack! Here’s what I’ve got so far:
OPGO in action. Rectangles are walls, the circle is the player.
This contains the very core mechanics that I will need for my game: movement of the player, a system that manages the walls (adding, deleting, rendering, etc.), and collision detection. I’m still far from done though. Things like sliding collision, AI, sounds, and a level selection system still need to be implemented. But the core is there. I’m optimistic about when I’ll finish the game because next week I have a break from school, which means I’ll (probably) have a lot of time to code 🙂
Lastly, you might see that on the top of the screenshot it says “Scapegoat”. Well, I had this really cool idea for a game where you control a goat which wants to escape but has to sneak past farmers guarding and patrolling the area. I had to go for a more minimalistic approach because I won’t have a lot of time for graphics this month. That’s why I changed the name to Operation Get Out so I won’t have to pay much attention to graphics. Cheap and lazy, I know haha. It’s an assignment for my computer science class so that’s why I’m less motivated I guess.
Until next time 😉
January is gone! A new month, a new game. This month I will be making an escape game. My idea is very simple: you are in a room, and you need to get out. However, the room is being patrolled by guards. So you’ll have to sneak your way out. Not a problem, just be sure you are not seen by the guards! It will probably be a simple game, or at least I hope it will be. I don’t have a lot of time this month so it will probably be very minimalistic. Simple graphics, simple sounds and music (if even implemented at all), only a few levels, but clear and robust gameplay. That’s what I’m aiming for. If anyone has any ideas about possible names for the game or maybe a theme, be sure to tell me! If I have enough time to implement nice looks I surely will.
The reason I have chosen for this type of game is because I have to make a program that contains an AI for my computer science class. And since this type of game can work with simple implementations of AI (something needs to control and instruct the guards right?), and because I’ve always been wanting to make a sneaking game, I’m making a sneaking game.
However, there might be a chance that everything goes according to plan. I might finish the core gameplay early and might not encounter any (hard) problems. In case that happens, I’m thinking about implementing a player FOV (field of view). See, if you can just see where all the guards are all the time the game is pretty easy. But what if you can only see the guards if they are in your FOV? That makes it a lot harder and a lot more sneakier. I will probably implement it as a hard mode option. That is, if I have enough time. This wasn’t originally my idea though. Vincent Riemer, A.K.A. BizCaus on Reddit, thought of it first (as far as I know). In my opinion he did a pretty good job at implementing the mechanic. You can see it for yourself here: http://www.vincentriemer.com/blog/posts/ps-video-update-4 .
So, that’s my idea for my february game for One Game a Month. Just like last month I will blog about the progress on my (this) blog. Fingers crossed!