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.
11 December, 2020
Why the break
Hello everyone who may be interested, which I'm guessing at this point is very few if any. I stopped writing this blog several years ago because my professors were worried that if I posted my algorithms and or thoughts on game development that I wouldn't be able to get published in a journal(which is important for graduate students for some reason). Since my masters project would essentially need to be such a paper I stopped writing my blog. Well, I dropped out of school years ago, and I find myself unemployed once again. So in the hopes that this will be useful to others I am going to go back over all of my posts and add my thoughts on how things changed after I have learned a great deal more about this. So let the necroposting commence.
08 October, 2013
Collisions with triblocks
So I've run into another problem using triblock style voxels. First a little background into how voxel engines work. In games like minecraft it seems like there are millions of blocks that are all separate and independent, but the reality is that if each block had to be individually drawn it would slow the system down considerably. To avoid these millions of draw calls the blocks are instead organized into chunks. A chunk may be an area of say 16x16x16 blocks that will take into consideration whether the blocks are filled or not and then draws a mesh to represent all of the filled blocks that are next to empty blocks. When the player interacts with the world and places or removes blocks then the chunk( or chunks in the case of being right on the edge) is redrawn. Because the whole thing is a mesh together, the collision of the ray from the player's point of view (represented as the sight in the middle of your screen, usually a cross or box) has to determine which box in the chunk is being selected for change, and it accomplishes that in most systems by going halfway into a block and calculating where it is. Because cubes line up with orthogonal directions fro x, y, and z in a 3d system then they use those directions to identify the block they are in and do the necessary change. No matter where the collision occurs on the chunk the test will always find the resulting blocks.
My problem is that using equilateral triangles for one of the planes creates a system where sides will be facing directions other than the orthogonal directions of x, y, and z. To complicate things further if I were to do the same test by going in a half block distance into the block or out from the block using the direction(or negative direction) of the normal vector and the collision occurs near one of the edges I will identify the wrong block for deletion/addition into the mesh. This is kind of a big problem. One possible solution would be to have each mesh store a triangle list, with each triangle pointing to the block it belongs to and the block it is facing. The problem with this approach is that even more will have to be stored in memory during run time, and voxel games are already huge memory hogs. Another issue is that to cut down on the amount of drawing that has to be done if several faces are in the same plane often the triangles are enlarged to cover just the edges of what is showing.
My problem is that using equilateral triangles for one of the planes creates a system where sides will be facing directions other than the orthogonal directions of x, y, and z. To complicate things further if I were to do the same test by going in a half block distance into the block or out from the block using the direction(or negative direction) of the normal vector and the collision occurs near one of the edges I will identify the wrong block for deletion/addition into the mesh. This is kind of a big problem. One possible solution would be to have each mesh store a triangle list, with each triangle pointing to the block it belongs to and the block it is facing. The problem with this approach is that even more will have to be stored in memory during run time, and voxel games are already huge memory hogs. Another issue is that to cut down on the amount of drawing that has to be done if several faces are in the same plane often the triangles are enlarged to cover just the edges of what is showing.
So what this means is I won't be able to do the large areas I was hoping for back when I first had this grand idea. Unless of course I figure out how to overcome these obstacles. Anyway if you are interested in a better explanation please visit https://sites.google.com/site/letsmakeavoxelengine/. It had a pretty good explanation of what goes into a voxel engine.
13 August, 2013
The clutter of virtual stuff
So I have been playing Hexxit with my wife and kids and I'm noticing something. For those of you who aren't familiar with Hexxit it is part of a mod package for Minecraft which comes with the Technic launcher. Anyway back to my point, I have a tendency towards hoarding inside of video games, especially MMOs. I realized that I have been spending hours creating chests and organizing the vast amount of stuff inside of the game. I have noticed that I have this tendency in other games I play as well, games like Firefall and Aion. In Firefall the inventory is an endless black hole that I can throw whatever into, which is nice in that I don't have to worry about space but very confusing when looking for something in particular. In Aion I was forever running out of space for the myriad of items to be found, and finding where I put something could be very annoying as I would have to switch characters and do item juggling just to get the items in the right place. Even with the difficulties that arise I still find myself justifying keeping every little thing since it may be useful eventually, right?
It is clear that people like stuff, even virtual stuff. According to this New York Times article, virtual goods are worth billions of dollars, and this was back in 2010. That is a lot of money for items that aren't really there. So the question I have is how many items should there be in a game that I create? In the case of a Minecraft like game there needs to be both a 2D sprite of the object to go into the player's inventory, and usually a 3D representation of the object. A player inventory implies a multi-level database, as you have the inventory that the player is holding at the moment and more long term storage at the base. I'm going to learn a bit more about databases this coming semester, and I'm hoping to puzzle out a little of how I'm going to organize this project. But one thing is clear at least to me, more is not necessarily better. I think that keeping things to a minimum in the number of things department would be a good thing. I'll have to think more on this later though as I still need to get the basic mechanics of the world figured out first.
It is clear that people like stuff, even virtual stuff. According to this New York Times article, virtual goods are worth billions of dollars, and this was back in 2010. That is a lot of money for items that aren't really there. So the question I have is how many items should there be in a game that I create? In the case of a Minecraft like game there needs to be both a 2D sprite of the object to go into the player's inventory, and usually a 3D representation of the object. A player inventory implies a multi-level database, as you have the inventory that the player is holding at the moment and more long term storage at the base. I'm going to learn a bit more about databases this coming semester, and I'm hoping to puzzle out a little of how I'm going to organize this project. But one thing is clear at least to me, more is not necessarily better. I think that keeping things to a minimum in the number of things department would be a good thing. I'll have to think more on this later though as I still need to get the basic mechanics of the world figured out first.
17 June, 2013
Doing things wrong
So I've been enjoying a break from school ( I figure I should do that while I still have the chance) and in between I have been looking at tutorials for how to do a minecraft-like in Unity3D. The particular video series I followed is by one Craig Perko and can be found at .
So what I have learned from this video is that I was going about creating my scene the wrong way. I was creating a new mesh for every face that needed to get displayed, rather than making the faces all fit together into a larger mesh. This would explain why it was performing so badly at my website http://apoidgames.web44.net/wedge.html, I had hundreds of very expensive meshes all trying to fit together. Unfortunately building all of the faces into a single mesh is not quite so easy when using equilateral triangles for one of the planes. Also unfortunately I am taking a class called computational geometry over the summer which will again take much of my time, so I will have to put this project on hold for now(again). Anyway thanks Craig Perko for explaining how minecraft works a little more clearly.
So what I have learned from this video is that I was going about creating my scene the wrong way. I was creating a new mesh for every face that needed to get displayed, rather than making the faces all fit together into a larger mesh. This would explain why it was performing so badly at my website http://apoidgames.web44.net/wedge.html, I had hundreds of very expensive meshes all trying to fit together. Unfortunately building all of the faces into a single mesh is not quite so easy when using equilateral triangles for one of the planes. Also unfortunately I am taking a class called computational geometry over the summer which will again take much of my time, so I will have to put this project on hold for now(again). Anyway thanks Craig Perko for explaining how minecraft works a little more clearly.
23 April, 2013
The Algorithm for triangles and hexagons
So I thought that it might be a good time to share the algorithm I devised in order to create triangles and hexagons in a standard 3-space. I'll share just the one for a triangle since the hexagon is just 6 triangles put together.
In order to do it you will need some variables that are important. This will be written in pseudo code and should be easily adapted to whatever language you wish to translate it to.
In order to do it you will need some variables that are important.
// This variable is the height of an equilateral triangle
float depth = Math.sqrt(3)/2;
//Then we need some counters for the loops
float count = 0;
float countstart = 0;
float countstop = 50; // This can be for however large you wish to draw
// This first one is built in 2 space
for( int y = 0, y < 50, y++) //Note that the target number of loops is the same size as countstop
{
count = countstart;
while( count < countstop) // This is where the X element is drawn
{
Draw an equilateral triangle the uses the following vertices;
Vertex1 ( x = count, y= y * depth);
Vertex2 (x = count + 1, y= y * depth );
Vertex3 (x =count + 0.5, y = (y + 1) * depth );
count = count + 1;
}
countstart = countstart + 0.5;
countstop = countstop - 0.5;
}
The one for creating triblocks in 3 dimensions is fairly similar
//These variable are used once again
float count = 0;
float countstart = 0;
float countstop = 50; // This can be for however large you wish to draw
//There are only slight variations to build blocks in 3-space
// This second one is built in 3 space
for (int z = 0, z < 50 , z++)
{
for( int y = 0, y < 20, y++) //Note that the target number of loops is the same size as countstop
{
count = countstart;
while( count < countstop) // This is where the X element is drawn
{
if( z=0)
{
Only draw a zpos triblock
}
else
{
Draw a zpos triblock
Draw a zneg triblock
}
count = count + 1;
}
}
countstart = countstart + 0.5;
countstop = countstop - 0.5;
}
Please note that the y loop can have as many iteration as you wish since the triangle is in the z and x portions. Again to create a hexagon one would need 6 of these triangle formations.
In order to do it you will need some variables that are important. This will be written in pseudo code and should be easily adapted to whatever language you wish to translate it to.
In order to do it you will need some variables that are important.
// This variable is the height of an equilateral triangle
float depth = Math.sqrt(3)/2;
//Then we need some counters for the loops
float count = 0;
float countstart = 0;
float countstop = 50; // This can be for however large you wish to draw
// This first one is built in 2 space
for( int y = 0, y < 50, y++) //Note that the target number of loops is the same size as countstop
{
count = countstart;
while( count < countstop) // This is where the X element is drawn
{
Draw an equilateral triangle the uses the following vertices;
Vertex1 ( x = count, y= y * depth);
Vertex2 (x = count + 1, y= y * depth );
Vertex3 (x =count + 0.5, y = (y + 1) * depth );
count = count + 1;
}
countstart = countstart + 0.5;
countstop = countstop - 0.5;
}
The one for creating triblocks in 3 dimensions is fairly similar
//These variable are used once again
float count = 0;
float countstart = 0;
float countstop = 50; // This can be for however large you wish to draw
//There are only slight variations to build blocks in 3-space
// This second one is built in 3 space
for (int z = 0, z < 50 , z++)
{
for( int y = 0, y < 20, y++) //Note that the target number of loops is the same size as countstop
{
count = countstart;
while( count < countstop) // This is where the X element is drawn
{
if( z=0)
{
Only draw a zpos triblock
}
else
{
Draw a zpos triblock
Draw a zneg triblock
}
count = count + 1;
}
}
countstart = countstart + 0.5;
countstop = countstop - 0.5;
}
Please note that the y loop can have as many iteration as you wish since the triangle is in the z and x portions. Again to create a hexagon one would need 6 of these triangle formations.
Labels:
algorithm,
apoidgames,
Brift,
game,
game design,
gamedev,
Hexwars,
triangles
28 March, 2013
Early Wedge in Html5
Ok after a long time I finally have a playable demo I can share with everyone via the web. Just go to
http://apoidgames.web44.net/wedge.html
The controls are basic and it may run a little slow as I only have one type of the two types of triblock showing. There is also no collision detection so you can walk right through all of the blocks. I built it using three.js, and I'm hoping to get to the point where it can be edited. It at the very least will give everyone an idea of what I am going for in the landscape. Just imagine lots of these triangles put together into one large field. Anyway I'm back to figuring out how to make this even more interactive.
http://apoidgames.web44.net/wedge.html
The controls are basic and it may run a little slow as I only have one type of the two types of triblock showing. There is also no collision detection so you can walk right through all of the blocks. I built it using three.js, and I'm hoping to get to the point where it can be edited. It at the very least will give everyone an idea of what I am going for in the landscape. Just imagine lots of these triangles put together into one large field. Anyway I'm back to figuring out how to make this even more interactive.
21 March, 2013
Beginners Ambition
So I've come across this term in my research and I thought I would talk about it a little. Having spent the last few years of my life pursuing a dream that was far too ambitious for a first project, and also meeting many beginners in the game creation process, I have seen a definite pattern that has emerged. When someone is unfamiliar with what it takes to make a video game they think remaking some large game or creating an MMO is just a matter of using the existing framework and tweaking it a little. What happens afterward is a realization of what a colossal effort it takes, as every question they look up on Google leads to two or more new questions, which when followed lead to yet more questions. Soon a beginner is quite overwhelmed, and that grand game they have thought up becomes an unconquerable beast of a task.
So what advice would I give to someone interested in becoming a game developer. Well one is start small, with learning how to make pong for example. Think of pong as the monster conquerable by a beginning adventurer. It's not that exciting, but given you are just starting out it's where you are and it will give you valuable experience needed for the next level challenge and the challenge after that. Eventually you will be able to recreate games from the 8-bit era like super mario bros. Unfortunately there are no shortcuts if you wish to create something truly unique. If you wish to program a 3D game then you will need to learn matrix math and programming challenges that will really stretch your creative and analytic skill sets. Perhaps one day, hopefully with the help of others going through a similar journey, you will be able to take on that challenge and make your game.
Also I cannot stress enough that making games is a challenge that will require a good education in math, computer science, and depending on what you want to include in your game a wide variety of other subjects. It is not a challenge for the faint of heart, and unlike playing most games you will fail many times before you succeed. I have a great respect for game developers now, and I truly hope that many of the rising generation are able to take on the challenge to become great game developers in the future.
So what advice would I give to someone interested in becoming a game developer. Well one is start small, with learning how to make pong for example. Think of pong as the monster conquerable by a beginning adventurer. It's not that exciting, but given you are just starting out it's where you are and it will give you valuable experience needed for the next level challenge and the challenge after that. Eventually you will be able to recreate games from the 8-bit era like super mario bros. Unfortunately there are no shortcuts if you wish to create something truly unique. If you wish to program a 3D game then you will need to learn matrix math and programming challenges that will really stretch your creative and analytic skill sets. Perhaps one day, hopefully with the help of others going through a similar journey, you will be able to take on that challenge and make your game.
Also I cannot stress enough that making games is a challenge that will require a good education in math, computer science, and depending on what you want to include in your game a wide variety of other subjects. It is not a challenge for the faint of heart, and unlike playing most games you will fail many times before you succeed. I have a great respect for game developers now, and I truly hope that many of the rising generation are able to take on the challenge to become great game developers in the future.
Labels:
Apoid,
beginning programming,
Brift,
game,
game development,
Hexwars
22 February, 2013
Working on Web Programming and Three.js
So I've been doing some soul searching and trying to determine what to teach myself in programming relating to graphics. I learned a bit about GLUT (an open GL library not really used much these days) and rather than learning older technology I am going to work on understand HTML5, javascript, and WebGL. I hope to put something together that runs in a browser (probably Chrome, upgrade if you haven't yet) by the end of the semester.
To this end I am learning about an interesting library called THREE.js by one mr.doob. He has been instrumental in getting several chrome experiments up and running and I feel that the library is approachable as the novice I am. The cool thing would be that I could share whatever I make on the internet, so hopefully you all can experience it too. Thanks for reading as always.
To this end I am learning about an interesting library called THREE.js by one mr.doob. He has been instrumental in getting several chrome experiments up and running and I feel that the library is approachable as the novice I am. The cool thing would be that I could share whatever I make on the internet, so hopefully you all can experience it too. Thanks for reading as always.
12 February, 2013
The power in WebGl
I recently stumbled upon a pretty amazing demo showing just what can be done with javascript and Webgl. You can check it out at https://developer.mozilla.org/en-US/demos/detail/bananabread . Basically they took a full game engine written in C++ and OpenGL and ported it to javascript and webgl. It's open source, so I will be able to study it out and get a good idea of where I could go to start my own game later on.
Labels:
Apoid,
apoidgames,
Brift,
game,
gamedev,
Hexwars,
javascript,
WebGL
04 January, 2013
Reality Check
I'm coming to the realization yet again that this is no small project that I have undertaken. I recently had a few good discussions with people on Google+ about game making, and here is what one +Robert Mitchell, who has some experience in the game industry, had to say
"The fact is that the level of competition for good game dev gigs has never been higher. And the reward:risk isn't as good as other sectors unless you offset with an obsession about games in the first place. The likes of EA, for instance, has a tiny fraction of a percent hiring rate for applicants to any given job offer made.
Even then, lucking out with stable employment in this field is just like netting a pink winged unicorn that tastes like chocolate bacon."
Also
"The fact is that the level of competition for good game dev gigs has never been higher. And the reward:risk isn't as good as other sectors unless you offset with an obsession about games in the first place. The likes of EA, for instance, has a tiny fraction of a percent hiring rate for applicants to any given job offer made.
Even then, lucking out with stable employment in this field is just like netting a pink winged unicorn that tastes like chocolate bacon."
Also
"But again, if you find yourself awake at night thinking about how the latest games you played could be improved - and not just from the addition of a new character - and or find yourself in deep thought about the emergent properties found in the interaction of systems around you. Or if you enjoy reading game theory papers talking about conflict and cooperation and Monty Hall's three door game makes obvious sense to you and you don't mind the years it might take to fully pivot over... Game development is incredibly rewarding, IF and ONLY IF you have the love of the craft... because otherwise, this industry will devour your soul and leave you a grumpy, sour mess. I've seen it happen and almost always to good people who just wanted a stable, straight forward job."
I've given a lot of thought to his comments, and the cold hard reality is that I will have to put the needs of my family first and foremost. I have also come to realize that I am not passionate about making games in general, rather I am passionate about making a game that I think I would enjoy playing. I probably won't be able to get the resources to make this particular game as it is so ambitious. I do plan on continuing my education and finishing my master's degree, and I'll find out how much I can get done before that period of my life is finished. I might end up doing a thesis as opposed to a project, but I still have a long time before I have to make that choice. To any aspiring game developers who may be reading this, I recommend learning as much as you can as early as you can. Trying to learn all of this in my mid 30's has been quite tiring.
10 December, 2012
Firefall review
So I recently had the opportunity to try out Firefall and I must say that for a free to play game it was very impressive. I liked the ability to swap out battleframes, which is very similar to the idea I have for switching roles. There was a definite PvE (player vs environment) push, with PvP(player vs player) being almost an afterthought. The PvP matches were basically 5v5 team deathmatch style with the possibility of 10 v 10 on different maps, but there is not the persistent open world pvp I was kind of hoping would be there. There are a kind of simple tower defense type situation where you and your squad defend a thumper (a type of mining device) from wave after wave of overgrown bugs and other mutated wildlife, which provides a challenge of it's own. Finally there is the Chosen, who are evil incarnate NPC (non player characters) who come to take over watchtowers and generally make life difficult. Some of them are quite powerful, leaving me roasted a many a time as I tend to walk around alone. Even so I was able to take out dozens of them single handed, and I'm sure that even with improved AI players will eventually figure out way's to kill them easily.
As for what I would hope to see, I would say that player controlled chosen would make the game very interesting. That way large scale open world pvp could be realized, though that also introduces some problems as to how would tech and other items work. That and if you have the "good" side and the "bad" side developers often will unconsciously favor the good side.
As for what I would hope to see, I would say that player controlled chosen would make the game very interesting. That way large scale open world pvp could be realized, though that also introduces some problems as to how would tech and other items work. That and if you have the "good" side and the "bad" side developers often will unconsciously favor the good side.
Labels:
Apoid,
apoidgames,
Brift,
Firefall,
game,
game design,
game development,
gamedev,
Hexwars,
review
Product vs Service
As I continue to study the art of game creation I came across an interesting and thought provoking concept, that we are moving away from games as a product to games as a service. I certainly would say that I hope to create a system for the latter, but I suppose I should explain the differences before I go into that.
In the past games were required to be in a complete state (meaning completely coded, put into a package to be sold in retail outlets, etc..) before they got to the consumer. Often once it had shipped the developers would no longer have anything to do with the product other than wait for one of two outcomes, success and the opportunity to make more games or rejection by the masses which usually meant the end of said game development company. With every "product" shipped there was a definite gamble, and since publishers who were funding the product from the inception and who also are very concerned with making a profit were pretty much in control, any failure to produce said profit was a death sentence to any game developer who didn't perform well.
Now switch to games as a service. MMO's are a great example of how this mindset works. A game is created and then costumers are brought in before the game is complete (usually in beta) and they give feedback as to what they would like to see in the game as a finished product. The thing is that the game is never really finished, as things keep getting added on. Costumers also don't do the one time purchase as in the other model, rather they pay on an ongoing basis either through subscription costs or via micro-transactions. The game developer and the consumer then have this continual relationship where there are feedback loops and opportunities for creating an experience that players enjoy and game developers are happy to provide. It also means that game developers are able to work with a product long after it has reached the hands of the consumer.
I think the second option has a better chance of creating communities around a game, and also gives developers a chance to polish and work out games to become the very best that they can. I look forward to the change in paradigms that is already occurring.
In the past games were required to be in a complete state (meaning completely coded, put into a package to be sold in retail outlets, etc..) before they got to the consumer. Often once it had shipped the developers would no longer have anything to do with the product other than wait for one of two outcomes, success and the opportunity to make more games or rejection by the masses which usually meant the end of said game development company. With every "product" shipped there was a definite gamble, and since publishers who were funding the product from the inception and who also are very concerned with making a profit were pretty much in control, any failure to produce said profit was a death sentence to any game developer who didn't perform well.
Now switch to games as a service. MMO's are a great example of how this mindset works. A game is created and then costumers are brought in before the game is complete (usually in beta) and they give feedback as to what they would like to see in the game as a finished product. The thing is that the game is never really finished, as things keep getting added on. Costumers also don't do the one time purchase as in the other model, rather they pay on an ongoing basis either through subscription costs or via micro-transactions. The game developer and the consumer then have this continual relationship where there are feedback loops and opportunities for creating an experience that players enjoy and game developers are happy to provide. It also means that game developers are able to work with a product long after it has reached the hands of the consumer.
I think the second option has a better chance of creating communities around a game, and also gives developers a chance to polish and work out games to become the very best that they can. I look forward to the change in paradigms that is already occurring.
Labels:
Apoid,
apoidgames,
Brift,
game,
game design,
game development,
gamedev,
Hexwars
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
Subscribe to:
Posts (Atom)




