Team Fortress 2′s Revised Gameplay Mechanics

The people over at Valve seem to believe that scouts were an underpowered class on certain standard maps; my question is, have they ever seen anyone who is good at the class? Sure, the game is not marketed towards elitists who would rather tediously perfect the art of timing and count down in their heads the time it takes for health packs to respawn, but the new functionality of the scout is somewhat overwhelming.

As expected, Valve added one VERY useful melee weapon, and 2 utterly pointless utility items. Although, to be fair, the new drink that replaces the pistol can often substitute for a medic’s ubercharge on a well organized team; and now my complaining begins. Originally, the scout was a class that required a lot of dexterity to excel at. You had to be able to anticipate players’ actions, and jump around them to avoid their attacks.. it rewarded skilled players greatly and made poor players look horrible. Now, the scout is quite easy to use. The new melee weapon allows the scout to stun anyone at range, and while I myself love this weapon and have great fun with it, I think it is vastly overpowered. The ability to stun ubered targets is just an insult to the other defensive classes. Why play something that requires thinking to defend, where you can just hit a ball at someone.

And that energy drink? Man, I hated when valve released the sandvich and the flare gun. Any skilled player will tell you that those weapons are about as useful as the f10 cheat menu [for those that don't know, f10 is a quit game button]. Sure, the flare gun is ‘fun’ to use, but who plays games for fun anymore? It’s all about the competition and testosterone pumping action.. right? I must reiterate how utterly useless the flare gun and sandvich were, particularly because using either meant losing a shotgun, and either class without a shotgun (ESPECIALLY the pyro) would be caught dead in the water more often than not. Well, for this new energy drink, the scout must sacrifice his pistol. Again, for me, this would be an unfair tradeoff. BUT, that is because I would never intend of playing scout as a support class (which is now what it is). Using the energy drink, the scout can play the role of a ‘tank’, and ‘tank’ enemy turrets while a demoman comes in behind him and destroys them to kingdom come. Well folks, the day a scout can single-handedly play the role of an uber, an anti-uber, and a very fast-moving (fastest class in the game) dextrous killer, well that day is the day clans rethink their playstyle.

Coming from Guild Wars, a game that changes what skills do frequently in order to prevent people using the ‘same old thing’, change is welcome and accepted. However, I believe scouts are a bit too over-powered right now. Especially coming from someone who frequently plays sniper and spy, I’m not liking this update much at all (Unless I play scout, of course )

Tremendous Optimizations!!!!

Yeah, you counted right ; those are 4 exclamation marks. As it turns out, I’m an idiot.
My original object hierarchy meant that each instance of the object dealt with its own sprite pointer and texture. It wasn’t a perfect solution by any scalar multiplication (over zero, anyways.. ha!), but it worked. And now I decided to implement a hash table ADT, I am keeping all the textures in that ADT. Each object now has a pointer to a sprite and a pointer to its texture. (The obvious solution). So now, instead of each object having to free and load and take up memory on its creation, the texture needs to be loaded only once, and only freed once the program terminates. DRASTIC performance increase. Also, instead of each object’s render() method initializing its own sprite’s begin and end methods (required before and after drawing is done), the object is passed a pointer to the Object Core’s sprite pointer upon creation. The object core originally iterated through all objects and called their render(). Now, it does the exact same thing, except it calls the begin() and end() method of its own sprite only ONCE, and each object’s render() simply tells the sprite to draw in a certain way. Essentially, the sprite object inside the object core is a paintbrush. The object core says when it is OK to pick up the paintbrush and when it is not OK, and each object takes it and draws a picture with it.

STEEPED.

Heim theory vs Supersymmetry vs Other

One of the ‘expected’ methods of future space travel is something called a warp drive. Inspired by Star Trek (or possibly some other sci-fi series), it offers an interesting method for FTL (Faster Than Light) travel, without violating the currently accepted laws of physics. No, accelerating to the speed of light or any super-high speed (with current understandings and technology) isn’t feasible, because of the large amount of work (and therefore energy) needed to achieve such a change in momentum. A warp drive does not move the ship at all, instead, it manipulates the space around the ship. And now is when things start to sound ridiculous, but this is only because our current understanding of physics is very primitive. Anyways, what this means is that instead of using some sort of reaction mass (in order to have a net change in momentum), the space around the ship is manipulated in order to propel the ship forward. Now, this is where the theory stops being feasible and becomes a theory – we do not yet understand how spacetime works. There are various theories, but none are yet unequivocally accepted. I personally believe we will not be able to move forward in this regard until a Grand Unified Theory is proposed and validated. And there are many attempts. The most prominent ones are M-Theory, String theory (particularly superstring theory), and Loop quantum gravity, in my unprofessional opinion. There is one theory however, that is not well-known, as it was never publicized to peer-reviewed journals, called Heim theory. I do not yet fully understand any of the theories, and am constantly trying to educate myself further, but from what I’ve learned so far, Heim theory and Supersymmetry are disjoint theories ; they disagree with each other (or so I’ve gathered). I do know, that using the CERN Collider (Also known as the LCH or Large Hadron Collider), scientists expect to be able to detect some of the particles proposed by supersymmetry, and this either means that they overestimated the capabilities of the collider, or these particles do not exist. Either way, I believe with the results of the CERN Collider, we will be ready to take more steps forward in our understanding of the physial universe.

But, back to the issue at hand – warp drives! What then do these different theories mean for a warp drive? Well, aside from the possibility of other forms of travel (Parallel universe usage, wormhole usage, or other yet undiscovered methods) , it would define how we could manipulate the spacetime field around us. For example, using antimatter and super dense matter (possibly dark matter?), one could theoretically create some sort of particle attractor that could attract antimatter behind a spacecraft and super dense matter in front, using the gravitational force to propel it. Or, once more is understood about the fabric of spacetime, depending on the mathematical mechanics, to be able to bend it around the ship in a way that it is constantly shrinking behind the ship and expanded in front, so as to propel the ship forward. One theory I read states that gravity is the result of spacetime fabric pushing against matter, and if this is the case, we could theoretically manipulate the fabric to attract more of it at a certain point, creating a larger push, resulting in possible propulsion?

The possibilities are endless! Well, not really.

New Update – Relative Motion, Accepted Object Hierarchy, and More!

So, now that I’ve decided on the object hierarchy, I’ve began working on the player’s simplistic 2D motion up, down, and the turning. (Forward moves in the direction you’re facing). Well, I’ve decided on creating the viewport as only a fraction of the entire map (viewport isn’t exactly the correct word, as I’m not using the predefined viewport type), and so, when the player moves around the screen, the background changes, because there’s more of the world to explore than what is initially visible. The way I’ve decided to do this is not as deterministic as forcing the player to be in the center of the screen (which would essentially imply that the player never moves, but rather his movements move every other object), but rather to scroll the background at a factor of the player’s speed. Depending on how far we want the background to be (or, more technically, on the size of the image), we can adjust this factor through a simple #define. This gives somewhat of a parallax effect, as it looks that the foreground is moving at a different rate than the background.
Well, the obvious problem with this, is if the background is moving relative to the player’s motion, what happens to all the other objects? Well, the way I’ve decided to implement it, is to pass a pointer to the ObjectCore upon the creation of the BackgroundObject, and when the background moves (more shortly), it calls a function in the ObjectCore that iterates through all Objects and moves them by a factor similar to that of the background’s movement relative to the ship. Note that the background’s movement is triggered by the movement of the Player object (which incidentally also has a pointer to the ObjectCore, and calls objectCore->getBackground()->move(); when the player decides to move their ship).

The next thing (and something I’ve been stuck on for quite a portion of the day) is how I can create generic function pointers. I’ve found somewhat cryptic tutorials using google, and it’s something that was never covered in my studies (yet), so it’s somewhat of a new frontier. Essentially, I need to define a struct with a pointer to a function with unknown arguments, a long, and a pointer to a struct of the same type. This is used as a sort of event clock, so that a function can be executed once that long reaches 0 – basically, a timer. I know absolutely nothing of threading and Sleep() or other such commands, so I’m sure there’s an easier way to do this that I’m missing, which is something I’ll surely look into. But right now, I need to figure out how (or if it’s possible) to create and use generic function pointers. I know one way to do it could be to create different pointers for different functions and only allow certain functions to be used, however I think it would be a lot nicer if I could generalize the process and allow for use of ANY function.

Code Repository Operational!

I’ve found myself a (seemingly) good web host and have quickly put together a small webpage! Feel free to browse around and look at some of the things I’ve programmed. I’d personally say the highlight of it is the DirectX game I’m currently working on. I’ll update that project every friday! Progress is being made very quickly! Here is that webpage.

Possible thesis?

Here’s an interesting idea, that may or may not have been visited in the past : distributed computing! Yes, distributed computing is already a popular field of study, but using it in hopes to check the validity of a result using redundancy? Now that’s something!

Consider this :

If you were living inside a space station, with automated critical systems that control things such as the amount of oxygen in the air, the amount of pesticides to use on food, ran diagnostics on various other hardware, would you trust your life to one processor and accompanying software? What would happen if a virus was developed, what would happen in case of a computational error? Would you ever feel secure knowing that could happen?

Now, what if instead of one ‘computer’ made critical decisions, multiple computers made these decisions. What if the decision had to be ‘approved’ by multiple computers? I’d rather not go into too much detail just yet, but think of it like a bureaucracy. For a decision to be made, the majority of computers have to agree to it. And how would they come to such an agreement? Simply put, by comparing their outcomes that result from similar inputs. That is to say, put input X into computer A and B, if A.X = B.X then all is alright (unless of course both miscalculated in the same way [possible causes : virus, dumb luck], more on this later), otherwise if A.X != B.X then a problem is flagged and the computers will notify a human as well as initiate diagnostics on themselves.

Hmm?