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.
Showing posts with label Hexwars. Show all posts
Showing posts with label Hexwars. Show all posts
11 December, 2020
Why the break
Hello everyone who may be interested, which I'm guessing at this point is very few if any. I stopped writing this blog several years ago because my professors were worried that if I posted my algorithms and or thoughts on game development that I wouldn't be able to get published in a journal(which is important for graduate students for some reason). Since my masters project would essentially need to be such a paper I stopped writing my blog. Well, I dropped out of school years ago, and I find myself unemployed once again. So in the hopes that this will be useful to others I am going to go back over all of my posts and add my thoughts on how things changed after I have learned a great deal more about this. So let the necroposting commence.
17 June, 2013
Doing things wrong
So I've been enjoying a break from school ( I figure I should do that while I still have the chance) and in between I have been looking at tutorials for how to do a minecraft-like in Unity3D. The particular video series I followed is by one Craig Perko and can be found at .
So what I have learned from this video is that I was going about creating my scene the wrong way. I was creating a new mesh for every face that needed to get displayed, rather than making the faces all fit together into a larger mesh. This would explain why it was performing so badly at my website http://apoidgames.web44.net/wedge.html, I had hundreds of very expensive meshes all trying to fit together. Unfortunately building all of the faces into a single mesh is not quite so easy when using equilateral triangles for one of the planes. Also unfortunately I am taking a class called computational geometry over the summer which will again take much of my time, so I will have to put this project on hold for now(again). Anyway thanks Craig Perko for explaining how minecraft works a little more clearly.
So what I have learned from this video is that I was going about creating my scene the wrong way. I was creating a new mesh for every face that needed to get displayed, rather than making the faces all fit together into a larger mesh. This would explain why it was performing so badly at my website http://apoidgames.web44.net/wedge.html, I had hundreds of very expensive meshes all trying to fit together. Unfortunately building all of the faces into a single mesh is not quite so easy when using equilateral triangles for one of the planes. Also unfortunately I am taking a class called computational geometry over the summer which will again take much of my time, so I will have to put this project on hold for now(again). Anyway thanks Craig Perko for explaining how minecraft works a little more clearly.
23 April, 2013
The Algorithm for triangles and hexagons
So I thought that it might be a good time to share the algorithm I devised in order to create triangles and hexagons in a standard 3-space. I'll share just the one for a triangle since the hexagon is just 6 triangles put together.
In order to do it you will need some variables that are important. This will be written in pseudo code and should be easily adapted to whatever language you wish to translate it to.
In order to do it you will need some variables that are important.
// This variable is the height of an equilateral triangle
float depth = Math.sqrt(3)/2;
//Then we need some counters for the loops
float count = 0;
float countstart = 0;
float countstop = 50; // This can be for however large you wish to draw
// This first one is built in 2 space
for( int y = 0, y < 50, y++) //Note that the target number of loops is the same size as countstop
{
count = countstart;
while( count < countstop) // This is where the X element is drawn
{
Draw an equilateral triangle the uses the following vertices;
Vertex1 ( x = count, y= y * depth);
Vertex2 (x = count + 1, y= y * depth );
Vertex3 (x =count + 0.5, y = (y + 1) * depth );
count = count + 1;
}
countstart = countstart + 0.5;
countstop = countstop - 0.5;
}
The one for creating triblocks in 3 dimensions is fairly similar
//These variable are used once again
float count = 0;
float countstart = 0;
float countstop = 50; // This can be for however large you wish to draw
//There are only slight variations to build blocks in 3-space
// This second one is built in 3 space
for (int z = 0, z < 50 , z++)
{
for( int y = 0, y < 20, y++) //Note that the target number of loops is the same size as countstop
{
count = countstart;
while( count < countstop) // This is where the X element is drawn
{
if( z=0)
{
Only draw a zpos triblock
}
else
{
Draw a zpos triblock
Draw a zneg triblock
}
count = count + 1;
}
}
countstart = countstart + 0.5;
countstop = countstop - 0.5;
}
Please note that the y loop can have as many iteration as you wish since the triangle is in the z and x portions. Again to create a hexagon one would need 6 of these triangle formations.
In order to do it you will need some variables that are important. This will be written in pseudo code and should be easily adapted to whatever language you wish to translate it to.
In order to do it you will need some variables that are important.
// This variable is the height of an equilateral triangle
float depth = Math.sqrt(3)/2;
//Then we need some counters for the loops
float count = 0;
float countstart = 0;
float countstop = 50; // This can be for however large you wish to draw
// This first one is built in 2 space
for( int y = 0, y < 50, y++) //Note that the target number of loops is the same size as countstop
{
count = countstart;
while( count < countstop) // This is where the X element is drawn
{
Draw an equilateral triangle the uses the following vertices;
Vertex1 ( x = count, y= y * depth);
Vertex2 (x = count + 1, y= y * depth );
Vertex3 (x =count + 0.5, y = (y + 1) * depth );
count = count + 1;
}
countstart = countstart + 0.5;
countstop = countstop - 0.5;
}
The one for creating triblocks in 3 dimensions is fairly similar
//These variable are used once again
float count = 0;
float countstart = 0;
float countstop = 50; // This can be for however large you wish to draw
//There are only slight variations to build blocks in 3-space
// This second one is built in 3 space
for (int z = 0, z < 50 , z++)
{
for( int y = 0, y < 20, y++) //Note that the target number of loops is the same size as countstop
{
count = countstart;
while( count < countstop) // This is where the X element is drawn
{
if( z=0)
{
Only draw a zpos triblock
}
else
{
Draw a zpos triblock
Draw a zneg triblock
}
count = count + 1;
}
}
countstart = countstart + 0.5;
countstop = countstop - 0.5;
}
Please note that the y loop can have as many iteration as you wish since the triangle is in the z and x portions. Again to create a hexagon one would need 6 of these triangle formations.
Labels:
algorithm,
apoidgames,
Brift,
game,
game design,
gamedev,
Hexwars,
triangles
21 March, 2013
Beginners Ambition
So I've come across this term in my research and I thought I would talk about it a little. Having spent the last few years of my life pursuing a dream that was far too ambitious for a first project, and also meeting many beginners in the game creation process, I have seen a definite pattern that has emerged. When someone is unfamiliar with what it takes to make a video game they think remaking some large game or creating an MMO is just a matter of using the existing framework and tweaking it a little. What happens afterward is a realization of what a colossal effort it takes, as every question they look up on Google leads to two or more new questions, which when followed lead to yet more questions. Soon a beginner is quite overwhelmed, and that grand game they have thought up becomes an unconquerable beast of a task.
So what advice would I give to someone interested in becoming a game developer. Well one is start small, with learning how to make pong for example. Think of pong as the monster conquerable by a beginning adventurer. It's not that exciting, but given you are just starting out it's where you are and it will give you valuable experience needed for the next level challenge and the challenge after that. Eventually you will be able to recreate games from the 8-bit era like super mario bros. Unfortunately there are no shortcuts if you wish to create something truly unique. If you wish to program a 3D game then you will need to learn matrix math and programming challenges that will really stretch your creative and analytic skill sets. Perhaps one day, hopefully with the help of others going through a similar journey, you will be able to take on that challenge and make your game.
Also I cannot stress enough that making games is a challenge that will require a good education in math, computer science, and depending on what you want to include in your game a wide variety of other subjects. It is not a challenge for the faint of heart, and unlike playing most games you will fail many times before you succeed. I have a great respect for game developers now, and I truly hope that many of the rising generation are able to take on the challenge to become great game developers in the future.
So what advice would I give to someone interested in becoming a game developer. Well one is start small, with learning how to make pong for example. Think of pong as the monster conquerable by a beginning adventurer. It's not that exciting, but given you are just starting out it's where you are and it will give you valuable experience needed for the next level challenge and the challenge after that. Eventually you will be able to recreate games from the 8-bit era like super mario bros. Unfortunately there are no shortcuts if you wish to create something truly unique. If you wish to program a 3D game then you will need to learn matrix math and programming challenges that will really stretch your creative and analytic skill sets. Perhaps one day, hopefully with the help of others going through a similar journey, you will be able to take on that challenge and make your game.
Also I cannot stress enough that making games is a challenge that will require a good education in math, computer science, and depending on what you want to include in your game a wide variety of other subjects. It is not a challenge for the faint of heart, and unlike playing most games you will fail many times before you succeed. I have a great respect for game developers now, and I truly hope that many of the rising generation are able to take on the challenge to become great game developers in the future.
Labels:
Apoid,
beginning programming,
Brift,
game,
game development,
Hexwars
12 February, 2013
The power in WebGl
I recently stumbled upon a pretty amazing demo showing just what can be done with javascript and Webgl. You can check it out at https://developer.mozilla.org/en-US/demos/detail/bananabread . Basically they took a full game engine written in C++ and OpenGL and ported it to javascript and webgl. It's open source, so I will be able to study it out and get a good idea of where I could go to start my own game later on.
Labels:
Apoid,
apoidgames,
Brift,
game,
gamedev,
Hexwars,
javascript,
WebGL
04 January, 2013
Reality Check
I'm coming to the realization yet again that this is no small project that I have undertaken. I recently had a few good discussions with people on Google+ about game making, and here is what one +Robert Mitchell, who has some experience in the game industry, had to say
"The fact is that the level of competition for good game dev gigs has never been higher. And the reward:risk isn't as good as other sectors unless you offset with an obsession about games in the first place. The likes of EA, for instance, has a tiny fraction of a percent hiring rate for applicants to any given job offer made.
Even then, lucking out with stable employment in this field is just like netting a pink winged unicorn that tastes like chocolate bacon."
Also
"The fact is that the level of competition for good game dev gigs has never been higher. And the reward:risk isn't as good as other sectors unless you offset with an obsession about games in the first place. The likes of EA, for instance, has a tiny fraction of a percent hiring rate for applicants to any given job offer made.
Even then, lucking out with stable employment in this field is just like netting a pink winged unicorn that tastes like chocolate bacon."
Also
"But again, if you find yourself awake at night thinking about how the latest games you played could be improved - and not just from the addition of a new character - and or find yourself in deep thought about the emergent properties found in the interaction of systems around you. Or if you enjoy reading game theory papers talking about conflict and cooperation and Monty Hall's three door game makes obvious sense to you and you don't mind the years it might take to fully pivot over... Game development is incredibly rewarding, IF and ONLY IF you have the love of the craft... because otherwise, this industry will devour your soul and leave you a grumpy, sour mess. I've seen it happen and almost always to good people who just wanted a stable, straight forward job."
I've given a lot of thought to his comments, and the cold hard reality is that I will have to put the needs of my family first and foremost. I have also come to realize that I am not passionate about making games in general, rather I am passionate about making a game that I think I would enjoy playing. I probably won't be able to get the resources to make this particular game as it is so ambitious. I do plan on continuing my education and finishing my master's degree, and I'll find out how much I can get done before that period of my life is finished. I might end up doing a thesis as opposed to a project, but I still have a long time before I have to make that choice. To any aspiring game developers who may be reading this, I recommend learning as much as you can as early as you can. Trying to learn all of this in my mid 30's has been quite tiring.
10 December, 2012
Firefall review
So I recently had the opportunity to try out Firefall and I must say that for a free to play game it was very impressive. I liked the ability to swap out battleframes, which is very similar to the idea I have for switching roles. There was a definite PvE (player vs environment) push, with PvP(player vs player) being almost an afterthought. The PvP matches were basically 5v5 team deathmatch style with the possibility of 10 v 10 on different maps, but there is not the persistent open world pvp I was kind of hoping would be there. There are a kind of simple tower defense type situation where you and your squad defend a thumper (a type of mining device) from wave after wave of overgrown bugs and other mutated wildlife, which provides a challenge of it's own. Finally there is the Chosen, who are evil incarnate NPC (non player characters) who come to take over watchtowers and generally make life difficult. Some of them are quite powerful, leaving me roasted a many a time as I tend to walk around alone. Even so I was able to take out dozens of them single handed, and I'm sure that even with improved AI players will eventually figure out way's to kill them easily.
As for what I would hope to see, I would say that player controlled chosen would make the game very interesting. That way large scale open world pvp could be realized, though that also introduces some problems as to how would tech and other items work. That and if you have the "good" side and the "bad" side developers often will unconsciously favor the good side.
As for what I would hope to see, I would say that player controlled chosen would make the game very interesting. That way large scale open world pvp could be realized, though that also introduces some problems as to how would tech and other items work. That and if you have the "good" side and the "bad" side developers often will unconsciously favor the good side.
Labels:
Apoid,
apoidgames,
Brift,
Firefall,
game,
game design,
game development,
gamedev,
Hexwars,
review
Product vs Service
As I continue to study the art of game creation I came across an interesting and thought provoking concept, that we are moving away from games as a product to games as a service. I certainly would say that I hope to create a system for the latter, but I suppose I should explain the differences before I go into that.
In the past games were required to be in a complete state (meaning completely coded, put into a package to be sold in retail outlets, etc..) before they got to the consumer. Often once it had shipped the developers would no longer have anything to do with the product other than wait for one of two outcomes, success and the opportunity to make more games or rejection by the masses which usually meant the end of said game development company. With every "product" shipped there was a definite gamble, and since publishers who were funding the product from the inception and who also are very concerned with making a profit were pretty much in control, any failure to produce said profit was a death sentence to any game developer who didn't perform well.
Now switch to games as a service. MMO's are a great example of how this mindset works. A game is created and then costumers are brought in before the game is complete (usually in beta) and they give feedback as to what they would like to see in the game as a finished product. The thing is that the game is never really finished, as things keep getting added on. Costumers also don't do the one time purchase as in the other model, rather they pay on an ongoing basis either through subscription costs or via micro-transactions. The game developer and the consumer then have this continual relationship where there are feedback loops and opportunities for creating an experience that players enjoy and game developers are happy to provide. It also means that game developers are able to work with a product long after it has reached the hands of the consumer.
I think the second option has a better chance of creating communities around a game, and also gives developers a chance to polish and work out games to become the very best that they can. I look forward to the change in paradigms that is already occurring.
In the past games were required to be in a complete state (meaning completely coded, put into a package to be sold in retail outlets, etc..) before they got to the consumer. Often once it had shipped the developers would no longer have anything to do with the product other than wait for one of two outcomes, success and the opportunity to make more games or rejection by the masses which usually meant the end of said game development company. With every "product" shipped there was a definite gamble, and since publishers who were funding the product from the inception and who also are very concerned with making a profit were pretty much in control, any failure to produce said profit was a death sentence to any game developer who didn't perform well.
Now switch to games as a service. MMO's are a great example of how this mindset works. A game is created and then costumers are brought in before the game is complete (usually in beta) and they give feedback as to what they would like to see in the game as a finished product. The thing is that the game is never really finished, as things keep getting added on. Costumers also don't do the one time purchase as in the other model, rather they pay on an ongoing basis either through subscription costs or via micro-transactions. The game developer and the consumer then have this continual relationship where there are feedback loops and opportunities for creating an experience that players enjoy and game developers are happy to provide. It also means that game developers are able to work with a product long after it has reached the hands of the consumer.
I think the second option has a better chance of creating communities around a game, and also gives developers a chance to polish and work out games to become the very best that they can. I look forward to the change in paradigms that is already occurring.
Labels:
Apoid,
apoidgames,
Brift,
game,
game design,
game development,
gamedev,
Hexwars
10 November, 2012
What I'm learning about programming
Ok I know I haven't posted for a while, but that is mainly because I haven't done a whole lot as far as this game is concerned. School again is sucking up lots of time. I am having what I think is an important understanding of something though.
Programming ,indeed all of computer science, is all about tackling problems and learning to teach oneself in order to tackle ever increasingly difficult problems.
I think that is why when I look at jobs in the world of gaming they always have the requirement of having shipped at least one title. That is because an appropriate candidate will have proven that faced with problems they did not give up and run away, rather they figured out a way to make it work. In my college experience I have railed at how it seems that I must teach myself, yet I think that is the actual goal of studying computer science and programming, to develop in students the ability to self teach and problem solve without the assistance of someone else. Higher order thinking skills are really hard to pick up though, which is why when someone is able to show that yes they did have problems that were hard and yes they did solve them even when it wasn't fun that is says something about that person.
Which is why I need to kick myself in the rear and get to work overcoming some of these obstacles I keep running into. I also need to remember that I can learn it little by little, step by step. So now back to getting my homework done.
Programming ,indeed all of computer science, is all about tackling problems and learning to teach oneself in order to tackle ever increasingly difficult problems.
I think that is why when I look at jobs in the world of gaming they always have the requirement of having shipped at least one title. That is because an appropriate candidate will have proven that faced with problems they did not give up and run away, rather they figured out a way to make it work. In my college experience I have railed at how it seems that I must teach myself, yet I think that is the actual goal of studying computer science and programming, to develop in students the ability to self teach and problem solve without the assistance of someone else. Higher order thinking skills are really hard to pick up though, which is why when someone is able to show that yes they did have problems that were hard and yes they did solve them even when it wasn't fun that is says something about that person.
Which is why I need to kick myself in the rear and get to work overcoming some of these obstacles I keep running into. I also need to remember that I can learn it little by little, step by step. So now back to getting my homework done.
Labels:
Apoid,
apoidgames,
Brift,
game programming,
Hexwars,
programming
08 October, 2012
Github
In the vein of being completely and totally open about how I am moving forward with this project I have created a Github account and posted the code I have so far. I am still trying to get a grasp on OpenGL and GLUT which is why I haven't done a whole lot recently. Also I am struggling with how to represent the triblocks in a way that is not resource intensive.
Part of my problem is that for each triblock there are 5 neighboring triblock areas. I need a way for the triblocks to be aware if each of the neighboring areas are either filled or not. If they are filled then the triblock will not display the neighboring face, and if not then the face will be displayed. I might have to make a huge set of pointers, which I am not looking forward to as I still haven't quite got the hang of them.
Anyway if you want to stop by and check out my code just look for Brift or Hexwars on github.
Part of my problem is that for each triblock there are 5 neighboring triblock areas. I need a way for the triblocks to be aware if each of the neighboring areas are either filled or not. If they are filled then the triblock will not display the neighboring face, and if not then the face will be displayed. I might have to make a huge set of pointers, which I am not looking forward to as I still haven't quite got the hang of them.
Anyway if you want to stop by and check out my code just look for Brift or Hexwars on github.
Labels:
Apoid,
Apoidea,
apoidgames,
Brift,
game,
game development,
Github,
Hexwars,
programming
06 October, 2012
Single Hexfield battle
Because the game will need to be constructed in phases and the first proof of concept will need to be a full hexfield I have been mulling over how the game might play out if only 1 hexfield were involved. So the ideas I have are this.
1. The game starts out with a 5/10/15 minute building phase when players can get their base set up. All teams will start out with the exact same resources available via a console. It will be up to members of each team to construct their base as they see fit. Because I one day hope for six factions we'll just start out with 6 separate starting areas, divided up like the picture above.
2. At the end of the build phase the walls come down and the battling can commence. If players are still setting up their base they are now in danger of being attacked. If frozen while carrying a base item they will have to drop it once they get teleported, which means that there is an opportunity for enemy players to capture the item and use it for their own base. This means that there is a good reason to both attack and or defend right from the time those walls come down.
3. The battle will commence until there is only one team standing, Once a team's teleporter is taken down then they will lose the ability to respawn and will remain frozen in place until they either get a new teleporter down or all of their team is frozen, at which point they will be given the option to concede and exit the game.
Teams could be chosen at random or there could be the option of having precreated teams. This format of play will be where beginners will start the game, and it is through demonstrated knowledge of the game mechanics and ability to follow the rules that they can be allowed to play in the big game. It will also be a place where the factions for each color can come in and train new players while recruiting for their faction.
1. The game starts out with a 5/10/15 minute building phase when players can get their base set up. All teams will start out with the exact same resources available via a console. It will be up to members of each team to construct their base as they see fit. Because I one day hope for six factions we'll just start out with 6 separate starting areas, divided up like the picture above.
2. At the end of the build phase the walls come down and the battling can commence. If players are still setting up their base they are now in danger of being attacked. If frozen while carrying a base item they will have to drop it once they get teleported, which means that there is an opportunity for enemy players to capture the item and use it for their own base. This means that there is a good reason to both attack and or defend right from the time those walls come down.
3. The battle will commence until there is only one team standing, Once a team's teleporter is taken down then they will lose the ability to respawn and will remain frozen in place until they either get a new teleporter down or all of their team is frozen, at which point they will be given the option to concede and exit the game.
Teams could be chosen at random or there could be the option of having precreated teams. This format of play will be where beginners will start the game, and it is through demonstrated knowledge of the game mechanics and ability to follow the rules that they can be allowed to play in the big game. It will also be a place where the factions for each color can come in and train new players while recruiting for their faction.
Labels:
Apoidea,
apoidgames,
battle,
Brift,
game,
hexfield,
Hexwars,
Single hexfield
19 June, 2012
Laser pointer function
So I know that I mentioned that I wanted to have a laser pointer function in the past, and this post is to elaborate on exactly how it will work. I think that there will be 2 modes which will be changeable via a right click. The first mode works just like a normal laser pointer in that one will only see the dot at the end. The other mode will be the same as when one fires a laser through smoke or steam and the whole beam is illuminated. This mode will obviously draw more attention, and so players will be able to communicate quickly by essentially pointing something out. It will also alert enemies that you are close. As far as appearance goes I think that it will be just a slight protrusion from the multipurpose handle
Labels:
Apoid,
Apoidea,
Brift,
game,
game design,
Hexwars,
laser,
laser pointer,
Tools,
War Simulation
31 May, 2012
Distress Signals
I have been thinking about what could be done to indicate to other players of one's faction that someone is in distress. So along with the laser pointer idea, I had a thought that distress signals could be sent by pointing their laser pointer directly up. So long that a player is not under anything (like in a cave) and they are using the pointing function (which is a double use for placement of blocks and structures as well as quick communication), then if frozen the beam automatically shoots directly up and an alarm will be triggered if they are close enough to a communications structure( basically within the same hexfield as one). The alarm volume will depend on how many distress calls are being sent at any given time and will be relayed back to the main base. I envision a large map on one of the walls which will indicate distress signals by a radiating hex, the larger the radiation, the more attention grabbing it will be. So basically it would provide a player controlled mechanism to quickly indicate incoming attacks.
Labels:
alarm,
Apoid,
Apoidea,
Brift,
communication,
distress,
Hex wars,
Hexperiment,
Hexwars,
laser,
pointer
01 April, 2012
Mirrors
I had an interesting thought last night. A craft-able item that could be placed is a mirror that allows shots fired by the placing faction to be reflected, yet opposing faction's shots would be absorbed as damage which when it becomes to much will break the mirror. These mirrors could be hacked just as any other structure. There would be both ceiling/floor types and wall types, which could be represented as two different recipes. This will have to wait of course, but will make a nice addition after the basics of the game have been completely developed.
Labels:
Apoidea,
Brift,
crafting,
game,
game design,
Hexwars,
mirror,
recipe,
structures
27 March, 2012
Competitiveness and the desire to be on the winning team
At the heart of player vs player games or pvp as is coined in the industry is the desire to compete. As my children have very convincingly shown me time and again, winning is funner than losing. While many people point out that good sportsmanship is all about enjoying the game regardless of outcome, many of us secretly hope to be the winners. What I have noticed that frequently happens in games is that people know who the good players are and will wait to see which team they join before choosing a team. If all of the good players do this it's what's known as stacking, where there is an imbalance in playing ability on the two teams. What occurs then is hardly a competition, rather it is a massacre. I like to think of myself as a good player in many games that I play, and often I will try to be on the underdogs team so as to even the playing field a bit. What I have noticed is the more that I play a game and become known, that when I join the underdog team that it isn't the underdog team for that long because many "good" players will switch sides as soon as the tide of the competition comes to be against them winning.
I try not to bring up politics very often, but since it is a common area of competition I think it bears a quick look at it. When foreigners are being made familiar with american culture for example, I found it interesting that Americans claim to be the most free country in the world, yet despite having many choices of political parties overwhelmingly there were only two dominant parties. In talking to people about this occurring for such a long time, many people say that they would prefer to vote for one of the smaller parties, except that would just mean throwing away their vote. Thus they feel obligated to choose instead from the two parties who clearly have a chance of "winning". Some people were not even aware that they were allowed to choose other parties, or even that other parties indeed existed beyond the two powerhouses. I like to look at this as people wish to be affiliated with a winning establishment, even if that establishment may not share the same ideals as said people, the "choosing the lesser of two evils" if you will.
In games the drive to win often leads people to extreme and unethical behaviors, such as cheating, hacking, stacking teams or sides, spying on their competitors, bribery, the list goes on an on. Often systems are put into place to try and stop these unwanted behaviors, yet the desire to win will often lead people to seek out loopholes or other ways of getting an advantage. The problem is once a system is compromised and people recognize the inherent unfairness the advantages the cheaters have, then many people are driven to leave the system if they have a choice, or if not they are forced to cheat themselves in order to remain competitive.
So to bring this back to my game, I really want to see this succeed and in order for that to happen it needs to be able to stop such behaviors from happening. I've seen too many games where the players who are willing to play fair and follow the rules are driven away by cheaters and hacks. Some areas that I am a little concerned in would be
1. How do you keep factions relatively even as far as number of skilled players on each side?
2. What happens when the majority of a faction decides to stop playing making things unequal?
3. How do we limit hacking of the client, and in what ways do we detect said hacking?
4. What if someone stops playing and gives their account to a friend who is on an opposing faction? How do we detect this and stop it, or does it need to be stopped?
5. What can be done to make sure the game stays fun for everyone?
Any help with how to tackle these questions would be greatly appreciated.
I try not to bring up politics very often, but since it is a common area of competition I think it bears a quick look at it. When foreigners are being made familiar with american culture for example, I found it interesting that Americans claim to be the most free country in the world, yet despite having many choices of political parties overwhelmingly there were only two dominant parties. In talking to people about this occurring for such a long time, many people say that they would prefer to vote for one of the smaller parties, except that would just mean throwing away their vote. Thus they feel obligated to choose instead from the two parties who clearly have a chance of "winning". Some people were not even aware that they were allowed to choose other parties, or even that other parties indeed existed beyond the two powerhouses. I like to look at this as people wish to be affiliated with a winning establishment, even if that establishment may not share the same ideals as said people, the "choosing the lesser of two evils" if you will.
In games the drive to win often leads people to extreme and unethical behaviors, such as cheating, hacking, stacking teams or sides, spying on their competitors, bribery, the list goes on an on. Often systems are put into place to try and stop these unwanted behaviors, yet the desire to win will often lead people to seek out loopholes or other ways of getting an advantage. The problem is once a system is compromised and people recognize the inherent unfairness the advantages the cheaters have, then many people are driven to leave the system if they have a choice, or if not they are forced to cheat themselves in order to remain competitive.
So to bring this back to my game, I really want to see this succeed and in order for that to happen it needs to be able to stop such behaviors from happening. I've seen too many games where the players who are willing to play fair and follow the rules are driven away by cheaters and hacks. Some areas that I am a little concerned in would be
1. How do you keep factions relatively even as far as number of skilled players on each side?
2. What happens when the majority of a faction decides to stop playing making things unequal?
3. How do we limit hacking of the client, and in what ways do we detect said hacking?
4. What if someone stops playing and gives their account to a friend who is on an opposing faction? How do we detect this and stop it, or does it need to be stopped?
5. What can be done to make sure the game stays fun for everyone?
Any help with how to tackle these questions would be greatly appreciated.
22 March, 2012
Google Summer of Code
School has been going fairly well, though there are some things that I have felt could have gone better. Anyway while thinking about how I can get better at coding this summer I ran across this excellent program known as Google summer of code, which puts worthy opensource programs in touch with college students (like me) so that improvements/additions to said open source programs can be made. I feel a little intimidated to be sure, but I will need to practice coding in order to get better, and what better way to do that then working on an opensource project. I will still be working as tech support for my school's smart classrooms this summer, but I think that I probably won't be allowed to work much more than part time. This will be a lot of work, but I think that it would be incredibly rewarding and fulfilling at the same time. I have been thinking that opensource might be the better way to go with all of this anyway, and while I realize that I won't be able to make a lot of money ( if any at all) I feel that being able to share my work so other can build on it is important.
I have realized lately that I have been making a shift from gamer to game developer. Part of that is the realization of what it takes to make a game of any size. I now have a much greater respect and appreciation for all of the game developers out there. I know that many hours of hard work will be required for the smallest part of what I want to do, and that people will most likely be very critical and/or demanding of my work as soon as I get it out and available for use. I'm not so much worried about that, it's just that I would like to play this game in a multiplayer setting, and if no one is willing to play the game that will be really hard to do. The nice thing is that I can also see from both perspectives now. I still understand the frustration of the gamer community at not getting new content at a rate that they desire, yet I understand the plight of the developers who work so very hard just to have people turn around and say meh. It's an interesting turning point, and I hope I can remember to feel empathy for both sides.
I have realized lately that I have been making a shift from gamer to game developer. Part of that is the realization of what it takes to make a game of any size. I now have a much greater respect and appreciation for all of the game developers out there. I know that many hours of hard work will be required for the smallest part of what I want to do, and that people will most likely be very critical and/or demanding of my work as soon as I get it out and available for use. I'm not so much worried about that, it's just that I would like to play this game in a multiplayer setting, and if no one is willing to play the game that will be really hard to do. The nice thing is that I can also see from both perspectives now. I still understand the frustration of the gamer community at not getting new content at a rate that they desire, yet I understand the plight of the developers who work so very hard just to have people turn around and say meh. It's an interesting turning point, and I hope I can remember to feel empathy for both sides.
Subscribe to:
Posts (Atom)

