It has been quite a while since my last post. I've gotten a lot of work done since then, so I've decided to split my post into two parts. In this first part, I'll discuss the changes to the monster's AI, and in the second part I'll talk about graphics some more.
I've made several major changes to the monster's AI to make it more dangerous and unpredictable. The first change is the ability to 'blink'. When the monster is trapped or otherwise unable to reach the player, it can now teleport to designer-specified points called 'blink nodes', favoring nodes that are close to the player, but not to close to be unfair. This gives the monster more options, and makes it more challenging to trap.
Another major change that I've made is making the monster more resistant to the flashlight. The player's flashlight no longer marks them as 'safe' when in the dark, and the monster will now attack them. If the player sees the monster and reacts quickly, it can still be warded off with the flashlight. However, if it gets close enough then the flashlight becomes ineffective and the player will be forced to fumble with a flare to escape. This rewards careful play, and prevents the player from being 100% safe for most of the game.
Lastly, I've made the monster change speed based on its state. This not only makes it seem more dangerous, it also makes it very difficult to chase and kill, as we found some testers liked to do. Combine that with regenerating health similar to what the player has, and the monster is suddenly much more dangerous than it used to be.
Now, the monster is much more dangerous. On the visual side though, it's still a bit of a cute fluff cloud. In my next post, I'll discuss the steps that are being taken to fix that.
3/6/16
Capstone Update 15: Monster Beauty Pageant
During the past couple of weeks, I've been working on the monster as always. The AI work has been slowing down since I've had to look up how to alter some of the pathing. In the meantime, I've also started working on the particle effects that make up the monster. I think I've made some pretty good progress so far.
Next, I decided to try and fix a simple problem: Because the monster is entirely black, it's nearly impossible to see against a dark backdrop. I needed to find a way to make the monster visible while still being creepy. One of the original concepts that spawned this game was the common fear of the dark. That concept led me to try and make the monster create glowing 'eyes' within its mass, both to add to the creepiness factor and to make it more visible to the player.
My first change was to "give the monster legs", as I like to call it. As you can see in the screenshot above, the monster's main mass actually falls now, and sits on the ground. The result is that the monster seems to actually drag its body across the floor, rather than simply float like a cloud. It also serves to almost make it feel more like a creature, by giving it what looks like a discernible head.
After that, I started working on making its state more visually obvious. I started off by making the monster's size depend on a variable that I could alter. When the monster charges the player, it becomes thin and agile. When it runs away, it puffs up to look more intimidating. This change alone makes it feel more interesting and alive.
With the size changing in place, I began working on giving it some more interesting movement as well. When attacking, the monster now undulates along two sin waves. Each axis (horizontal and vertical) has a slightly offset multiplier and length. The result is desynchronized movements that make it look both dangerous and a little bizarre.
Shaping the Monster
When I asked the artists on the team for some guidance on how the monster should look, they brought up images of schools of fish, and various swarms of animals. Following that idea, I added an additional emitter that created tiny particles to erratically orbit the monster's origin point. The original cloud of smoke now had what looked like a swarm of insects buzzing around it.Next, I decided to try and fix a simple problem: Because the monster is entirely black, it's nearly impossible to see against a dark backdrop. I needed to find a way to make the monster visible while still being creepy. One of the original concepts that spawned this game was the common fear of the dark. That concept led me to try and make the monster create glowing 'eyes' within its mass, both to add to the creepiness factor and to make it more visible to the player.
 |
| Even in a bright preview window, it still looks a tad unsettling |
Changing Form
I got some useful feedback in class. My teacher showed me some videos of snakes, barracudas, and other 'long' predatory animals to help make the monster seem more dynamic and alive. I've taken her feedback into consideration, and made a few interesting changes. |
| The monster in its natural habitat |
My first change was to "give the monster legs", as I like to call it. As you can see in the screenshot above, the monster's main mass actually falls now, and sits on the ground. The result is that the monster seems to actually drag its body across the floor, rather than simply float like a cloud. It also serves to almost make it feel more like a creature, by giving it what looks like a discernible head.
 |
| When fleeing a light, the monster puffs itself up |
After that, I started working on making its state more visually obvious. I started off by making the monster's size depend on a variable that I could alter. When the monster charges the player, it becomes thin and agile. When it runs away, it puffs up to look more intimidating. This change alone makes it feel more interesting and alive.
 |
