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.

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.

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.

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.

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.

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.

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.