So I Don't Like Bloggin... Apparently

The last few weeks have revolved around pinning down the exact way pods will work. After a final decision was made last week I was able to Implement 3 of the 4 pod types.

Engine: Passive bonus to thrust, use:temp boost
Shield: Passive bonus to shields, use:Overshield
Weapon: Passive bonus to lasers, use:temp strong lasers(maybe something cooler later)

Special: not yet done, because we have yet to decide exactly what this will be i did not implement it, but the backend logic to quickly incorporate it is there.

originally there were going to be many pods of everytime, but in order to streamline the interface we have decided that the only pods that will have any variation are the special pods. all engine, shield, and weapon pods will be indistinguishable from other engin, shield, and weapon pods. this may prove to make balancing farther levels later on, but that may be solved by allowing the ship to "unlock" additional ports to carry extra pods even if the pods are not more powerful they will have more of them.

The pods apply the passive bonus and then when use will have the bonus affected for a set number of frames and then drop off the ship and then begin smoking with the particle engine.

Stardate 64339.5

This week most if not all my work revolved around implementing the core of our game, pods. The realization that we could store meaningful information in the form of locator points in maya was a major plus to our idea. After a naming system was established i wrote code that would look at all the locators for various pod types and then created the data structures to support those points. All said and done every ship can now read a significant amount of data in from it's own model and will manage it's own pods and types appropriately. Also the pods now fire satisfactorily from the ship. 

Progress or something resembling it.

This week we moved away from the twice a week mandatory meetings to a single saturday morning meeting.
I think this is a smart move for two reasons: 1, we won't get burned out as easily meeting only once a week, and 2, meeting Saturday morning gives us a lot of time to work with compared to after school during the week. Also i personally find it easier to code not after a long day at school and work. It is somewhat hard to give up sleeping in Saturday morning but ultimately i think the gains will outweigh the negatives.

This Saturday I implemented a large portion of the functionality of the pods. There is now a base pod class that all ships can interact with by picking up, droping, and shooting. To begin with I added on test pod that makes the ships "laser_strength" variable grow and shrink accordingly. the firing animation if you can call it that is not exactly polished though and the pod sometimes jumps to a new location as it is fired from the ship.

The deeper we dive in to the 3d of xna the more we find that there is much we can use built into the framwork.
 when researching how to generating bounding boxes for the collidable models we found that xna will make bounding sphere's for each seperate mesh of the model as well as for the model as a whole. So by having our artists break up their models into several meshes the bouding spheres will be generated for us. However it was hard for our artist to know how the bounding sphere's where going to look so i made a small windows forms program that incorporates xna and will draw the model loaded with the auto generated bounding spheres.

Coding Away

Between the meetings Friday and Saturday a lot of functional code was put together. My task was to get the controls for the ship working. To get it to the point that this was actually testable Felix and myself put a lot of general coding in various places. The Ship behaves very well now and combined with the work that Felix did on the camera I think that we have an excellent base on which to build the rest of the game.

Confusion. While we are able to make fairly significant progress in some areas other parts of my job confuse me because I don't know what the final product is actually supposed to be. Exactly what the ships are and how they interact with the ship is somewhat up in the air still and i think that we are going to pound out and possibly vote on one issue tomorrow.

Back to the Blogging

I've been somewhat lax in my blogging so I will attempt to summarize what has happened since my last post. After the voting process 3 games were chosen. Those game being: Gravity Shift, Twin-stick dota commando or some other morphing name, and then my teams game "Ununpentium: A Space Fighter Game" which I'm still hoping changes as my team, I believe, knows.

Shipwrecked seemed to be cursed by it's small target audience and somewhat lack luster gameplay. Although I believe it is the kind of game that I would enjoy thoroughly, I can easily see how most would not. In any case, onwards we go.

Ununpentium, it sounds like something Intel will come out with after the i7, but alas it is not. After deciding to essentially scrap the prototype that was put together by the pitch team we began to plot out where we thought we could start. The original prototype will likely contain a lot of code that eventually gets put into the new project but it was essentially in one large unorganized file. It has been somewhat of a daunting task to just begin the project. I quickly sketched a class structure for the elements of a game and also a control flow for how we would update and manage the states of the game last week and we've been working off that as a basis. It is far from a perfect design and will likely change greatly, but the general consensus has been that we have to start somewhere and start making mistakes before we can fix them. This will have much more added to it, but here is a diagram of the classes that I put together:

This is far from a complete structure but it does allow for a lot of growth to occur with little to no interruption to the preexisting classes.

Until today there has not been a clear division of work and Felix and James have put in the majority of actual code. I also have added several other classes and put in simple member variables and such where I could see it was clear they were needed, but have been hesitant to work on something that will become some other person's responsibility. Today though we have all been given much more specific tasks and I am responsible for getting the ship class put together. This will likely be challenging because it involves a lot of what to me is complex 3d model translations. Also we have a very well thought out menu system but we still do not have the ability to get into any sort of a game play situation which makes testing my classes impossible for now.

Pitch Day

