Matrix Multiplication, Conditional Statements, and Functions

I actually was able to finish matrix multiplication the day after my last post, which was pretty cool. Unfortunately, school has started back up, so I think development will slow quite a bit. I'm working on implementing symbol tables (needed for functions) and functions at the moment.

Matrix Multiplication

The way my program works so far (there's probably a better way) for matrices is that for printing and operations, I push all the elements onto the runtime stack in reverse order. So for printing, I just pop off the elements on the stack and throw in a couple of newlines here and there. For storing matrices in memory, I just pop each element off the stack and then put it into the memory location corresponding to its location in the matrix (according to matrix size).

Now this presented me with a problem at first with matrix multiplication, because I'd have two matrices on the stack at once and I'd be pushing the third resulting matrix on as well. I couldn't access the elements of both matrices with simple pushing and popping. One thing I forgot about  was the special stack pointer register though! So what I did was after I push the first matrix on, save the stack pointer to a temporary register, then push the second matrix on and save the stack pointer to another temporary register. Then I could simply look at an offset of these temporary registers and get the matrix element I wanted.

Conditionals

The next thing I actually worked on was if-else statements, and I actually was able to complete those as well. The syntax is pretty generic, it is simply if expression then statment list else statement list. Of course the else block is optional. The reason I ended up doing this was because I was trying to plan out functions in my language, and I was writing base functions that I wanted to include in the language, some of which require conditionals!

Functions

One of the decisions I had to make when designing functions in my language, was whether or not I wanted to include types of parameters/return values or not. While it may look prettier, I think this can lead to some issues that I don't really want to deal with. Plus the way I decided to write the functions gave me a neat way to give a variable name to the size of parameters. So without further adieu, here is what I'm planning on implementing for my function syntax. I'll give the sample declaration, the sample call to the function, and then a description in that order:

(Note: the three periods just signify some other code might be there)

\foo =
   ...
;
...
foo.
... 

This is a function call foo that takes no parameters and returns nothing. To call any function, type the name, the correct number/sized parameters, and then a period.

\foo A[m:n] =
   print A @ m - 1,n - 1
;
...
foo [1 2,3 4].
...

This is a function that takes one parameter, a matrix refered to as A (in the function) with m rows and n columns, and returns nothing. You can reference m,n, and A in the function.

\foo num -> int =
   return num + 1
;
...
if foo 0. then
   print 0
;else
   print 1
;
...

This function takes one parameter (this time an integer, as no size is declared, named num), and returns an integer. Integers can be used in conditional statements, so you could use the return value in an if statement. The integer 0 is false and everything else is true, so this code would print 0 (as foo 0. would return 1).

\foo A[m:n] -> [n:1] =
   B = [n:1]
   ...
   return B
;
...
B = foo [1 0,0 1].
...

This function takes a matrix, and returns a column vector (could also be a full matrix). You can use the sizes in the parameters in the return size as well.

\foo A[m:n] -> [m:?] =
   ...
   return B
;
...
print foo [4:4].
...

The function takes an m by n matrix and returns an matrix with m rows and an unknown number of columns. For instance, when computing the basis of a matrix, you don't know the dimension (or how many vectors will be in the basis) without reducing the matrix or using other properties.


I think these features cover a decent amount of problems that you would need to solve using my language, but obviously I might think of some more!

Moving Forward

So after I finish changing the existing code to use a more complete symbol table, I'm going to go forward with function parsing and function code generation. Perhaps after that I will take a look at assembly optimization or AST optimization.

Making a compiler for a small programming language

I've been working on a compiler for a language that deals with matrices. I took a compilers class last semester, as well as a couple of classes dealing with linear algebra and matrices. I wasn't too happy with the resources out there for doing matrix operations, so I decided to write a language for it!

Here's some example syntax to start off with:

Matrix Declarations:

Nonempty

{1 2 3,4 5 6,7 8 9}
This represents a 3x3 matrix with first row 1 2 3, second row 4 5 6, third row 7 8 9.
It would look like this drawn out:
| 1 2 3 |
| 4 5 6 |
| 7 8 9 |

Empty

{3:3}
This represents a 3x3 matrix containing all zeros
It would look like this drawn out:
| 0 0 0 |
| 0 0 0 |
| 0 0 0 |

Variable storage:

My language sort of uses implicit storage in the way that you don't declare a variable's type, but all the variables are matrices.
A = {3:3} --A now contains an empty 3x3 matrix
B = {1 2,3 4} --B now contains a 2x2 matrix
C = 4 --C now contains the integer 4
D = 5 * 2 - 3 --D now contains the integer 7

Matrix Indexing:

Assume that all the variables have the values as defined in Variable Storage.

Indexes are zero based

Single element

B @ 0,0 --the upper left element in B, 1
B @ 1,1 --the lower right element in B, 4

Row

B @ 0,# --the first row of B,{1 2}

B @ 1,# --the second row of B,{3 4}

Column

B @ #,0 --the first column of B, {1,3}

B @ #,1 --the second column of B,{2,4}

Other Cool Stuff:

Now that I've discussed matrix indexing, you can also use indexing in storage.

Taking A as an empty 3x3 matrix, I could do the following:

A @ 0,# = {1 2 3}

A @ 1,# = {4 5 6}

A @ 2,# = {7 8 9}

Now A looks like:

| 1 2 3 |

| 4 5 6 |

| 7 8 9 |

But say I had a 10x3 matrix, I wouldn't want to type each row declaration out!

E = {10:3}

for x = 0,9 do

     E @ x,# = {(x+1) (x+2) (x+3)}

;

This indicates a for loop with a variable x going from 0 to 9 by 1. In each iteration it sets the xth row to contain 3 elements that are 1,2,and 3 bigger than x respectively.

I'm hoping you can imagine what E looks like now! (like A but with 7 more rows!)

What's left to do:

Matrix multiplication

I have an idea of how to go about this, so should be done soon!

Matrix operations (reduction, span, basis, transpose, inverse, etc)

I currently have a small set of operations built into the language itself (I would generate the assembly for them manually) but I think I will add functions to the language and just include a base library for these functions. This will probably take a decent amount of time!

Code optimization

The assembly that I produce at the moment is probably not the best way to do it. I also might convert it to an intermediate representation before I convert it to assembly, so I optimize it better in that stage. This is probably a while down the road though.

Juiciness!

Unfortunately, it's been a while since my last post. Lots of fun school stuff going on!

So since last time, I've really just added more "juiciness" to the game. What I mean by that is stuff that makes the game look and feel better, but doesn't actually effect game play. One of the things I added was screen shake when an enemy make it past your defenses.
If you think about it, this gives the impression that:
1. It's bad when an enemy reaches the end of the path
2. It matters that they've made it to the end
And of course, it's not too hard to implement so why not! :P

Another thing I'm toying around with is persistence. What I mean by this is stuff that stays on the level throughout the level. So for instance, I put down a red tower, and it attacks an enemy, and you actually see red specks fly off of the enemy and land on the ground. Those flecks actually just sit there until the end of the level. It's sort of similar to you spilling something on the ground in real life... it doesn't just disappear when it lands! I'm not sure if I really like how it looks at the moment, but it's fun to play around with!

The last big thing I changed comes in two parts:
1. I added lines between path nodes. They're just white lines that are a little see through, and they're supposed to represent white light.
2. Changed the spells image to prisms. Prisms are cool because when light travels through them it separates it into the different components. Now I didn't quite stick to this because I wanted a red, green, and blue crystal, but it's close enough! So when you stick a prism in the path, the white light gets absorbed by it, and the crystal emits red light. It's shown in the video (kind of hard to explain it :P). I thought this fit a lot better with the theme of the game (color/light) than paint did. (PS thanks to my dad for the idea of prisms!)

Tower Defense: New enemy and spells!

So I made two big  additions since last time: added a new type of enemy and added spells.

I wanted to add a new enemy for a couple reasons... Previously the only way enemies were different or harder was their health was higher, and it could only go up so high since it's based on color values (the max was (255,255,255) which is white). If you put down a couple of white towers on the level, you were pretty much set and could kill everything no problem. So I wanted to add an enemy that would be a bit harder to kill, and act sort of like a boss. One thought was of splitting enemies... when you kill them, they split into smaller enemies. So right now I have splitting enemies that can split up to 2 times, and into however many enemies I want (it's just 2 right now). It's a lot more difficult to handle these things, since if you do kill them you now have even more enemies to kill.

