I did something similar in Warcraft 3, but with a Bomberman game. That wasn't my first project that involved programming though.
My first project involved creating a heavily scripted map for Medal Of Honor: Allied Assault. In that game you have the map which is created in a level editor, and then you create a level script that goes along with it. I haven't played much of Quake 3, but I'm guessing this is the "Quake C" type stuff that that game had.
My vision was to create a level that was heavily scripted that had you fighting alongside squadmates that weren't cannon fodder. There was a medic in the original game, but I wrote a medic script from scratch that was more customizeable. You could tell the medic who to follow, how many health packs he had to give to others, etc. I eventually wanted to write AI for him to take cover during battles but I never figured that out.
The level that my YouTube video shows isn't the first project I did in MOHAA, but it was the culmination of everything I learned writing scripts for that game. Everything "scripted" that you see in the video is done via the level script. The squadmates following each other, the tank encounter, conversations, truck ride, etc were all done with my level script. A lot of things are broken as you can see, and I eventually gave up when I tried to implement wall climbing at the end.
The scripts involved mainly if statements and for loops. There were also several functions, which were either called with "thread function" which would execute the function in a separate thread, or "waitthread function" which would call the function and block until it returned. I asked LOADS of questions on the Medal Of Honor .Map forums, where the people there were extremely patient and helpful, and taught me a lot about programming (especially the user jv_map, or jvmap, I can't remember the spelling).
This was done in the Summer of 2003, when I was 14 too like Vexal. Then Call Of Duty was announced (by the original developers of MOHAA that went to form their own company) and they took the vision that I had for my map and made a complete game out of it
I would go in a heartbeat too. Living on the frontier is something I always wondered about when I read history books as a child. Everything around us on the planet has been explored... I want to go to a new place and discover new things. I was never one that was dependent on a lot of things in order to live, so I imagine I could live quite well in the limited environment (slow internet, no water etc lol).
It's also easier to write implementations when you can rely on assumptions. If you know an array will have space for exactly 12 elements, you can cater specifically to that, as opposed to an array that could possibly have space for only 1 element, or hundreds. You have less cases to worry about. This could also limit your ability to do certain things, but the reason the limit was chosen in the first place was because it allowed the designers to do what they needed to do.
Another example: trying to create the ultimate engine. Most game engines are very specialized. By assuming that a given engine will be used for only FPS games, you can design the program based on these assumptions (e.g. you can't roll the camera upside down when by turning it). Or a multiplayer focused engine, where all logic consists of client/server communications with cheat detection etc since we are under the assumption that we will not be creating singleplayer experiences.
Your new paddle angle is independent of anything you've done in previous frames, so don't try to shove "current facing angle" into your calculations. atan2(y/x) is the right approach, but it assumes that a rotation of 0 degrees will cause the paddle to face the positive x-axis, and that your rotation isn't backwards. You may need to add a multiple of 90 degrees and/or negate the angle to fix things if those assumptions don't hold. Oh, and make sure that you're using radians where you need radians and degrees where you need degrees. Finally, if you're only using mouse displacement over a single frame, you may run into aliasing effects; in that case, summing displacement over the previous 2-4 frames could give better results.
Thanks for the reply. i was using atan all this time which requires y/x already computed (1 argument). i had no idea atan2 existed which is what I needed (giving the angle including negative values of x and y). i used atan2 and it returns angles in the 1st and 2nd quadrants from 0 to 180, and in the 3rd and 4th quadrant from 0 to -180. I fixed that by checking to see if y < 0, and if so, add 360 to the result. actually I should mention atan2 returns everything in radians, i converted this answer to degrees then added 360 to fix the 3rd and 4th quadrant results.
another thing that was messing me up is that im using the SDL coordinate system (positive y is going downward, negative y goes up) which was screwing with my calculations. ive fixed this and now its working perfectly. i actually planned from the start to have it set up so that 0 degrees is facing the positive X axis increasing counterclockwise. i have one image of the paddle at 0 degrees (its actually facing 45 degrees but ill fix the image) and when I load the program i used SDL_gfx to rotate it 360 times and store each of the rotations in an array of SDL_Surface *'s :).
so in short everything works now and I will look into smoothing the movement over multiple frames in the future. thanks for the help!
o and the code below for anyone interested. angle is what the paddle uses to draw the correct paddle image rotation. the image in the array I use is "paddles[angle]"
bool Paddle::DoMove(int x, int y)
double angleRad = 0;
double angleDeg = 0;
//the x and y passed are SDL coordinates. arctan2
// uses cartesian coordinates;
y = y*-1;
//no mouse movement, do nothing
if (x == 0 && y == 0)
angleRad = atan2(y, x);
angleDeg = angleRad*180/PI;
//atan2 reports angles in 3rd and 4th quadrant as negative. fix by adding 360