Today we did our final pitch to a few industry people. I thought that most of the teams did quite well. Many of the prototypes were much improved from the first dry run. My own personal critique of a few of the ideas is that while they are excellent ideas the playstyle and point and click or drag and drop interface only makes sense with a mouse and keyboard and definitely not a controller.

Specifically our own pitch I thought went decidedly ok. In that we did not wow or impress, nor did we fall entirely flat. Somewhat frustratingly many of the elements that we consider core the the game (hunger, thirst, gradual gathering and building) were received quite negatively and a quicker shorter version of the game, that I at least would defeat the whole purpose, was suggested. Then again that is just how these things go I suppose.

Filming

This weekend I worked more on the 3d prototype scene. I was unable to create an effective height map, but compromised by filming with a free flying camera. I put in a few rows of trees that Brandon had modeled. There were some issues, such as at certain angles the leaves of the trees would disappeared entirely. By filming mostly below the height of the trees though it was hard to see which trees were missing their leaves. The other complication was the quality of the video. I use a free software that worked well on small resolutions or slow moving scenes, but when i tried filming something in a resolution as high as my windows the frame rates would
drop below 5 per second.

It appears I actually do have some depth

After talking to Roger and Bob about our game last Thursday we have decided to divide our resources. Zee is working on a 2d prototype that is going to show some of our mechanics and be a general tool for explaining gameplay while I am working on a 3d prototype that will be essentially eye candy (if you can call it that) and have a model slide around a beach or island.

I was able to relatively quickly find some tutorials for terrain and water and put that together, but this did not support any collision, height mapping, or a 3rd person camera at all. The majority of my time went into importing our prototype character into the world and then finding a way to have the camera follow him as it should and then also have him be put at the correct height as he slides around the map.

The problem that I have run into is that while he is sliding he will only snap to the height of the nearest terrain vertex. I have attempted several solutions such as taking the height of several of the vertexes around him but to not much success. Even as it is it may be a useful presentation tool if nothing else but for screen shots. I hope to be able to figure out a more elegant solution before the pitch tomorrow and if not by then for the final pitch next week.

I'm Just a 2-dimensional Guy

After a period of indecision it seems that we are going to scrap the 3d attempt and refocus on working on a 2d prototype. I was starting to get exciting at the idea of attempting the 3d, but this is a much more realistic path to take at the moment. I've been drawing up some basic outlines for the game major classes, but some of those were with 3d in mind, but some minor changes should make them applicable.

As a side note, my new computer has arrived and with vs2008 and xna freshly installed I'm finally able to get down to some real code and real work. The exact points that we are trying to hit in the prototype are not entirely clear to me, but I'm sure will be soon. As for now having the ability to walk around a map, basic collision, and basic inventory seem to be the obvious things to get up and running.

The New Pitch

Voting took place and we were divided into small teams last week.

I was placed on what as far as I can remember was my second or third choice. Shipwreck, as best as I can describe it in a few word is an open ended survival rpg. The long term goal of the character is to escape a tropical island which he/she has been stranded on, but the immediate fun I believe is going to be exploration and, for lack of a better word, stabilization. What I mean by this is that while the character is originally thrown into a very hostile world with no means of feeling safe there will be ways to create shelter, stockpile food and resources, and become more dangerous themselves.

The major decision we have to make as a team is weather to pitch this as a 3d game or a 2.5D game. Originally I was hesitant to go any where near a 3d game, but after reading tutorials and just plain thinking about how the game would look I want to invest a little more time to see if it is possible. The game itself is of fairly large scope and adding 3d could push us over the edge into the realm of impossibility, but it remains a possibility for now.

The Pitch

This week was the pitching and voting on what game we will eventually build.
This was mine:

Junkers
Pace Sims
 

Story Summary:
In the year 1337 robots that have out lived their function
are exiled into the cold dead void that is space, Mars. When a group
of robots has their friend taken to this place they must band together
to make their way to to Mars and then, with some luck, back again.
 

Game Play:
- Side-Scrolling Puzzle Platformer
- 1-4 (2-4 possibly?) Players (split screen or zoom out?)
- There are 4 Robots that can be controlled simultaneously
(1 active robot per player at a time)
- Players must use the unique abilities of each Robot to make
there way through the levels and puzzles.
 

Robot 1:
Can unlatch his/her arm and use it as a grappling hook
Robot 2:
Can shoot a laser and has a short ranged attack as well
Robot 3:
Can jump twice as high and can
glide with his arms that turn into wings.
Robot 4:
Has armor plating and does not take damage from normal enemies.
Is also very strong and can throw other players and lift heavy objects.
 

Examples:
This is very much like the snes game "Lost Vikings"
What makes this game different from lost vikings is the multiplayer
mechanic. Because the players can be controlled simultaneously the
puzzles can take this into account and become more complex.

Notes:
The story and particular powers of the robots are not elements that have
had a great deal of thought put into them, but the mechanic of the multiple
player/multiple power put into a puzzle platforming game I believe lends itself
very well to a scalable complexity that other mechanics may not offer.

Blogger

I just blogged all over this page.