If you’re going to code badly… do it with style!
Please, for the sake of "the next guy" (or yourself a month down the line) tab format your code. Especially if you aren't that "great" a programmer and your 1240 line file is a mass of spaghetti if statements.
If you have a nasty mess of if statements, there is just no easier way than to tab format it. However, no tab formatting is better than a little tab formatting. Take this for instance:
if(this == that){
if(that == this){
Do this
Do that
if(this == that){
Do this
}else{
Do that
}
Do this
if(this)
Do that
if(that){
Do this
}
}else{
if(this == that){
Do this
Do that
}else{
if(this)
Do that
if(this)
Do that
if(this == that){
Do this
}else{
Do that
}
}
if (this == that)
Do that
}
if (this == that)
Do this
}
It's a mess, but at least it's readable. If you ever do anything that looks like the above, you have almost definitely done something wrong. You probably should have used some sort of multidimensional array, or stored some stuff in a DB and done a good SELECT statement.
But if the word "multi-dimensional array" sounds like a sci-fi weapon to you, and you can't function without if statements, then please tab them.
If you don't tab your code blocks consistently you will end up with this:
if(this == that){
if(that == this){
Do this
Do that
if(this == that){
Do this
}else{
Do that
}
Do this
if(this)
Do that
if(that){
Do this
}
}else{
if(this == that){
Do this
Do that
}else{
if(this)
Do that
if(this)
Do that
if(this == that){
Do this
}else{
Do that
}
}
if (this == that)
Do that
}
if (this == that)
Do this
}
I DEFY you to be able to read that code. It's insanity, and will drive any sane person to the brink of delirium.
If you don't tab them, that's OK (but not optimal). It's better than tabbing inconsistently. But please put brackets on EVERY if statement. Yes, all of them. Even if it's just one line. I know you don't have to, but just do it. There is just no good reason not to. One good reason to do it is that when you come back in a month and add a second line to that if statement, if you forget to add brackets at that point then that second line will always execute, and thus a bug is born. Make it fail safe.
Now, if you inherit some horrible quasi-tabbed code (like the bunch shown above) you do have some options.
A bad (but better than nothing) option is to open it up in an IDE, highlight it all and hit SHIFT+TAB until there is no formatting (then you could even go through and tab it all if you can figure it out).
A good option is PHP Developer (and many other IDEs) which will show you where the opening and closing brackets for a bracket set are. Aptana (which is basically eclipse) does not. Textpad does not (Although you can highlight an opening bracket and hit Ctrl+m to see the closing one). Dreamweaver does (I think. I believe it will actually re-format your code for you).
For those of you newbs out there learning to code for the first time, use an IDE like Textpad or Dreamweaver and set it to help you out with your formatting (STOP USING NOTEPAD!!!!). In Textpad this is as simple as clicking Configure>Preferences>Document Classes>[Click your programming language] then select "Automatically Indent Blocks". If you use another IDE figure it out and then do it and be consistent. There is almost nothing I can think of style-wise that is more detrimental to success than tabbing your blocks of code. It's one of the first steps to becoming a "good" programmer. I won't say it's what separates the men from the boys, but maybe the boys from the babys.
The Importance of a Tasks List
If you are feeling frustrated on a project, or if you find yourself blogging/reading blogs (or something else) instead of working, you might consider that perhaps you have lost (or never even had to begin with) your direction.
On page 95 in Step 5 of her book "10 Steps to Successfull Project Management", Lou Russell summarized research by Michael Ayers which detailed a few reasons why people resist work. Aside from the obvious ones like "The project doesn't interest them", "The project doesn't need them" and "The project goes against their values", there were two reasons that interested me.
These two reasons (in my oppinion) are very closely related:
1. The project seems impossible
2. The person doesn't know what they are supposed to be doing
If you don't know what you are supposed to be doing, the project is going to seem impossible.
If you set out to accomplish a task, usually all you have in mind is the end goal. Say for example you decide you are going to make some cookies. You know what you want. You want to savor the sweet gooey goodness of some moist fresh from the oven chocolate chip cookies. But if you don't know what you are supposed to do to get them, the project will seem impossible.
You may wander around the kitchen for a while, opening the oven door and looking inside hoping they will appear. If you're like me, you would probably focus on something you know, and get more and more granular with that subject until you have lost complete site of the project you started, and focus entirely on something you do know. You will end up building a replica of the oven, or inventing a new kind of spatula, or perhaps making a peanut butter and jelly sandwich before you even realize that you have come no closer to accomplishing your goal.
It's easier to just ignore what you don't know and focus on what you do. Your avoidance might just go so far as to lead you out of the kitchen entirely. You could end up watching tv on the couch, or playing ball in the yard, or just going to the store with a vague notion of buying some cookies as a pretense.
Stop. Just stop right there. Sit down, get a piece of paper out, get a cook-book, get the oven manual, make a plan. Don't spend too much time on it, but spend just enough to get you going. Focus on the parts you don't know, go large scale on the parts you do. You don't need to detail exactly how you need to use your thumb and fore-finger to turn clockwise the nob marked "oven" to such and such degrees, just say "turn on oven to such and such degrees". However to get those cookies really mixed up you may need to detail a tricky wrist flip. But don't spend three hours on a plan for a project that should take 20 minutes.
In order to make the impossible seem possible, you need to know what you are supposed to be doing. You can't know what you are supposed to be doing unless you have a plan. A tasks list. So next time you find yourself blogging, or surfing, or gazing out the window, stop and think, "Why am I procrastinating/avoiding?". It may just be as simple as you don't have a plan.
Side Scrolling
Just a little update post. We've got scrollage (remember, you can move the ball with the arrow keys. You might have to click on the game to activate it though).
It hit me today that I didn't need the ball to move, I needed the stage to move. It took some doing, but I've now got the ball staying still in the dead center of the stage, and the stage zooms around the ball. This probably will get some tweaking, but here is basically what I had to do:
1. Move the ball.
2. Capture the x, y values of the ball.
3. Put the ball back in the middle of the stage.
4. Capture the difference between where the ball was and where the ball is.
5. Move the stage by that difference.
I'll explain in more detail in my forthcoming tutorial.
All that's left now is to make the ball react to left sloping ground. Once I have that done, I'll clean up the code and make a big level. Once I have *that* done I'll play with it a bunch and either get bored with it, or I'll add monsters and upgrades and actually make it into a game.
Making the Ball Rotate
You asked for it, you got it. The ball now rotates.
I realized that I already am capturing how fast the ball is going along the "x" axis (left and right), and that I could rotate it simply by telling it to rotate the amount that it was moving on the x axis each time the frame updated.
All it took was this simple line of code:
_rotation += dx;
At first I did this:
_rotation += dx + dy;
So that when it would also take into account how much it was moving along the y axis (up and down). This worked really well and looked really cool because then when you pressed the "up" arrow to make it go up, it looked like it was "digging" through the air. But then I realized this was only conveniently working because I had it sloping down to the right. If it were sloping down to the left, the ball would not rotate because the dx would be negative and the dy would be positive and they would cancel eachother out. Also while it is sloping down to the right like it is now, they are both positive and actually make it look like it is rolling faster than it should be.
By the way, in case you haven't noticed, if you click on the flash movie, and then press the up, left, and right arrows, you can make the ball move.
One more thing. It is sort of jitteringly hovering above the ground right now. That's not good. It's not supposed to do that. I need to fix that...
The Ball Will Bounce…
Turns out, the whole problem was that I forgot to actually "rotate" the line. Apparently there is a slope, and then there is a slope. If you draw the line as a sloped line, flash doesn't consider it sloped. If you draw it flat, THEN rotate it to the slope you desire, flash considers it sloped. You then take that line and bounce a ball off of it. The example now WORKS! Also, note that rolling and bouncing are exactly the same, and this example rolls. Rolling is just bouncing so small that you can't see the bounce happen... kind of...
The Parts of a Triangle
Anyone remember Trigonometry? No? Me neither... Oh, wait, that's right, I never really took it. Well, I took Algebra and Geometry, but never a class specifically called Trigonometry. Is there such a thing? I'm sure there is. Anyways, I'm re-learning the parts of a triangle and how to find them.
Here is what I have figured out so far:
Why am I doing this? Well, I have to if I am ever going to get this game working.
Here is what I found out (after buying a $40 book to learn this. Excellent book by the way...):
In order to bounce a circle or bounce a ball off of a slope you have to bounce it off of not a slope. Yeah, let me say that again, you just basically don't bounce it off of a slope. What? Well, there is no such thing as a slope. There is flat, and then there is flat. To you it looks like a slope, but really it isn't. It's just a flat surface.
I know, I know, I'm not making sense here. Let me clarify. The only reason it looks like a slope to you, is that you are not on a level plane with it. A line is a line is a line. Tilt your head far enough and this: | will be flat and level. I'll venture to guess you only had to go about 90 degrees either way and that line became flat.
It's the same thing with flash:
- Take your angle
- Make the computer tilt it's head until you no longer have a sloped line (but rather a horizontal line)
- Do your calculation (make it bounce off of that line)
- Tell the computer to tilt it's head back
So, now I take the method I described a few days ago for finding the "slope" of the surface the ball is interacting with, and use the triangle that is formed by that interaction to apply this bounce method and I've got the main motion mechanics of my game working.
Should be easy. Hah! We'll see...
Lookup Tables for Math Equations
Well, I've begun creating little tutorials for myself.
The problem is that it sometimes can be months between flash game projects, and I often forget some of the things I learned last time around (although they are much easier to re-learn, but I usually just re-member).
So I started taking notes, but then I started just making little flash examples for myself, and then thought about it some, and just went ahead and started making a little tutorial.
I've never actually seen this technique used or suggested anywhere online (although I'm sure it's not original to me). So, I am posting it here (soon to be followed by many others).
What this does is allows you to take a complex equation, which will bring your flash game to it's knees, and predict different inputs and pre-calculate outputs. Then during the game if you didn't happen to predict an input, it will go ahead and calculate for that input, but then from that point forward consider that calculation as a "pre-calculated" calculation.
I've not actually used this technique in any game yet, and I know there will have to be some adjustments to it (you will probably have to round to whole numbers, because I don't think it will work with decimal inputs, or you will have to multiply everything by 100 to allow for decimals to the second place). So basically, if anyone uses this technique, let me know how it turns out please!
Tutorial Page
Source Code
Newton’s Laws
So... It turns out that what I am trying to do is one of the hardest things you can possibly try and do in two dimensional game programming. Great. While starting a new job and writing my first book.
I remembered that I had picked up "Beginning Math and Physics for Game Programmers" a while back when I was working on my tower defense game. I cracked it open expecting some sort of simple equational explanation that could be quickly and easily applied to my game and solve my problems.
Nope. It's not until chapter 11 that they start really talking about it. That's cumulitive of chapters 4, 8 and 9... and that doesn't even start addressing the collision part of it. That's just "If you have a ball with a known wieght on a known slope moving from a known point to a known point, THEN this..." So either it's a crap book, or it's just freakin hard.
What I did realize however is that if I figure this out I will know how they did Linerider (kind of)...
I’m a newb
Just browsing through some samples/tutorials here has made me realize just what a newb I am when it comes to all this flash game stuff. I think sometimes I struggle with stuff for days that would take someone else but a few hours. This can get very frustrating for me. I still have a lot to learn.
On the plus side, I really love coding, so it makes it all worth it. Even if it does make me feel like a complete idiot sometimes...
Oh, and I was recommended this book: "Foundation Actionscript Animation: Making Things Move" by Keith Peters by a flash game programmer whose game I liked enough to write him asking what the algorithm he used to handle his ball physics was. He didn't tell me the algorithm, but said he basically got it from that book.
Physics
It's all about how you search for what you search for (which you all already knew).
In my search for an algorithm for my marble game, I've been typing in asinine things like "rolling ball" or "game programming ball rolling" or "game programming 2d scrolling". Garbage like that.
Well, this morning I stumbled upon a repository of flash games, which led me to a little game called "ramps". After e-mailing the author to find out what his algorithm was, I noticed he used the word "Physics". Duh!
A single google search on the words "Game Physics" yielded a plethora of results. Hooray for me! Soon I will have my rolling routine in hand and ready to go!
This was immediately following a brain wave I had in the shower about an algorithm to find the angle of the slope that the ball might be resting on. It would probably have proven to be very taxing and slow, which would have made the game unplayable. We'll see how it compares to what other people have done though. I may just have figured it out myself, right before I found it online.
The method I thought up was this:
1. Take your circle (or ball) and add/subtract the radius (half the width) of it to the center x and center y coordinates in order to find the bottom left and bottom right corners.
2. Use a for loop (up to the height of the ball) to determine how close A is to the ground
3. Use a for loop (up to the height of the ball) to determine how close B is to the ground
4. Use the difference to determine the slope of the ground underneath A and B and how it should effect the direction of the ball.
I'm not exactly sure how I would use this information that I glean yet to move the ball. I do know that this would probably be hell on the processor, and that this is probably the wrong method. It's just the one I happened to come up with this morning, and I thought I'd share it.
I'll let you know as soon as I settle on a better one...
The one I have been using sucks. Basically what it does is use if/else statements to check and see if one side of the ball is hitting the ground and the other isn't. If one side is, it tells it to start moving towards that direction. This method does not take slope into account AT ALL (which is why it sucks).
Also, right now my collision detection happens after the ball has already moved. It needs to happen BEFORE. That way you will never have the ball inside of the wall, because the method will predict where the ball is going instead of tell me where it is (so you can act instead of react).
Pages
- Projects
- The History of the World (as relevant to Christopher McCulloh)
- WordPress Themes
- Continuum Refactor
Categories
- autobiographical
- flash games
- hardware
- history
- iPhone App Development
- Java
- Javascript
- math & physics
- movies
- n342
- plugin
- programming concepts
- project management
- prototyping
- screencast
- Software
- Theming
- Tools
- TOTW
- tutorial
- Uncategorized
- Usability
- video games
- web sites
- Wordpress
Blogroll
Archive
- February 2013
- September 2012
- July 2012
- May 2012
- April 2012
- December 2011
- November 2011
- October 2011
- May 2011
- January 2011
- November 2010
- October 2010
- September 2010
- August 2010
- June 2010
- May 2010
- April 2010
- February 2010
- January 2010
- December 2009
- November 2009
- October 2009
- August 2009
- July 2009
- June 2009
- February 2009
- October 2008
- September 2008
- July 2008
- June 2008
- May 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- June 2007
- November 2006