I'm also trying to figure out a way to have high health enemies that aren't white, because right now there's no point in NOT getting a white tower. I want to have a red enemy that has as much health as a white enemy... this would incentivize having a high level red or magenta tower. As of right now my only ideas for this are adding enemies that have more than 255 as their color value, which would sort of act like a shield. So that's something to think about.

The next thing I added was spells. In a lot of tower defense games, players can use spells to interact/affect enemies without using towers and I wanted to add this to my game. My original idea was to have a paint brush effect that fades away and if enemies move over the paint, something happens. Unfortunately I couldn't really figure out how to produce a paintbrush effect and I think figuring out collision would be difficult. I ended up changing it slightly to be throwing paint onto the path. So right now there's three types of paints (three spells). There is red paint, which does damage to enemies that move over it, green paint that gives you money when enemies walk over it, and blue paint that slows enemies moving over it. I want to put these on a shared cooldown to make deciding which spell to use more important. So for instance if you want to thin out enemy numbers, you can use red paint or if you need more money to get the third upgrade for a tower you can use green paint. Maybe enemies are approaching a point in the path with lots of towers next to it so you can use blue paint so they take a lot of damage from the towers. I think it will make gameplay more interesting and more interactive.

Interface changes for adding/upgrading towers

So I was kind of unhappy with the interface of adding/upgrading towers, and I wanted to change it. First of all, you couldn't really see what the range of the tower was or how many upgrades it had or what it's damage was. So I added a feature where you can select towers, which does these things. It shows the attack radius of the tower, the towers stats appear in the upper right corner, and it shows upgrade paths. Every tower has three upgrade paths, a red, green, and a blue upgrade path. Taking an upgrade path is basically like combining your current tower with a red, green, or blue tower (depending on which path you take). I think it's good progress in the right direction, although I feel like I could make it more clear somehow.

