Thursday, September 4, 2014

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.

Thursday, August 21, 2014

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.

Wednesday, March 5, 2014

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!)

Saturday, February 15, 2014

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.

Monday, February 10, 2014

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!


Thursday, February 6, 2014

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!

Friday, January 31, 2014

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!