So I was discussing the whole concept with a few classmates when I said that I didn't want to include critical kills like head shots. They thought that I was going to have a lot of problems since head shots have been a part of the FPS mindset for such a long time. So I thought a little explanation of why I feel critical kill shots shouldn't be a part of this game.
1. Being killed in one shot really stinks. There have been many games that the head shot insta-kill makes the game very frustrating, especially for new players. Ace of Spades in particular comes to mind, and I have personally taken on 5 or 6 players and killed them all before the could get me just because I was able to shoot their heads faster than they could shoot me. While in real life it is very possible for 1 or 2 bullets to take someone out, in a game or an experiment like I am hoping to make this like I wish to encourage competition and a moderate feeling of fair play.
2. It is bad practice to aim for the head in real life combat. The first day of M16 training in the Army they instruct all soldiers to aim for the center of mass. On a human the center of mass is just between the stomach and the chest, where incidentally a large number of vital organs are located. So while it is true that shooting someone in the head will kill them, shooting them in a place you are more likely to hit them like the chest has just as much a chance of killing them. While I realize games don't have to be like real life combat, for the few people who do get put into a combat situation I would like to have this game be good training for them.
3. I want this game to have the feel of a RTS game, but with the players being the individual soldiers. In most RTS games there are certain classes that are stronger than other, but typically there is a decent balance between same level entities. In Starcraft for example, a single terran marine vs. a single protoss zealot would be a fairly matched fight in which one or the other may win depending on the strategies used. If the marine could kill the zealot in one shot by shooting his head, that balance would be shifted. Now I know there are players out there claiming that since heads are smaller and there is a chance to miss that head shots are really skill shots and should be rewarded, but if the reward is your enemy not even being able to counter attack in any way it's too powerful. And so the head will only get damaged as much as the torso.
I hope this explains well enough why I don't wan't to have instant kills. Even vehicle mounted weaponry will seem a little under powered in the game, as the goal is not the super fast paced die every 30 seconds combat normally found in FPS games, rather the stay alive and do as much damage (or prevent as much damage) strategically type game.
Hex Wars (name may change later) is an attempt to make a family friendly FPS/RTS online game. The idea is to have a game that plays something like a strategy board game with the players taking the role of the pieces.
28 February, 2012
No headshots
Labels:
Apoidea,
Brift,
death,
frag,
game,
game design,
game programming,
Hex wars,
No head shots
10 February, 2012
The Official Google TV Blog: OnLive: Console-class Gaming Comes to Google TV
Ok this could be big news for cloud gaming. If Google starts supporting it with the large amount of server power and it's amazing amount of internet influence then we could see it really take off.
Linear Algebra, Matrices, and 3D math
I realize that it appears that I have not made any real progress on this game for some time now. I'm finding that there are many principles that I need to learn before trying to tackle 3D. Part of that is math, which I have been struggling through for a little while. I highly recommend that anyone who is interested in doing anything 3D learn about linear algebra. A brief explanation is that it is the math that helps give the illusion of 3D on a 2D surface (like your TV or monitor). Anyway the learning process is slow as I'm not as young as in times past. As I have said before this will take a long time, especially since I want to do it right.
Labels:
3D,
Apoidea,
Brift,
college,
game,
game design,
Hex wars,
linear algebra,
matrices
No competition inside of a faction
I've been thinking a bit about this subject and how to bring it into this game. Often in MMOs players find themselves competing with their allies for resources such as better armor, that special drop that only one person can get, whoever has the highest number of enemy killed, etc... I really want to bring in the concept that if someone on my team (in my faction for example) gets something that it is a reason to be happy and not envious.
In war situations any resources that can be gained by ones allies or denied ones enemies is a bonus. So for example I don't want to put a limit or respawn timer on resource nodes because it would make it so players within a faction would have to fight over who gets it and when. It would also encourage camping, territorial disputes, and make it difficult for new players to get necessary resources. So what I envision is a large group heading to a resource node would welcome any and all who happen to want to join them, because that means there will be more of that resource for the faction. Having more people with you mean more backpack space to fill up with valuable metal or energy crystals. Also the larger numbers would make enemy ambushes and other enemy attempts to deny ones faction resources less effective, meaning that for all in the faction it is a win. I think that would promote teamwork, camaraderie, and esprit de corp inside a faction, which is necessary if a faction wants to be successful. So that means there will be no special bonus given to the elite other than the satisfaction of completing the mission. I do realize there are players out there who obsess over leader boards and the acquisition of status symbols, and this game may not be for them
In war situations any resources that can be gained by ones allies or denied ones enemies is a bonus. So for example I don't want to put a limit or respawn timer on resource nodes because it would make it so players within a faction would have to fight over who gets it and when. It would also encourage camping, territorial disputes, and make it difficult for new players to get necessary resources. So what I envision is a large group heading to a resource node would welcome any and all who happen to want to join them, because that means there will be more of that resource for the faction. Having more people with you mean more backpack space to fill up with valuable metal or energy crystals. Also the larger numbers would make enemy ambushes and other enemy attempts to deny ones faction resources less effective, meaning that for all in the faction it is a win. I think that would promote teamwork, camaraderie, and esprit de corp inside a faction, which is necessary if a faction wants to be successful. So that means there will be no special bonus given to the elite other than the satisfaction of completing the mission. I do realize there are players out there who obsess over leader boards and the acquisition of status symbols, and this game may not be for them
Labels:
Apoidea,
Brift,
game,
game design,
game programming,
Hex wars,
teamwork
24 January, 2012
Data structures
So to start off this semester of study I am focusing a bit more on data structures, as well as learning more about Java and C# with the XNA Game creation code. Before diving off into coding I have realized that it is much more important to understand the principles of effective and efficient programming. In talking with a mentor about my proposed landscape system he brought up a good point. If I am trying to render thousands of objects that share similar characteristics, like the triblock, that making each one it's own unique object will take a long time to process and will eat up tons of memory. So finding an effective way to represent all of the landscape can be rather difficult to do. This reinforces the decision I made earlier to have indestructible landscape that can be built on, even though that removes the possibility of tunneling under enemy bases and defenses. If the only blocks that can be placed and destroyed by players are the ones that they have gathered the resources for and taken the time to craft then the total amount of memory usage should be considerably smaller. I hope that through the course of this semester I will be able to find what data structures will be most appropriate for everything that I wish to put into this game.
Labels:
Apoidea,
array,
Brift,
data structures,
game,
game design,
game programming,
Hex wars,
landscape
23 January, 2012
The Multipurpose handle
So in looking at how I want to display things I had an idea about how tools will be displayed. I am taking the perspective that the aliens in charge only wish to provide the most basic equipment to the humans, and many things are in reality virtual objects. So as far as actual physical objects go every player will have the suit and an all purpose handle. For the three main modes that will always be available for players in the field the handle will change what kind of output it gets. I envision this handle being somewhat like a WII remote in size. For ranged weapon mode a glowing pistol/rifle will be attached, with the handle being the handle of the weapon. For melee weapon/tool mode a glowing blade will appear on the end of it. In placement mode a beam of light will come out of the end of the handle and whatever object the player wishes to place will show up either 1 a wireframe of the object in the color of the faction to indicate that it can be placed there or 2 a grey wireframe to indicate that it is a no go at that spot. The last mode I think I want to have is just the laser pointer with the option of visible beam and invisible beam(it will default to invisible) which will help players to quickly communicate if they see something that they wish to draw their teammates attention to.
Why so few posts
I was looking back through the posts that I have done in the past, and I found that there were several posts which weren't particularly productive and might have shown a bit of negativity. While part of my goal in documenting this process is to show the entire process that I am having to go through to make this game, I also wish to be efficient in my communications and leave out unnecessary parts, though I suppose you the reader can always decide which posts to read and not read anyway. So if it seems like there isn't much coming out, it's because I would rather have quality over quantity.
Subscribe to:
Posts (Atom)