Reading posts and looking at screenshots is all well and good... but you can't get a good idea of what a game is like until you actually sit down and play it. Swamplands isn't really in a "playable" state as of yet, but this little demo will at least give you a look at the engine and at some of the mechanics.
Download it here
Press 'f1' in-game for help.
Wednesday, April 25, 2012
Wednesday, April 18, 2012
Impact Effects Screenshots
The playable tech demo is on the way. For now, take a look at these screenshots of the previously-mentioned bullet impact effects. Lighting was turned off so they're more visible
Both of these were basically just me going nuts with unlimited ammo. It's unlikely that you'll see this much dust in-game since you have very little ammo.
This shot is perhaps a little more realistic.
And just for fun, here's a shot of the same room with lighting turned on. As you can see, there are some added textures since the last screenshots. And if you look closely, you'll notice that the light bloom now actually casts light rather than just colored halos (a little hard to see).
Tuesday, April 17, 2012
Impact Effects!
In contrast to AI, coding weapon/impact effects is one of the more rewarding parts of making a game, in my opinion. It's just awesome to try and perfect all the little details to make shooting as fun as possible. Pit was the first game where I used any sort of hanging dust effects, and I was very happy with how they turned out. So I've added a similar system in Swamplands. And it looks AWESOME. Firing a full clip into a wall fills the area with grey dust that takes awhile to dissipate. And I just love how that feels. I'll also be adding some gunpowder smoke, muzzle flash/sparks, and possibly shell casings.
Sadly, due to the tile-based handling of walls, there will be no destructible environments. But all the time I'd spend on that can now be put towards other weapon-specific visuals and effects. Although this is nowhere near a game about shooting things, it's still a game designed by me... and as a result, I want guns to feel as good as possible.
Nope, I don't have any screenshots of this entertaining little effect. But I will soon. And, even better, I plan on soon putting up a playable tech/atmosphere demo for people to play around with. Stay tuned!
Friday, April 13, 2012
Stealth
So yes... the "visibility gem" system has been replaced. Originally, your "hiddeness" effected the probability of an enemy NPC dice roll turning up as 1, and if the dice turned up as 1 then he would see you and give chase. Sounds good on paper, but in reality this system ended up being far too unforgiving to be fun. In fact, I don't think I've ever played a game with a "random roll" stealth system that was fun. Morrowind is a perfect example: there's no way to recover from being seen, and at anything other than higher levels its almost impossible NOT to be seen. Because it's all based on dice rolls. As long as you're within an enemy's view range, it's completely random whether or not you are seen. So in other words, stealth is useless unless you have an ungodly high level, because there's no way to use skill or strategy to ensure that you won't be seen. To a certain extent, the original Swamplands stealth system was a little like this. You it was too unforgiving, which is odd to say for a game that is SUPPOSED to be unforgiving. But still...
Now, we have a system more akin to the one in Far Cry 1. You have a bar at the top of the screen that shows how close enemies are to spotting you. Your "hiddeness" determines how fast the bar fills. Stealth is not easy, but it's possible. And it feels a lot fairer, since you get a sense of whether or not you're hiding well enough without immediately failing. And, there's no randomness.
Now, we have a system more akin to the one in Far Cry 1. You have a bar at the top of the screen that shows how close enemies are to spotting you. Your "hiddeness" determines how fast the bar fills. Stealth is not easy, but it's possible. And it feels a lot fairer, since you get a sense of whether or not you're hiding well enough without immediately failing. And, there's no randomness.
Monday, April 9, 2012
A quick update
It's been a little while since I've posted anything, since I'm in the process of getting engaged, and that's taken a lot of my free time (as well as some time that really shouldn't be free). Unfortunately, that means that I also haven't been putting as much time into Swamplands as I'd like. I'm still working on the AI right now. The detection system and hunting routines aren't coded, but the test NPC will currently walk around randomly and run from you if you get too close. It will also avoid walls while doing both these things, using some simple motion planning. I've also done a bit of visual work, adding in some rot and "missing chunks" to vary up the floor tiles. I've also cleaned up the control scheme and added matches for making fires. Evan has done some work on the story as well. At this point, we're going to do something very odd narration-wise: Every 30 or so days (this number will probably change later on), your character loses their memory. Which means that you'll wake up somewhere different with new gear, surrounded by evidence of events that you don't remember happening. It's odd, to be sure, but then again that's kinda the deal with this game... there are a lot of very odd things. Benji seems to have slowed down on the art, but that's a little understandable considering the manic pace that we were doing things at the beginning.
So hopefully once my beloved has something sparkly on her finger and wedding plans are finalized (or at least MORE finalized), I'll be able to do more work. And once I've built a new computer (aka, one that can capture footage at a decent framerate), I'll probably have footage to show. For now, rest assured that the game is still moving along.
So hopefully once my beloved has something sparkly on her finger and wedding plans are finalized (or at least MORE finalized), I'll be able to do more work. And once I've built a new computer (aka, one that can capture footage at a decent framerate), I'll probably have footage to show. For now, rest assured that the game is still moving along.
Wednesday, March 28, 2012
Some more screenshots
As promised, here's a few more screenshots of the game.
Here's the same room, without any lighting effects. Not nearly as interesting, as you can see. Ultimately, the game will have a lot more tiles for broken walls, tiles, etc. It should also be noted that anything in this shot that should be able to be picked up, can be picked up and often used.
In this shot, the overall lighting level has been increased.
Another shot at low light levels, with another fire. Inside areas will likely be lit by some sporadic lighting from old industrial lights or furnaces. The Swamplands functions on methane gas (of course), and some areas are still generating power.
The HUD, which is brought up with the 'q' key. Everything is manipulated in real time, as in System Shock 2, so it's important to find a safe location before messing with your inventory. As previously mentioned, many things can be picked up and used. The bars at the top represent (from top to bottom) your health, hunger, thirst, fatigue, and "infection" (which functions very similarly to Fallout 3's radiation). Things like a logbook and map are still being discussed for inclusion.
We're using a fairly basic but effective per-pixel lighting system, and some colored halo effects to simulate colored lighting (which the lighting system doesn't support). Here, the room is being illuminated by a campfire and the player's flashlight. You can also see our "poor man's lightbloom" as applied to glowing mushrooms down at the bottom of the screen. The blue bar at the top is a placeholder for a "visibility gem" system that is probably going to be replaced with a more sophisticated "enemy awareness" system, like the one used in Far Cry 1. The two boxes at the bottom of the screen represent what your holding in your two hands (in this case, they are empty).
Here's the same room, without any lighting effects. Not nearly as interesting, as you can see. Ultimately, the game will have a lot more tiles for broken walls, tiles, etc. It should also be noted that anything in this shot that should be able to be picked up, can be picked up and often used.
In this shot, the overall lighting level has been increased.
Another shot at low light levels, with another fire. Inside areas will likely be lit by some sporadic lighting from old industrial lights or furnaces. The Swamplands functions on methane gas (of course), and some areas are still generating power.
The HUD, which is brought up with the 'q' key. Everything is manipulated in real time, as in System Shock 2, so it's important to find a safe location before messing with your inventory. As previously mentioned, many things can be picked up and used. The bars at the top represent (from top to bottom) your health, hunger, thirst, fatigue, and "infection" (which functions very similarly to Fallout 3's radiation). Things like a logbook and map are still being discussed for inclusion.
Monday, March 26, 2012
AI fun times
I hate coding AI. I really do. It's not necessarily because it's an unpleasant task... it's because I find it annoyingly difficult. See, it's easy to understand what you want the computer to do, but it's ridiculously hard to tell it to do that. For instance, it's all well and good to say "this guy should go around walls." But how exactly do you do that, code-wise? The answer, it turns out, is quite complicated. Far more complicated than simply adding a "go around walls" line of code somewhere in the movement routine.
Gamemaker has a very VERY easy function for simple movement planning, which is what I used in previous Gamemaker projects (although if memory serves, enemies in Pit didn't do anything to try and find their way around walls, since it was rarely necessary). It basically will change an NPC's movement direction under-the-hood to move parallel to a solid object if it contacts it. This works pretty well if you're only dealing with single blocks or detached "lines" of wall objects--the NPC sometimes takes the long way around, but it doesn't get stuck. However, when intersecting walls come into play, this routine can regularly cause NPCs to start infinitely looping in corners. Not a huge problem when you're making a mob shooter like Nurf Nerfus, but a significantly larger problem when you need your enemies to be able to actively hunt down the player and pursue them through inside areas.
So this is why motion planning exists. Motion planning functions let an NPC plan out the shortest, most logical path to a given point by looking at the entire layout of the area at once rather than simply moving until they hit something. The motion planning in Gamemaker is actually pretty good, and allows for some pretty convincing "maze solvers." The problem with them is that calculating a path takes a fair amount of time, in computing terms. So it's not practical to just have the AI calculate a path every step. When my NPCs are just walking around, it's works perfectly well to set a point once and let them find their way to it. You wouldn't notice any slowdown. But when the point is constantly changing--such as when an NPC is chasing the player, or going to the source of a noise-- the game can easily slow to a crawl. In reality, most situations like this can be averted with some smart "cutting corners" (for instance, if the NPC can see you, he doesn't really need to find his way around walls, and most of the situations where an enemy needs to actively chase the player involve direct line of sight). But then, the game needs to know when to use motion planning and when not to use it. It's not exactly a Carmack-worthy problem, but it adds more code and more complexity.
Any veteran programmers reading this are probably shaking their heads and going "what... he can't handle some simple motion planning? How does this clown ever expect to succeed as an indie game designer! I can do motion planning in my sleep. Now excuse me while I go back to making a mod that improves the visuals on yet another AAA commercial title." Well I don't know if I mentioned it previously or not, but I am a thoroughly right-brained programmer. In other words, anything that requires something resembling mathematical competence will invariably confuse me. This is why I love the Gamemaker toolset. Because then I don't have to worry about those niggling little annoyances like collision detection, sprite rotation, etc. At worst, I may have to use a function or two. At best, I can merely set a variable and the engine takes care of it for me. However, even within the admittedly noobish environment of Gamemaker, there are still things that I would much prefer not having to do. Things that require me to exert effort beyond simply typing in the correct sequence of functions and variable assignments. Things that will inevitably result in woeful spaghetti code and arcane solutions. Which is always...ALWAYS...the case with my AI.
So, this is a rather rambling post... basically, I'm working on the AI right now. And it's predictably difficult. It will ultimately involve some cutting of corners and implementation of different techniques. But thus far, it's turning out pretty good. Enemies won't be able to see you if you're hiding in shadows or are outside their FOV, they will actively hunt for food and run from danger, and they'll do a little to try and find you if they know you're around. Next post, I'll have some screenshots of the lighting and simple little graphical effects that the game has implemented thus far.
-jefequeso
Gamemaker has a very VERY easy function for simple movement planning, which is what I used in previous Gamemaker projects (although if memory serves, enemies in Pit didn't do anything to try and find their way around walls, since it was rarely necessary). It basically will change an NPC's movement direction under-the-hood to move parallel to a solid object if it contacts it. This works pretty well if you're only dealing with single blocks or detached "lines" of wall objects--the NPC sometimes takes the long way around, but it doesn't get stuck. However, when intersecting walls come into play, this routine can regularly cause NPCs to start infinitely looping in corners. Not a huge problem when you're making a mob shooter like Nurf Nerfus, but a significantly larger problem when you need your enemies to be able to actively hunt down the player and pursue them through inside areas.
So this is why motion planning exists. Motion planning functions let an NPC plan out the shortest, most logical path to a given point by looking at the entire layout of the area at once rather than simply moving until they hit something. The motion planning in Gamemaker is actually pretty good, and allows for some pretty convincing "maze solvers." The problem with them is that calculating a path takes a fair amount of time, in computing terms. So it's not practical to just have the AI calculate a path every step. When my NPCs are just walking around, it's works perfectly well to set a point once and let them find their way to it. You wouldn't notice any slowdown. But when the point is constantly changing--such as when an NPC is chasing the player, or going to the source of a noise-- the game can easily slow to a crawl. In reality, most situations like this can be averted with some smart "cutting corners" (for instance, if the NPC can see you, he doesn't really need to find his way around walls, and most of the situations where an enemy needs to actively chase the player involve direct line of sight). But then, the game needs to know when to use motion planning and when not to use it. It's not exactly a Carmack-worthy problem, but it adds more code and more complexity.
Any veteran programmers reading this are probably shaking their heads and going "what... he can't handle some simple motion planning? How does this clown ever expect to succeed as an indie game designer! I can do motion planning in my sleep. Now excuse me while I go back to making a mod that improves the visuals on yet another AAA commercial title." Well I don't know if I mentioned it previously or not, but I am a thoroughly right-brained programmer. In other words, anything that requires something resembling mathematical competence will invariably confuse me. This is why I love the Gamemaker toolset. Because then I don't have to worry about those niggling little annoyances like collision detection, sprite rotation, etc. At worst, I may have to use a function or two. At best, I can merely set a variable and the engine takes care of it for me. However, even within the admittedly noobish environment of Gamemaker, there are still things that I would much prefer not having to do. Things that require me to exert effort beyond simply typing in the correct sequence of functions and variable assignments. Things that will inevitably result in woeful spaghetti code and arcane solutions. Which is always...ALWAYS...the case with my AI.
So, this is a rather rambling post... basically, I'm working on the AI right now. And it's predictably difficult. It will ultimately involve some cutting of corners and implementation of different techniques. But thus far, it's turning out pretty good. Enemies won't be able to see you if you're hiding in shadows or are outside their FOV, they will actively hunt for food and run from danger, and they'll do a little to try and find you if they know you're around. Next post, I'll have some screenshots of the lighting and simple little graphical effects that the game has implemented thus far.
-jefequeso
Subscribe to:
Posts (Atom)