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.
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.
10 December, 2012
Firefall review
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
15 November, 2012
Marching Cubes
As part of my algorithms class I need to present an algorithm that I have looked into and analyzed. For this assignment I chose the marching cube algorithm. It's a nice straightforward algorithm that was designed to display 3d volumetric information and it was originally presented in 1987. Anyway I am learning quite a bit about voxels through this, and apparently this algorithm or something very similar is commonly used in place of height maps for creating the base landscape in many games. The reason why is that it make negative spaces like caves and overhangs possible.
So a quick explanation is that you take a large set of cubes put into a 3d array like 512x512x512. Then going through each of the smaller cubes you determine whether one of the 8 corners is either inside or outside of your volume. The program then repeat this for all of the remaining cubes keeping track of which ones are inside and which ones are outside and drawing triangles based on the intersections. In the end you have a rough 3d representation of the volume being measured.
Now I need to go and write a 20 page paper on this, and I find myself wondering what fillers to use to stretch this out. Wish me luck.
So a quick explanation is that you take a large set of cubes put into a 3d array like 512x512x512. Then going through each of the smaller cubes you determine whether one of the 8 corners is either inside or outside of your volume. The program then repeat this for all of the remaining cubes keeping track of which ones are inside and which ones are outside and drawing triangles based on the intersections. In the end you have a rough 3d representation of the volume being measured.
Now I need to go and write a 20 page paper on this, and I find myself wondering what fillers to use to stretch this out. Wish me luck.
Labels:
Apoid,
Apoidea,
apoidgames,
Brift,
game,
game design,
gamedev,
Hex wars
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
29 October, 2012
Problem with trying to use Voxels and triangles
So I've encountered a little bit of a problem when it comes to using the voxel mindset with triblocks. The problem is that I need each and every triblock to have it's own unique ID, yet if I try to use a single point for each triblock only half of the triblocks would be represented. Voxel engines are very efficient because each voxel is basically one point which is either filled or not filled (it is possible to attach other information to them, but that isn't the problem as much.) I suppose that one thing I could do is for any given point there would be the up triblock and the down triblock. So the final title for the triblock would be something like x200y46z300up. Ok I'm glad we had this chat as I no longer have a problem.
My First Screenshot
So I realize this has been a long time coming, but I am finally able to post a screen shot showing I am indeed making progress. I know it may not look like much now, but the foundation for my game is laid out here. This is a hexagonal room with the triangles on top and bottom and squares on the sides, meaning that it is possible to program. I still have a long way to go, but it feels good to have something up. In the program I have a working first person camera with WASD motion going on and the mouse being used to look around. Thanks to lighthouse3d.com for a good tutorial to get me started. If anyone wants the executable just let me know.
Labels:
Apoid,
apoidgames,
Brift,
game,
game design,
Hex wars,
screen shot
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
07 September, 2012
Kill Stealing
An interesting source of competition found in League of Legends and I'm sure in other game is who gets credit for a kill. In the game if a player on team A is the last one to damage another player on the opposing team B before that player dies, then the player on team A is rewarded with more in game gold. If a second player on team A is also damaging the player but does not get the killing strike, then they will get credit as assisting the first player, yet no additional gold is given. The idea of being rewarded for successfully dispatching an opponent is something put into games in order to encourage player vs player (or PvP) interactions, but one side effect of this is competition among players on the same team for kills. The side effect in league of legends is that players become angry at someone who over and over again swoops in last second to land a killing blow and takes the reward for them self, which leads to that player becoming stronger and better equipped, which leads to them getting even more kills because of an imbalance in team strength. Luckily the effect is not long term as games rarely last longer than 45 minutes, but in games like and Aion where the world is persistent and having better armor drastically increases ones abilities in game it becomes a serious problem.
So the question for me is how will I address this in Hexwars. First of all I don't think keeping statistics on the form of something like a leader board is a good idea. I may have personal stats that each player can see how well they have done, and game stats at the end of a round. There is the natural reward of stopping enemy players from harassing your side, and depriving them of needed resources, but these rewards are faction based rather than individual based. So instead of angry players refusing to work together, there will be willing teammates who will work to support one another.
So the question for me is how will I address this in Hexwars. First of all I don't think keeping statistics on the form of something like a leader board is a good idea. I may have personal stats that each player can see how well they have done, and game stats at the end of a round. There is the natural reward of stopping enemy players from harassing your side, and depriving them of needed resources, but these rewards are faction based rather than individual based. So instead of angry players refusing to work together, there will be willing teammates who will work to support one another.
20 August, 2012
Insects in game
So going along with the theme that insects are controlling this whole experiment I am considering inserting some hive type insects as NPC (non player characters) to mix things up a bit. This of course will be added much later as I want to get the basics nailed down first. The reason I will be adding this is that I am sure I will have to program some AI in order to complete my masters degree. So the idea I have is this.
1. Wasps nest
This will be the most difficult enemy as it will be flying and it will also have both distance and melee attacks. If a player comes too close to the nest they will get triggered and all come out of the nest at the same time to attack. I'd like there to be enough enemies that spawn so as to overwhelm a single player or even a small group ( probably a pod size) meaning that taking one down is a serious event requiring a lot of coordination. Of course taking one down would also give a large amount of rewards in the form of nest material which could then be incorporated into weaponry or vehicles.
2. Bee's nest
This type is going to be in the form of suicide bomber type fighting, as the AI will move quickly to the player and then explode. Again it will spawn enough enemies to protect against a fairly large attack, with a faster respawn rate compared to the other nest types.
3. Ant's nest/hill
These will be ground based insects that will close in quickly, then attach themselves to a player doing constant damage until the player is frozen, then they will move on to the next player and so on.
For all three insect types the only class that can outrun them will be the scout class. Builder's will be necessary to harvest the nest material in all three cases, and the firepower of the soldier class will be absolutely necessary in taking down a nest. Luckily hive algorithms are fairly common so implementation shouldn't be all too difficult, though I haven't yet started the programming yet so I guess I'll find out eventually.
When a nest is not active I'll probably have a few of the insects outside doing simple patrolling. If an insect is attacked it will make it's way to the nest and set off the alarm if it is not taken completely out before then. Once in alarm state the various swarms will attack any players in a much wider area than the normal radius, meaning that if a group of players sets off this alarm they had better get away fast or be prepared to fight the whole swarm.
1. Wasps nest
This will be the most difficult enemy as it will be flying and it will also have both distance and melee attacks. If a player comes too close to the nest they will get triggered and all come out of the nest at the same time to attack. I'd like there to be enough enemies that spawn so as to overwhelm a single player or even a small group ( probably a pod size) meaning that taking one down is a serious event requiring a lot of coordination. Of course taking one down would also give a large amount of rewards in the form of nest material which could then be incorporated into weaponry or vehicles.
2. Bee's nest
This type is going to be in the form of suicide bomber type fighting, as the AI will move quickly to the player and then explode. Again it will spawn enough enemies to protect against a fairly large attack, with a faster respawn rate compared to the other nest types.
3. Ant's nest/hill
These will be ground based insects that will close in quickly, then attach themselves to a player doing constant damage until the player is frozen, then they will move on to the next player and so on.
For all three insect types the only class that can outrun them will be the scout class. Builder's will be necessary to harvest the nest material in all three cases, and the firepower of the soldier class will be absolutely necessary in taking down a nest. Luckily hive algorithms are fairly common so implementation shouldn't be all too difficult, though I haven't yet started the programming yet so I guess I'll find out eventually.
When a nest is not active I'll probably have a few of the insects outside doing simple patrolling. If an insect is attacked it will make it's way to the nest and set off the alarm if it is not taken completely out before then. Once in alarm state the various swarms will attack any players in a much wider area than the normal radius, meaning that if a group of players sets off this alarm they had better get away fast or be prepared to fight the whole swarm.
Labels:
ant,
Apoid,
bee,
Brift,
enemy,
game,
game design,
Hex wars,
Hexperiment,
hive,
nest,
NPC,
wasp
18 August, 2012
Crystal song
I have been working out how I want the energy crystals to work in the game, as they are needed for almost everything that get's created. I want them to be fairly easy to find yet not so easy that finding them becomes so common that they become a non issue. To this end I have come up with a nice workaround. I plan on making the crystals sing.
So I can hear you asking, how are they going to sing? I plan on making a crystal room that will be fairly large and have multiple connections to the surrounding caves. This room will only happen on the mid or lower cave levels, and I will have to work out just how many of them per hexfield will be needed. In the room it will be top to bottom full of crystal blocks. Blocks will be randomly assigned a tone relating to the midi scale, and there will be a constantly repeating "song" that the blocks will play. I have already composed this song, and I will post it to soundcloud probably later on today so you can hear it. Anyway when a player is getting close to the crystal the song will get louder. I plan on having the crystals emit a low level light source, and when singing the light will become slightly stronger. When players interact with any of the crystals in the room the song will stop and only the crystals getting hit by melee weapons will play. This means that players will be able to play little songs if they want to coordinate their efforts. Builders again will be the only ones able to actually get crystals and fill up their bags and anyone else who happens to be with them. After a time the song will start again, leading players back to the crystal room. I plan on using simple MIDI to accomplish the song and the crystal playing by players. Since this will be one of the few places in the game that will have music, it should provide a the needed guidance to players to meet their crystal gathering needs. It will also mean that enemy players will be able to know if there are other players in a crystal room as there will be the player controlled sounds emitting instead of the song.
Labels:
Apoid,
Apoidea,
Brift,
Crystal song,
crystals,
energy,
game,
game design,
Hex wars,
MIDI,
sound
07 August, 2012
Tackling the surface environment
Game environments are particularly challenging, especially when I hope to make them random. I have already talked about the three levels of caves, and how I hope to randomize the cave system to be unique for every hexfield in the game. The part that I am now concentrating on is the surface level from 60 meters to 100 meters. To help illustrate what I plan to do for this I have made a simple diagram.
I can then create a surface that is reflected in triblocks. While it is true that some of the more unique facets of a triangular tessellation will not be reflected in this type of initial setup, players will be able to add blocks to this environment utilizing the full spectrum of possibilities. The height map will need to have area's that are flat where bases can be created as well as guaranteed low areas that could intersect with cave levels. In order to still keep the sense of randomness each area could be taken randomly from one giant height map.
As you can see, a set of equilateral triangles can be skewed to fit the standard square tessellation pattern. This means that I would be able to translate a standard height map to this field. If I divide the surface area of the hexfield like this:
Labels:
Apoid,
Apoidea,
Brift,
environment,
game,
game design,
height map,
Hex wars,
surface
Control systems
I recently tried out another popular title called "League of Legends". It is free to play with micro transactions that allow players to unlock various heroes and looks for said heroes. The first thing that I noticed was the control scheme employed. One does not control ones hero directly, rather one clicks a location where one wants the hero to go and the hero responds accordingly. There are 4 skills per hero which can be activated via keyboard or by clicking on them with the mouse. I found the experience to be more along the control scheme found in RTS (Real Time Strategy) games where one acts as a commander who tells the troops where to go.
Since the majority of the player controls in my game will be based on the standard FPS(first person shooter) control system I'm thinking that when it comes time to market the game I will need to say that it is an MMO FPS game. Yes there is the commander position, but that position and the control scheme when in a commanding ship (which will be more similar to the RTS control scheme) will be a very small portion of the game that many players may not even experience. While commanders also won't be able to control anything directly like in RTS games, they will be able to set waypoints that all under their command or even in the faction can see, they will be able to set a wireframe equivalent of the structures to guide the ground troops, and they will be able to sound alarms in a given hexfield if they find an enemy force is present.
I find that people have spent years developing skill sets in these various schemes, which is why I don't see them going away any time soon
Since the majority of the player controls in my game will be based on the standard FPS(first person shooter) control system I'm thinking that when it comes time to market the game I will need to say that it is an MMO FPS game. Yes there is the commander position, but that position and the control scheme when in a commanding ship (which will be more similar to the RTS control scheme) will be a very small portion of the game that many players may not even experience. While commanders also won't be able to control anything directly like in RTS games, they will be able to set waypoints that all under their command or even in the faction can see, they will be able to set a wireframe equivalent of the structures to guide the ground troops, and they will be able to sound alarms in a given hexfield if they find an enemy force is present.
I find that people have spent years developing skill sets in these various schemes, which is why I don't see them going away any time soon
Labels:
Apoid,
Apoidea,
Brift,
control scheme,
controls,
fps,
game,
game design,
Hex wars,
marketing,
MMO,
rts
07 July, 2012
Simple Games
During the summer my kids have had a lot of free time. Aside from driving me and my wife a little crazy, they have spent a lot of time playing various flash games. Now of course being a fan of video games I have kept all of my old video game systems and video games, so there is no shortage of good high quality games to play. So I'm asking myself why they are favoring these somewhat annoying games online. I think the answer lies in simplicity. They don't have to give a lot of white matter work to understand the objectives of these games, and I just have to say that I am glad I'm not a tron.
I think that Zynga's recent success with similar types of games really shows how this principle is not only popular, but profitable as well. There is a lot of copycats out there though, which makes sense since it is really hard to come up with new kinds of games. I have been impressed by a few the innovations I have seen, but even most of those borrow heavily from various predecessors. In looking at my game design it also borrows heavily from previous game types, which is why I'm so confused why no one has ever made a game like it. Well I'll just have to keep at it.
I think that Zynga's recent success with similar types of games really shows how this principle is not only popular, but profitable as well. There is a lot of copycats out there though, which makes sense since it is really hard to come up with new kinds of games. I have been impressed by a few the innovations I have seen, but even most of those borrow heavily from various predecessors. In looking at my game design it also borrows heavily from previous game types, which is why I'm so confused why no one has ever made a game like it. Well I'll just have to keep at it.
Labels:
Apoid,
Apoidea,
Brift,
game,
game design,
Hex wars,
online games,
simple
28 June, 2012
Maze landscape
So I thought I would jot this idea down while I'm thinking about it. In landscape design I plan on having 3 levels of caves which go from 1-20 meters from the bottom, 21-40, and 41-60 and then a surface level which is from 61 meters up to 100 meters. So one possibility of the surface landscape would be similar to a hedge maze with occasional open areas where bases can be built. While it might be frustrating for some, I think that others might really enjoy trying to navigate such a maze. This could be in an area where there are higher quality materials, just as an additional challenge to get them back to base.
27 June, 2012
Intellectual property
So somewhat related to what I post here on this blog is a question of intellectual property. I recently listened to an NPR interview entitled "When Patents Attack", and I realize now that virtually anything I do in regards to this game will technically encroach on someones patents. The short version is that there are companies out there that hoard large amounts of patents, and then they do the equivalent of a mafia shakedown saying that they will sue unless you pay large amounts in licensing fees. These companies do not use the patents, indeed many of the companies don't even have employees and probably consist of the lawyers doing the litigation. It's clear to me that intellectual property laws need to be rewritten. The thing that scares me the most is that if I am even moderately successful in this endeavor it is possible that one of these companies will come after me. After all this game concept borrows heavily from many other games.
Also as you can see by having this blog public and sharing all of my ideas openly anyone could conceivably take all of these idea and make this game. I personally wouldn't have a problem with that, and all I request is that you make me a part of it. That being said though I don't see it really happening any time soon.
For those of you who are willing to take the time, please take some time to let the government know why and possibly how intellectual property law should be changed at Regulations.gov before July 25, 2012. Let's make it so the little guy has a chance of making it too.
Also as you can see by having this blog public and sharing all of my ideas openly anyone could conceivably take all of these idea and make this game. I personally wouldn't have a problem with that, and all I request is that you make me a part of it. That being said though I don't see it really happening any time soon.
For those of you who are willing to take the time, please take some time to let the government know why and possibly how intellectual property law should be changed at Regulations.gov before July 25, 2012. Let's make it so the little guy has a chance of making it too.
Labels:
Apoid,
Apoidea,
Brift,
copyright,
game,
game design,
Hex wars,
Intellectual Property,
license,
patents
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
14 June, 2012
Idea for my Masters Project
So as many of you have seen over the course of the posts I have created over the last year, this project is not a small undertaking. I have researched a lot of different game engines (set's of programming that one can build a game upon) such as Unity3D, Unreal, Cry Engine, C4 Engine, and a few open source ones as well. The problem is that each one of these tools has their own little quirks that must be learned in order to make a game with them. So the thought that I had was why not propose to the college the possibility of creating/finding an open source project that students could work on and add to for college credit. This has been done successfully at other colleges with programs like UCOSP, and this is apparently a rousing success. It gives students an opportunity to work on a real life project very similar to what they will experience in a job after college. I find that combining teaching and as close to real life experience is one of the optimal learning environments for students, and it will give them a taste of what it will be like once they graduate.
Proposing this will need to be put into a well organized plan of action so that I can show the powers that be that not only will this be beneficial to students, but it will enhance the learning experience of the University and therefore make it more successful. So along with making a game, I think that something I will attempt to work on is organizing and setting up such a program at UCCS.
Proposing this will need to be put into a well organized plan of action so that I can show the powers that be that not only will this be beneficial to students, but it will enhance the learning experience of the University and therefore make it more successful. So along with making a game, I think that something I will attempt to work on is organizing and setting up such a program at UCCS.
Labels:
Apoid,
Apoidea,
Brift,
college,
game,
game design,
game engine,
game programming,
programming,
real life experience,
UCCS
07 June, 2012
Grouping UI
So I have been working out how to do grouping as that will be very important. So this is what I have worked up so far. The first grouping is called a pod and will look like this for the three colors.
Basically there is 7 players involved with 1 player acting as lead. I want the colors to reflect the amount of health that a player has, so if say half your group is frozen and 2 others are injured it would look like this.
The next size will be called a drit and will be comprised of 3 pods with an additional leader. This one I will do in just green.
This takes 3 pods and puts them together with another leader for a total of 22 players involved. The closer one is to the center the higher they are up in the chain of command. I'll have to tweak the colors so it is clearer as to who is a higher rank, so for right now if they are brighter they are a leader of some sort. I want to make it so only the leaders will see this formation, so basically the 4 players in the middle will see everyone, all of the other participants will only see the pod that they are a part of. The last formation will be called a plat and will look like this which has been depicted in blue this time.
Again this takes 3 drits and attaches them to an additional leader for a total of 67 players. Again only the four players in the middle will see this formation, which is the plat leader and the 3 drit leaders. The pod leaders will only see the drit formation above, and all other participants still only see the pod that they are in. Commanders would then have a special interface allowing them to see all of these formations in a given hexfield, or if they are in the main base everywhere in the game field. Players will be able to identify group members by special icons or different colored text over the heads of group members.
Basically there is 7 players involved with 1 player acting as lead. I want the colors to reflect the amount of health that a player has, so if say half your group is frozen and 2 others are injured it would look like this.
The next size will be called a drit and will be comprised of 3 pods with an additional leader. This one I will do in just green.
This takes 3 pods and puts them together with another leader for a total of 22 players involved. The closer one is to the center the higher they are up in the chain of command. I'll have to tweak the colors so it is clearer as to who is a higher rank, so for right now if they are brighter they are a leader of some sort. I want to make it so only the leaders will see this formation, so basically the 4 players in the middle will see everyone, all of the other participants will only see the pod that they are a part of. The last formation will be called a plat and will look like this which has been depicted in blue this time.
Again this takes 3 drits and attaches them to an additional leader for a total of 67 players. Again only the four players in the middle will see this formation, which is the plat leader and the 3 drit leaders. The pod leaders will only see the drit formation above, and all other participants still only see the pod that they are in. Commanders would then have a special interface allowing them to see all of these formations in a given hexfield, or if they are in the main base everywhere in the game field. Players will be able to identify group members by special icons or different colored text over the heads of group members.
Labels:
Apoid,
Apoidea,
Brift,
command,
drit,
groups,
Hex wars,
Hexperiment,
plat,
pod,
UI,
user interface
Game Networking
I have been reading up on what is necessary to do game networking, and yes there is a lot that goes into it. In reading about the history of game networking I found that the evolution has changed based on the technology available at the time (you can read more about it here). One interesting thing that I feel bears looking back into is what is known as a pure server/client set up. Basically the game will exist on the server only, and clients act as a dumb terminal that only accepts inputs and displays game output. I have already said that I would like this game to go on Onlive, and since the Onlive system essentially uses this concept already it would be very simple to take it one step further. This means that there would only be one game being rendered, with players logging into this game and seeing it from their viewpoint. It would be the same experience as playing on a LAN, which is something Onlive touts as being one of it's strengths.
So long story short, I will probably set up the game to run on this pure server paradigm. Also I looked into the profit share on Onlive and it is a 60/40 split, which is a little higher than some of the other systems, but is understandable as they have server upkeep and bandwidth costs. My goal would be to make it into the playpack, but we'll have to see how things go.
So long story short, I will probably set up the game to run on this pure server paradigm. Also I looked into the profit share on Onlive and it is a 60/40 split, which is a little higher than some of the other systems, but is understandable as they have server upkeep and bandwidth costs. My goal would be to make it into the playpack, but we'll have to see how things go.
Labels:
Apoid,
Apoidea,
Brift,
game,
game design,
Hex wars,
Hexperiment,
network,
networking,
Onlive,
pure server
05 June, 2012
The Timeline
I was considering going back and editing older posts to reflect some changes in ideas that I have, but I have reconsidered since I would prefer that this blog outline the whole process and evolution of this game from beginning to end. That being said there may be some repeat posts coming up as I need to update certain aspects. The changes won't be particularly large, rather a refinement of previously discussed concepts.
As far as where I am in the process now, I am having to go back and relearn Blender after taking a break from it while in school. I'm finding that I understand quite a bit more about haw the program works now that I have taken linear algebra. I'm also reading Mathematics for 3D Game Programming & Computer Graphics and I'm starting into OpenGL. I still have a lot to learn, and keeping up with all possible technologies is proving to be an overwhelming challenge, so I'm going to work to keep it as simple as I can at this point.
As far as where I am in the process now, I am having to go back and relearn Blender after taking a break from it while in school. I'm finding that I understand quite a bit more about haw the program works now that I have taken linear algebra. I'm also reading Mathematics for 3D Game Programming & Computer Graphics and I'm starting into OpenGL. I still have a lot to learn, and keeping up with all possible technologies is proving to be an overwhelming challenge, so I'm going to work to keep it as simple as I can at this point.
Labels:
Apoid,
Apoidea,
Brift,
fps,
game,
game design,
Hex wars,
Hexperiment,
rts,
strategy
31 May, 2012
Auto Turret Behavior
So I have talked about turrets in the past, and in looking through my past posts I realized I didn't have anything written down about them. The recipe for making one will include at least 1 energy crystal, crafted metal pieces that will include enough for the dimensions of the turret, which will be 12 triblocks, and possibly something else I haven't determined yet. They will probably look a little like the Daleks from Dr. Who or the laser towers from Zelda with a floating globe that indicates . When crafted I want to give the creator the option of the scanning range in sets of 45 degrees. So for example they could set it to scan a 90 degree angle, or they could set it to 360 if they wanted, though it would be less effective as it would take longer to get back to a given point. Also the larger the scan field, the less radial distance the scan will cover
When attacked the auto turret will automatically fire a shot directly back to where it was shot from, and then it will scan in a 45 degree angle the area from which the shot was fired for approximately 5 seconds. The change of scanning also increases total distance of possible scanning to the maximum while it searches, but once it resumes it's normal scan the distance will go back to the original amount.
I want these towers to shoot a constant stream of soldier level weapon fire once locked on a target. A frontal assault on one is just not possible unless a team of least 15 soldiers are all attacking it at once, but I do hope to have a relatively dumb AI so smart players can defeat them if they work it right. All turrets will have the ability to fire in 360 degrees as well as directly up and mostly down so getting around behind one is not a guaranteed destruction.
One other thing I will consider is that if a player near a turret does their laser pointer in a specific direction, the turret will briefly scan that area more thoroughly. This could possibly be a problem though as spies could intentionally point a turret away while enemy players pass through an area, so I'll probably have to set a timer on it and a limit to how often a player could "direct" the turrets attention.
When attacked the auto turret will automatically fire a shot directly back to where it was shot from, and then it will scan in a 45 degree angle the area from which the shot was fired for approximately 5 seconds. The change of scanning also increases total distance of possible scanning to the maximum while it searches, but once it resumes it's normal scan the distance will go back to the original amount.
I want these towers to shoot a constant stream of soldier level weapon fire once locked on a target. A frontal assault on one is just not possible unless a team of least 15 soldiers are all attacking it at once, but I do hope to have a relatively dumb AI so smart players can defeat them if they work it right. All turrets will have the ability to fire in 360 degrees as well as directly up and mostly down so getting around behind one is not a guaranteed destruction.
One other thing I will consider is that if a player near a turret does their laser pointer in a specific direction, the turret will briefly scan that area more thoroughly. This could possibly be a problem though as spies could intentionally point a turret away while enemy players pass through an area, so I'll probably have to set a timer on it and a limit to how often a player could "direct" the turrets attention.
Labels:
AI,
Apoid,
Apoidea,
Autoturret,
Brift,
Hex wars,
Hexperiment,
turret
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 May, 2012
Google Developers Blog: Google BigQuery brings Big Data analytics to all b...
Google Developers Blog: Google BigQuery brings Big Data analytics to all b...: By Ju-kay Kwek, Product Manager, BigQuery BigQuery enables businesses and developers to gain real-time business insights from massive am...
This could prove to be very useful in the future. So I thought I would link it here. It's pretty boring behind the scenes stuff that has to happen.
This could prove to be very useful in the future. So I thought I would link it here. It's pretty boring behind the scenes stuff that has to happen.
Semester is almost done and Headgear
Ok I know that I have been rather quiet on this site for some time now. The nice thing is that my semester is almost done. I will have completed all of the prerequisites for grad school, and now I am just waiting to see if I will be accepted into the program or not. Even if I am not accepted I have already learned a ton and I have a good springboard for moving forward with this project. I will be focusing a lot more over the summer, so expect a lot more in the way of posts, though no guarantees of course.
So one idea I have had was to somewhat copy other FPS games in introducing purely aesthetic headgear for personalization. In this game I plan on a standard headgear being the antennae, and so at first it could be different configurations of antennae. If the game proves to be successful, then later on I will be able to commission an artist to make some better looking head items. This will have to wait until a game model is put together of course. This will also be another way for the game to get income and/or promote the game.
Labels:
Apoid,
Apoidea,
Brift,
game,
game design,
Hex wars,
masters,
programming,
school
23 April, 2012
The Troll Server
So I have been thinking a bit about what can be done to make sure people behave in this game as I want it to be family friendly, to the point where a 6 year old watching it won't pick up new and unwanted vocabulary, and also so that a parent watching the game over a teenagers shoulder won't see how someone in world chat is talking in depth about their latest adult experience. So an idea that I have come up with is a
Troll Server
That's right, a server where there are basically no rules, no censoring, just be as much of an offensive "pick and insert your term here" as you wish. Now if someone does something worthy of getting sent to such a place and "didn't mean it", then they will have to show real remorse in some fashion to be able to return to the "civil" servers.
What this accomplishes is a way for all types of players to be able to play the game as they wish, and they can be around the type of people that they wish to be around. Banning from playing doesn't really work, especially since they may be paying customers who we don't wish to alienate, and trolls often pride themselves on the number of times they are banned anyway. Of course if people willingly wish to play in this server they will be allowed, since that will make it all the easier to police them. It will just have to have a disclaimer before players enter it.
Players could then decide as a collective as to what behaviors constitute a sentence of going to the Troll server. I ran it by a friend (Columba from Aion, Israphel Server) who is a self proclaimed professional troll and he loved the idea. I think it could solve a lot of problems if other games were to adopt a similar type of system. Now of course if someone has a complaint of some sort, all that has to be said is "Look, your in the Troll server. If you don't like it, show us you can behave so you can be on a normal server". It could have a 3 strike system, where after the third strike they have sealed their fate of ever not playing on a troll server. That should keep a lot of people happy in multiple ways.
Troll Server
That's right, a server where there are basically no rules, no censoring, just be as much of an offensive "pick and insert your term here" as you wish. Now if someone does something worthy of getting sent to such a place and "didn't mean it", then they will have to show real remorse in some fashion to be able to return to the "civil" servers.
What this accomplishes is a way for all types of players to be able to play the game as they wish, and they can be around the type of people that they wish to be around. Banning from playing doesn't really work, especially since they may be paying customers who we don't wish to alienate, and trolls often pride themselves on the number of times they are banned anyway. Of course if people willingly wish to play in this server they will be allowed, since that will make it all the easier to police them. It will just have to have a disclaimer before players enter it.
Players could then decide as a collective as to what behaviors constitute a sentence of going to the Troll server. I ran it by a friend (Columba from Aion, Israphel Server) who is a self proclaimed professional troll and he loved the idea. I think it could solve a lot of problems if other games were to adopt a similar type of system. Now of course if someone has a complaint of some sort, all that has to be said is "Look, your in the Troll server. If you don't like it, show us you can behave so you can be on a normal server". It could have a 3 strike system, where after the third strike they have sealed their fate of ever not playing on a troll server. That should keep a lot of people happy in multiple ways.
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.
24 March, 2012
Spring Break and Math Stuff
So I have finally come to spring break this semester, though it won't be much of one as I said that I would be available to work in the computer labs (which I anticipate that those labs will be empty). It will be nice to have a little break from new information though.
On the brighter side I finally got to the section of linear algebra that helps me figure out how to do the triangular tessellations that I was hoping to construct the landscape from. Standard Minecraft style games use the standard x = 1, y = 1, z =1 3d coordinate system, which makes a lot of sense since that is by far the easiest way to represent something in 3d. These are known as the unit vectors and are written as x = (1,0,0), y = (0,1,0), and z = (0,0,1). There is a lot more to it, but I won't bore you with the details. For games the screen will represent an x,y plane because well, lets face it, it is really a 2 dimensional space. Even "3d" monitors and TVs are just a combination of 2 2d planes which creates the illusion of 3d.
So taking the height component as the y, I have figured out that y will still remain a good old 1. The x component will need to be .5, but not on every line rather every other line. The z component is the nasty one as it will be the square root of 3 divided by 2 instead of 1. So my plan is to create a constant variable called DEPTH ( constants are supposed in all caps like that) which is equal to the square root of 3 divided by 2. The z can be expressed as a number of DEPTHS, then if there is an even amount of z the x component will be the normal 1, 2 ,3 etc. but if the amount of z is odd, then x will be 1.5, 2.5, 3.5, etc... Now I wish to clarify that this is just for finding the points which are the corners of each triblock.
Now many of you are probably thinking why not copy the cubic approach that everyone else is using, since it equates to much less work. I guess that the answer is that I am just stubborn, that and I don't wan this to be dismissed as yet another Minecraft ripoff ( which may happen anyway, but at least I can claim that it is different).
On the brighter side I finally got to the section of linear algebra that helps me figure out how to do the triangular tessellations that I was hoping to construct the landscape from. Standard Minecraft style games use the standard x = 1, y = 1, z =1 3d coordinate system, which makes a lot of sense since that is by far the easiest way to represent something in 3d. These are known as the unit vectors and are written as x = (1,0,0), y = (0,1,0), and z = (0,0,1). There is a lot more to it, but I won't bore you with the details. For games the screen will represent an x,y plane because well, lets face it, it is really a 2 dimensional space. Even "3d" monitors and TVs are just a combination of 2 2d planes which creates the illusion of 3d.
So taking the height component as the y, I have figured out that y will still remain a good old 1. The x component will need to be .5, but not on every line rather every other line. The z component is the nasty one as it will be the square root of 3 divided by 2 instead of 1. So my plan is to create a constant variable called DEPTH ( constants are supposed in all caps like that) which is equal to the square root of 3 divided by 2. The z can be expressed as a number of DEPTHS, then if there is an even amount of z the x component will be the normal 1, 2 ,3 etc. but if the amount of z is odd, then x will be 1.5, 2.5, 3.5, etc... Now I wish to clarify that this is just for finding the points which are the corners of each triblock.
Now many of you are probably thinking why not copy the cubic approach that everyone else is using, since it equates to much less work. I guess that the answer is that I am just stubborn, that and I don't wan this to be dismissed as yet another Minecraft ripoff ( which may happen anyway, but at least I can claim that it is different).
Labels:
3D,
Apoidea,
Brift,
fps,
game,
game design,
linear algebra,
rts,
triblock
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.
07 March, 2012
Developers vs Publishers
So I have been doing a little research in my spare time between learning linear algebra and coding this semester. Today I read a long and boring article about the process that publishers and developers entering into an agreement to make a game must go through. All I can say is, it is no wonder that the game industry is broken. The short version of what I read goes like this, publishers have money and make contracts with developers so the developers will make a game as a "work for hire", meaning that the publisher gets to "own" the copyright and intellectual property of a game. Because of the size and complexity of making a games developers don't want to have to start from scratch, and so they create a set of "tools" like a gaming engine which they license to publishers so that every time they don't have to start from scratch. The rest of the article explained how either side works to negotiate as much as possible in order to retain as much as they can to maximize profits.
So what does this have to do with me and my game that I want to make. Well I would be considered a developer, an unknown and untested developer at that, which means I will have very little that I can bring to the table when negotiating with a publisher. This means that it would be an especially bad idea for me to do so, even if I could bring an exceptional product to show them, which is probably what it would take for them to even talk to me. So I will focus much more on things like Kickstarter and appeal to the public directly for money, which is also a difficult path but will not leave me with nothing afterward. This is of course after I have made a fair amount of progress, which is slow going while I learn the fundamentals of game design.
So what does this have to do with me and my game that I want to make. Well I would be considered a developer, an unknown and untested developer at that, which means I will have very little that I can bring to the table when negotiating with a publisher. This means that it would be an especially bad idea for me to do so, even if I could bring an exceptional product to show them, which is probably what it would take for them to even talk to me. So I will focus much more on things like Kickstarter and appeal to the public directly for money, which is also a difficult path but will not leave me with nothing afterward. This is of course after I have made a fair amount of progress, which is slow going while I learn the fundamentals of game design.
28 February, 2012
No headshots
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.
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.
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.
01 January, 2012
Where MMO's currently fall short
I might have wrote concerning this in the past, but I think it is important to revisit. I have had a few thoughts about how I feel the dynamic of massively multiplayer games is currently failing. I feel a lot of it comes back to a paradigm which could be traced back to games like the original final fantasy and dragon warrior for the original nintendo. A long time ago role playing video games were single player and players started out as weak and poorly geared characters who then began a long journey to becoming stronger, more powerful, and well geared adventurers who could beat increasingly stronger enemies. This paradigm also was present in non video game type role playing games like Dungeons and Dragons and then many other variety of role playing games similar to them. This paradigm of leveling up and becoming increasingly stronger was very successful and almost became pervasive in a world of offline video gaming, so the fact that online games would build off of it is only natural.
Enter the world of the internet, where players can now play games with other people in online worlds. The most famous example of this would probably be World of Warcraft though there are many of them out there with a growing number of them coming out every year. Just as in the single player paradigm of the single player role playing games, online game players start as weak and lowly characters who are able to progress through the acquisition of experience, wealth, and a whole assortment of items which allow them to complete quest after quest. The problem arises when players try to play together in these environments. I'll illustrate these problems with several scenarios featuring players A and B.
Scenario 1.
A has been playing an online game for several months now and has a level 25 character. He is good friends with player B, who after having heard of this game and having many invitations from A to play finally decides to play the game. Here is the problem. B must now start as a level one lowlife with nothing to his name, and starts to play the game in the way that single player rpgs go. If A wishes to play with B, he must either take his level 25 character back to the low level area where there is no challenge and the character does not progress, or he can start another character from the ground up so he can accompany B in this new game. A is now at odds with B in that A must stop his progression on his level 25 character if he wishes to play with B, which usually results with A impatiently rushing B along. B in the mean time may feel rushed and that he is not able to enjoy the game because A is trying to get him up to his level. What will usually occur in these situations is B finds another lowly beginner to play with or will elect to play alone as beginning levels don't really require teamwork. In the mean time A is playing with the other level 25s and progressing along there. Eventually, perhaps months or maybe even years later, A and B are on a level playing ground and can enjoy the game together. That may or may not happen as A and B may have stopped playing this game and have moved on to another game where the same situation happens. The moral of the story is that these friends aren't able to enjoy playing online games together. Players have tried many tactics to overcoming this problem, including power leveling( high level players assisting low level players to get levels quickly), buying gold from gold sellers for real money, or just buying an account where someone has already done all of the work of leveling up. All of these solutions have their own set of problems, but I digress.
Scenario 2
A and B start playing a game at the same time, but A has a lot more free time and motivation to play than B does and soon A is 5 levels higher than B. As time progresses the gap between these two players grows ever larger and soon it is not any fun for either player when they play together. This defeats the purpose of playing the game and soon A and B either find new friends to play with or will stop playing the game.
Scenario 3
A is a self proclaimed hard core gamer who decides that he must have the very best in the game before anyone else. To this end A quits his job and has very little interaction with anyone outside of the game. B is a friend who also enjoys games, but does not feel the need to have the best of the best, nor does he think that the game should trump life. A ends up spending every waking moment for months or possibly even years doing the mindless quests and hunting the rarest of monsters for the chance of the rarest of drops to happen. When B suggests that they play together, A notes that because B has not spent the necessary amount of time in the game and therefore cannot kill things fast enough, is too weak to fight the ultimate monster, etc.... So even though both players are the same level, the gear disparity makes it so they are still not on an equal playing field and cannot enjoy the game together.
So what is my point with all of these scenarios. My point is that the progression paradigm that works so well in single player games actually interferes with the social aspect of online games.
What is needed is a Paradigm shift.
Imagine now that the progression paradigm is changed to remove the concept of leveling up. In scenario one A and B are no longer at odds because there is no longer a level disparity. They can play together even though A has played 3 months longer than B. In scenario 2 it doesn't matter that A plays more than B since the amount of time that one spends in the game does not progress the character farther. And in scenario 3 A does not feel the compulsion to play the game to the exclusion of all else since no matter how much he plays he will have the best the game has to offer and B will be able to play with him even though he may not share the same level of motivation.
I know that some of you reading this are thinking "without progression what is the motivation to play". Well from what I have learned from research on MMOs from sources like the Daedalus Project many people play these games not because they wish to progress through a game, it is because they want to play with friends or other humans. This would suggest that if A were able to more easily and enjoyably play with B, then they will be more likely to play the game. I'm not suggesting that there be no objectives at all, though there are examples of games that have been successful there too like the Endless Forest.
I hope to provide in this game a place where people can play together, working to a goal side by side regardless of how long one has been playing or any other factor. It's also my hope that other MMOs will come to the realization that the progression paradigm is getting in the way of social interaction. After all the reason many people play multiplayer games is to have fun with friends.
Enter the world of the internet, where players can now play games with other people in online worlds. The most famous example of this would probably be World of Warcraft though there are many of them out there with a growing number of them coming out every year. Just as in the single player paradigm of the single player role playing games, online game players start as weak and lowly characters who are able to progress through the acquisition of experience, wealth, and a whole assortment of items which allow them to complete quest after quest. The problem arises when players try to play together in these environments. I'll illustrate these problems with several scenarios featuring players A and B.
Scenario 1.
A has been playing an online game for several months now and has a level 25 character. He is good friends with player B, who after having heard of this game and having many invitations from A to play finally decides to play the game. Here is the problem. B must now start as a level one lowlife with nothing to his name, and starts to play the game in the way that single player rpgs go. If A wishes to play with B, he must either take his level 25 character back to the low level area where there is no challenge and the character does not progress, or he can start another character from the ground up so he can accompany B in this new game. A is now at odds with B in that A must stop his progression on his level 25 character if he wishes to play with B, which usually results with A impatiently rushing B along. B in the mean time may feel rushed and that he is not able to enjoy the game because A is trying to get him up to his level. What will usually occur in these situations is B finds another lowly beginner to play with or will elect to play alone as beginning levels don't really require teamwork. In the mean time A is playing with the other level 25s and progressing along there. Eventually, perhaps months or maybe even years later, A and B are on a level playing ground and can enjoy the game together. That may or may not happen as A and B may have stopped playing this game and have moved on to another game where the same situation happens. The moral of the story is that these friends aren't able to enjoy playing online games together. Players have tried many tactics to overcoming this problem, including power leveling( high level players assisting low level players to get levels quickly), buying gold from gold sellers for real money, or just buying an account where someone has already done all of the work of leveling up. All of these solutions have their own set of problems, but I digress.
Scenario 2
A and B start playing a game at the same time, but A has a lot more free time and motivation to play than B does and soon A is 5 levels higher than B. As time progresses the gap between these two players grows ever larger and soon it is not any fun for either player when they play together. This defeats the purpose of playing the game and soon A and B either find new friends to play with or will stop playing the game.
Scenario 3
A is a self proclaimed hard core gamer who decides that he must have the very best in the game before anyone else. To this end A quits his job and has very little interaction with anyone outside of the game. B is a friend who also enjoys games, but does not feel the need to have the best of the best, nor does he think that the game should trump life. A ends up spending every waking moment for months or possibly even years doing the mindless quests and hunting the rarest of monsters for the chance of the rarest of drops to happen. When B suggests that they play together, A notes that because B has not spent the necessary amount of time in the game and therefore cannot kill things fast enough, is too weak to fight the ultimate monster, etc.... So even though both players are the same level, the gear disparity makes it so they are still not on an equal playing field and cannot enjoy the game together.
So what is my point with all of these scenarios. My point is that the progression paradigm that works so well in single player games actually interferes with the social aspect of online games.
What is needed is a Paradigm shift.
Imagine now that the progression paradigm is changed to remove the concept of leveling up. In scenario one A and B are no longer at odds because there is no longer a level disparity. They can play together even though A has played 3 months longer than B. In scenario 2 it doesn't matter that A plays more than B since the amount of time that one spends in the game does not progress the character farther. And in scenario 3 A does not feel the compulsion to play the game to the exclusion of all else since no matter how much he plays he will have the best the game has to offer and B will be able to play with him even though he may not share the same level of motivation.
I know that some of you reading this are thinking "without progression what is the motivation to play". Well from what I have learned from research on MMOs from sources like the Daedalus Project many people play these games not because they wish to progress through a game, it is because they want to play with friends or other humans. This would suggest that if A were able to more easily and enjoyably play with B, then they will be more likely to play the game. I'm not suggesting that there be no objectives at all, though there are examples of games that have been successful there too like the Endless Forest.
I hope to provide in this game a place where people can play together, working to a goal side by side regardless of how long one has been playing or any other factor. It's also my hope that other MMOs will come to the realization that the progression paradigm is getting in the way of social interaction. After all the reason many people play multiplayer games is to have fun with friends.
Labels:
Apoidea,
Brift,
game,
game design,
Hex wars,
mistake,
MMO,
progression paradigm
Subscribe to:
Posts (Atom)