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.

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.  

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.

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.

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.

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.

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.

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.

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.

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.

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:

 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.  

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

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.

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.

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.

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

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.

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.

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.

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.

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.

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.