The other big thing I did was add path indicators for enemies. Right now triangle appear pointing in the direction the enemy will take. This could be more clear too, but again I think it's a step in the right direction.

Here's a video detailing everything I just said!

Upgrading towers, sounds, and classes in lua

So since the last post, I've added a few things to the tower defense game...

(1) I added menus! I actually got bored one day and wasn't sure what to do so I figured I'd get it out of the way. The main menu includes a campaign button that takes you through each level one after each other, a level selection button where you can choose just to play one level and then go back to the menu, and, of course, a quit button.

(2) Upgrading towers! Before, I just had three towers, and honestly it made gameplay kind of boring... there was no sense of "progression" or getting better. The way you upgrade a tower (as of now) is to just drag one tower onto another tower (with some extra cost) and it combines their damage. So if I combine a red and green I would now have a yellow tower (additive color model). Now this yellow tower can damage both red and green components. I also made it so when you upgrade a tower, it can target one more enemy (with the max being 3). As of now, you can upgrade towers to max level on every level, but I want to make it so you get another upgrade per level, so by the final levels you have all of them. This would give some sense of progression.

(3) Sounds... So I had an interesting idea for sounds. I've taken a few music theory courses, and I know some cool sounding chords. So my idea was to have each tower play a note when it attacks. When all the towers are attacking at once, you get this cool sounding chord. Right now I only have 4 notes for 4 towers (I need to put sounds in for 3 more towers). I still need to work on my execution of the sounds though (you can hear how it sounds in the video below)

(4) So another thing I did was to refactor my code a lot to use metatables (mimic classes). I found out about these things in lua called metatables. You can specify a metatable for a certain table and if you call a function that the table doesn't have, it will try to call the function with the metatable. For instance: say I have an Enemy table (enemy class) with an update and draw function in it. Now I want to make an "instance" of this Enemy, so I make a new table e to store the data, and set e's metatable to Enemy. Now I haven't set the function update or draw in e. So normally if I called e.draw or e.update there would be an error. Now that e has Enemy as a metatable, calling e.update is equivalent to calling Enemy.update and it's the same for A.draw. It makes the code a lot more readable, and actually uses less memory than the way I was doing it before (I'm not 100% positive about that). My reasoning for the memory is: Every time I was creating a new enemy, I would create a table with each function in it. So each enemy had it's own instance of the update function for instance. Now I just create one function in the metatable, and each instance calls that function. I'd imagine this reduces memory but I'm not sure.

Hope you found this interesting!

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