| The monster going in for the kill. Believe me--it's creepier when it moves. |
With the size changing in place, I began working on giving it some more interesting movement as well. When attacking, the monster now undulates along two sin waves. Each axis (horizontal and vertical) has a slightly offset multiplier and length. The result is desynchronized movements that make it look both dangerous and a little bizarre.
 |
| As a little teaser, here's some updated damage feedback. |
3/5/16
Console Programming 3-Week Project 2 - DFGame Expansion
Hello again! After a few weeks of toil, I've finished my second 3-week project for Console Programming. I opted to make this project about building up DFGame to a more usable level, and I'm happy to say that the project was quite successful!
To make this game happen, as well as improving Halberd a bit, I decided to implement the following features during weeks 1 and 2:
The project script is a great example of such a feature. It's designed to set up a new DFGame-based project as quickly as possible, while also being easy to modify and extend.
DFGame now creates a folder in /usr/share (on *nix-based systems, of course), and adds folders which act like templates to it. This means that users can add their own, as well. It also installs the script to /usr/bin, so you can create a project just by calling "dfgame new project-name folder-name". folder-name is optional too, if you omit it, it'll set up the default project. The script moves over the contents of the template folder, and then checks for a special script within the folder. If the script is found, it's executed as well, to allow for extra customization. The current template scripts set up a config.mk file, for instance. Finally, the script initializes Git and builds the project, ensuring that everything is in working order.
I also took the opportunity to make something new: a log viewer. I've wanted this for a while, so that I could debug issues without having to look at several windows at once. Now, it's in!
It's not an enormous addition, but it feels like another good step towards making my editors more professional.
This new system lives up to my expectations quite nicely! It revolves around mapping inputs of any kind to either (or both) of two input types, actions and axes. An action is any kind of digital input. It generally used to represent singular in-game actions, such as opening a menu or attacking an enemy. Axes, on the other hand, are 2D analog inputs. An axis can be thought of as a 2D vector, like a joystick input. Axes should be used to describe inherently directional actions, such as movement or aiming. Any keyboard, controller, or mouse input should be translatable to any actions and/or axes.
So, we have a decent base here. But what makes this so powerful is the way it's implemented. DFGame's input code is broken up over 2 of its modules: the base game module, which is used everywhere, and the game frontend module which is only used in released copies of a game, not the editor. This means that the editor and game are responsible for handling their own inputs, and passing the result to the base input system.
Not only does this separation make inputs inherently rebindable, since the actual keys are disconnected from the in-game actions, but it also allows the editor to simulate inputs and the game to take inputs from custom sources and input devices. Ultimately, this makes input code way easier to deal with, and it also makes adding or changing controls during development a cinch.
In order to speed up rendering and save on memory, I've split sprites into two parts, the spriteset and the sprite [player]. This is a similar approach to the one I took with audio: One struct controls data access, while others act as interfaces to play back this data. The spriteset holds the texture atlas and animations, while the sprites hold information about the currently playing animation.
The game isn't currently packaged and available for download, although I'm considering that right now. The game's code is quite messy, since the point was simply to use it as a quick test of my library's capabilities, rather than to start a 'serious' development project. It's more of a game jam-style game.
Regardless, I took the time to make a video of the gameplay. Since there aren't any sound effects anyway, and the music was borrowed from one of my old game jam entries, I decided not to record the audio. Feel free to add whatever background music you like while watching.
Most of that will have to wait until after I graduate though. This is a very tough semester for me.
Project Overview
My ultimate goal for DFGame is to be able to build the base of a game from scratch, editor and all, in a single week. I decided that a nice way to cap this project off (and test the viability of DFGame in the process) would be to try and make a super-basic game/tech demo without an editor in a single week. I'm pleased to say that the result way a success!To make this game happen, as well as improving Halberd a bit, I decided to implement the following features during weeks 1 and 2:
- A script for generating new DFGame-based projects
- Some UI widgets for editor development
- Input handling code
- Sprite loading/drawing code
- Some initial project management code
Project Script
One of the main differences between DFEngine and DFGame is one of approach. DFEngine's goal was to make a fully-featured game engine, but with DFGame I add features that will benefit me directly in game projects. As a result, I can get things done faster because my focus is specifically on making games.The project script is a great example of such a feature. It's designed to set up a new DFGame-based project as quickly as possible, while also being easy to modify and extend.
DFGame now creates a folder in /usr/share (on *nix-based systems, of course), and adds folders which act like templates to it. This means that users can add their own, as well. It also installs the script to /usr/bin, so you can create a project just by calling "dfgame new project-name folder-name". folder-name is optional too, if you omit it, it'll set up the default project. The script moves over the contents of the template folder, and then checks for a special script within the folder. If the script is found, it's executed as well, to allow for extra customization. The current template scripts set up a config.mk file, for instance. Finally, the script initializes Git and builds the project, ensuring that everything is in working order.
UI Widgets
I've been meaning to move several parts of Halberd's UI over to dfgame for some time now. Most of the more 'generic' UI elements, such as the asset pan and missing files window are mostly self-contained, so moving them over was quite simple.I also took the opportunity to make something new: a log viewer. I've wanted this for a while, so that I could debug issues without having to look at several windows at once. Now, it's in!
Input
My input code has always been fairly simple, but this time I decided to try and make a more powerful system.This new system lives up to my expectations quite nicely! It revolves around mapping inputs of any kind to either (or both) of two input types, actions and axes. An action is any kind of digital input. It generally used to represent singular in-game actions, such as opening a menu or attacking an enemy. Axes, on the other hand, are 2D analog inputs. An axis can be thought of as a 2D vector, like a joystick input. Axes should be used to describe inherently directional actions, such as movement or aiming. Any keyboard, controller, or mouse input should be translatable to any actions and/or axes.
So, we have a decent base here. But what makes this so powerful is the way it's implemented. DFGame's input code is broken up over 2 of its modules: the base game module, which is used everywhere, and the game frontend module which is only used in released copies of a game, not the editor. This means that the editor and game are responsible for handling their own inputs, and passing the result to the base input system.
Not only does this separation make inputs inherently rebindable, since the actual keys are disconnected from the in-game actions, but it also allows the editor to simulate inputs and the game to take inputs from custom sources and input devices. Ultimately, this makes input code way easier to deal with, and it also makes adding or changing controls during development a cinch.
Sprites
DFGame's new sprite system is mostly identical to Halberd's, with one main exception.In addition to the sprite/animation system that I described in this post, DFGame's implementation has an additional layer of abstraction.In order to speed up rendering and save on memory, I've split sprites into two parts, the spriteset and the sprite [player]. This is a similar approach to the one I took with audio: One struct controls data access, while others act as interfaces to play back this data. The spriteset holds the texture atlas and animations, while the sprites hold information about the currently playing animation.
Project Management
One of the most important features that you can put into an engine is the ability to create new projects. Even if you plan to only use an editor once, being able to go back and create brand-new content with it can be quite useful. In addition, it gives the editor potential for a decent public release. For that reason, I've moved Halberd's project management code into DFGame. It could still use a bit of cleaning, but for now it'll do the trick.The Game
All of this technical talk is good, but you might've noticed that I mentioned a game earlier. In addition to the DFGame improvements, I also created a small game as a test. I planned to spend a week on it, but instead I only ended up with 3 1/2 days. Despite that, I still managed to make a small, well-scoped twin-stick arena shooter.The game isn't currently packaged and available for download, although I'm considering that right now. The game's code is quite messy, since the point was simply to use it as a quick test of my library's capabilities, rather than to start a 'serious' development project. It's more of a game jam-style game.
Regardless, I took the time to make a video of the gameplay. Since there aren't any sound effects anyway, and the music was borrowed from one of my old game jam entries, I decided not to record the audio. Feel free to add whatever background music you like while watching.
Conclusion
I'm really happy with the progress that I've made in the past 3 weeks. I took a simple collection of asset loaders and turned it into a wonderful budding library of game development tools. Now that I've proven that rapid development is possible with this engine, I'm going to try and participate in more game jams again. In addition, I think I might try to make some smaller games as well.Most of that will have to wait until after I graduate though. This is a very tough semester for me.
Subscribe to:
Posts (Atom)