Tower defense game

It's been a bit of time since my last post, mainly because I've been learning a whole new language/framework to program games in. I wanted to try something different after I finished Lacadia in C#, so I had a list of frameworks and engines that I could use and the Love framework for lua was on there. Love is a 2d framework with a bunch of cool,easy to use built in features. There's a particle system, custom shaders, physics, and a bunch more that I haven't even discovered yet!

So my first project using Love was a generic version of Pong, it didn't take very long to get a working version. At the same time, I had watched a video about adding "juicy" effects to your game that wouldn't effect gameplay that much, but make it much more interesting/fun/satisfying. So I began to add some of the things to pong.

1. Particles trail following the ball, it highlights the balls movement, and makes it seem like the ball is really moving
2. Easing on the paddles makes stopping the paddles seem more smooth and fluid. I was surprised at how much of a difference it made when I took it away.
3. Screen shake on hitting the ball as the number of consecutive hits without a score increases. I think this is a cool feature and it makes it the gameplay much more exciting as you hit the ball more and more times
4. Ball hit animation. When the ball hits a paddle, it's radius shrinks and then gets bigger and then eventually settles on the original size. It looks nice and makes hitting the ball feel powerful.
5. Something else to add would be sound, but I didn't feel like hunting around for/making my own sounds

All of this helped me get to know lua and the love framework pretty well.

What I'm working on now is a variant of the Tower Defense (http://en.wikipedia.org/wiki/Tower_defense) game. It's something I wanted to do for a while, just never really got into it. I thought it'd be cool to do a fantasy themed one, but I realized that that's been done a lot and I've done the fantasy theme a lot. So I kept thinking about different ideas and came up with something I like. 

So there are three types of towers: red, green, and blue towers. And there are colored enemies made up of a red,green, and blue component. When the enemy gets in range of a certain color tower, the tower starts to "steal" the enemies color, and when an enemies color gets to black, it dies. So if I have a red tower and a red enemy the enemy will slowly start to lose red color until it gets to black. If i have a red tower and a purple enemy (red and blue), the enemy will lose all of its red color and then end up as blue (I'd need to have a blue tower to kill it). I think this is an interesting idea. You can have different combinations of colors for enemies that actually require strategic placement of the different colored towers.

I also added a pretty cool lighting feature for the towers, which I show off in the video below...
Thanks for reading!

Particle System!

So as I mentioned in my Lacadia blog post, I've gotten a little side tracked and started a new project with particle systems in Monogame/XNA. The whole point of this project is to see how many particles I could have on the screen without falling below 30 fps. It was an interesting challenge, and it has definitely taken me places I did not expect to go. And by that I mean shaders. From my understanding, a shader is code that is run on your GPU with input from your CPU. So the big thing is take all of the computation and stuff you're doing on your CPU and does it on the GPU; it's much faster.

So in order to do this I had to learn about HLSL or high level shader language. It was pretty interesting to learn about actually! I hit a couple bumps in the road, but now I've gotten my shader working quite nicely. It can now do lighting, color fades, and color changes! Pretty cool stuff.

So let me take you through the events so far. I first start my project, using the same strategies I used in Lacadia for particles... I end up only being able to render ~2200 particles before I get down to 30 fps. Not cool! I don't quite remember how I found out about using shaders, but I investigated thoroughly, and after quite a lot of fiddling and learning, I was then able to get ~4000 particles rendering before 30 fps. You'd probably expect more, but I was actually making a really dumb error. So the way I was passing all the particles information to the GPU before was looping through each particle, and sending its information to the GPU, drawing it, then moving on to the next one... Well I ended up compiling all the vertices of the particles into a list of vertices, and sending them all at once to the GPU... HUGE increase in the number of particles.... I went from ~4000 to ~24,000 particles with 30 fps. 6 times as many! It was an awesome discovery! That puts me where I am today, and honestly i'm not quite sure what else I can do as of now to increase that number even more.

So what I've been doing lately, is investigating light sources with shaders, because I think I want my next game to have some sort of dynamic lighting, its pretty cool looking! So I've implemented a point light, that can have different colors of lights. I'll put the video down below as it's much more clear!

Hope you enjoy!

General code readability, some class updates, and Render targets

I kind of got side-tracked since my last update for Lacadia. After I started fooling around with particles, I wanted to create a separate project for fooling around with particle systems and see how efficient I could make it. It's been really interesting and I'm going to start another blog about that... (I'm not exactly sure if you're supposed to have more than one blog but I guess I'll figure it out!) But I just got back to making some changes for Lacadia...

One of the biggest things I changed was the way the code was organized. Previously I had all my data for the current level, items, characters, enemies, etc. just sitting in my main Game class. Well I decided that wasn't very clear, and it was pretty ugly too, so I made a GameLevel class, and basically moved all the character, enemies, items, rooms, hallways, and other things into that, and in my main game class, I just call GameLevel.Update and GameLevel.Draw. I think it makes it a little more understandable. Another thing it allows me to do is have a reference to the current GameLevel without having access to the Game itself. So following that change I created a GameObject interface. A GameObject is anything that is going to be on the screen. So characters, items, chests, enemies are all GameObjects. A GameObject has a position, whether its removed or not (for instance if an enemy dies it sets this to true), a reference to the GameLevel it is on, and some other things. This allowed me to make A LOT of my code waaaaay more readable, and clearer as well. Now I'm not sure if this is a good thing to do, I don't really understand the whole use of private and public variables, but I'm guessing having your character be able to access all the enemies and item lists is probably a bad thing... I'll have to investigate some time.

Another thing I did was update some class mechanics. I'll put a video of these with this post, but basically I changed the whole Warrior attacking mechanic. Previously the warriors sword would follow the mouse, so you could "swing" it by moving your mouse in a direction. All I did was put collision detection on the sword and that was that. This caused problems and wasn't very fun though. You could just hold your sword still and enemies that were on top of it would die, which wasn't very fun. Also swinging it around with your mouse was kind of hard. So I got rid of it. I changed it so when you click, you swing your sword around you in a circle, and it damages all enemies it touches. It's still not quite satisfying when you attack with the sword because you can't really control which direction it goes in, but I think I have an idea to fix that.

The last thing I want to talk about is render targets. So along with fooling around with particle systems, I started investigating my memory usage and frame rate. I discovered that drawing the stats of your character and stuff on the screen was escalating my memory usage a lot and it was because I was creating these strings and then throwing them away, multiple times per second. So I wanted to find a way to only draw stats if they were updated. In come render targets. Render targets are basically like another drawing layer. You can draw on them, an then draw them on top of the main graphics. So I draw all the UI on this other render target, and then if it needs to be updated, I update the render target. It helped memory usage a lot, although I still should change those strings to string builders.

So that's it for today's blog post! Hope you enjoyed!

First post on blogger

So, I decided my little website just wasn't doing it for posts about my games anymore, I wanted to keep a devlog for my games, but didn't really feel like figuring out how to make a nice readable website by myself. So I've decided to move my updates and such here. If you want to check out my previous posts, you can go to my website and read about them (link will be posted at the bottom.) My website also has links to some videos I've posted demonstrating some of my updates to my game if you want to check them out too... From now on though I'll be posting later videos on the blog post itself. I may end up just moving the stuff i've already done onto here, but I'll decide that later.



devlog: http://clowman.net76.net/thoughts.html
videos: http://clowman.net76.net/videos.html