Gravity Shift Progress - 12/05

On Sunday, December 5, 2010 0 comments

RThis week was another busy week for all my other classes but I did find time to add some new features. First, I fixed some small bugs here and there in the level editor. I also added the ability to use triggers and to translate them and run them correctly. The trigger I made, adds a force to any item that is within the defined range(changeable from the level editor) with a force that is changable from the level editor. The trigger can also be a square or a circle collision. I also spent some time completely rebasing GameObject construction through all its children. This passes the translated entity info to the object so each one can translate itself however it wants. I also fixed the camera, which looks tons better than it did.

Published with Blogger-droid v1.6.5

Gravity Shift Progress - Monday 11/22 WAY BEHIND :S

On Monday, November 22, 2010 0 comments

I don't know why I keep falling behind now, but I apologize first off. Between Thursday and Tuesday, I was not able to get any work done at all, except for getting our program upgraded to 2010 and XNA 4.0; Between Tuesday and Thursday, I coded up the translation process between the level editor and the game. This includes launching the game from the level editor, and converting the xml logic into Game logic. Also, this includes fixing all the bugs that arose from this. Since then, I have not had time to work on any more of the project. Its been pretty busy lately but I should have a lot of time the rest of this week(after Thanksgiving :D)

Gravity Shift Progress - Thursday 11/11

On Thursday, November 11, 2010 0 comments

This might seem lazy, but class is starting right now, so here's all my commits I did since Monday.

commit 645ba7dd956d44892afa3acc028fe4ced2b17ea4
Author: Tyler Robinson
Date: Thu Nov 11 14:11:06 2010 -0700

Update Additional Properites.
-Now allows loading and saving of entity properties. Also, set up for editing individual entity property values

commit 5867090c50cb90e026b3af7843cfeeb957ad0b3b
Author: Tyler Robinson
Date: Thu Nov 11 13:56:19 2010 -0700

Update Additional Properites.
-Now allows loading and saving of entity properties. Also, set up for editing individual entity property values

commit c51c2fe3ffe609f7903ea25d7fa3356cbcba40d2
Author: Tyler Robinson
Date: Wed Nov 10 17:39:39 2010 -0700

Integrate Save/Load for everything

commit ab6c709655871619010bbb7b8246f21c423ca08e
Author: Tyler Robinson
Date: Wed Nov 10 15:58:19 2010 -0700

Fix Row/Column initialization and Add manual Double Buffer

commit d18d297f97271ec5e369f07147187a8138d9d1f7
Author: Tyler Robinson
Date: Wed Nov 10 08:53:56 2010 -0700

Add some comments and fix an error with Select tool

commit f84f35f57c8f89979c795c67f76a944a8c2919e5
Author: Tyler Robinson
Date: Tue Nov 9 23:17:13 2010 -0700

Fix multiselect
-Relocated the drawing points with the drawing offset. Why this worked before and stopped? Who knows.

--Flicker is nearly 100% gone, and definitely good enough to leave be for now
(maybe come back in the future but I don't know why we would).

Definitely release quality at this point(minus few missing features)

commit 3120322c27c5116ccf2ef702419ae0b6180383f9
Author: Tyler Robinson
Date: Tue Nov 9 21:59:25 2010 -0700

Major improvement in flicker issues. Still exists but much better now(Completely usable now)

commit 10b02b9f518504ce5a5b83417c682f501fd8408e
Author: Tyler Robinson
Date: Tue Nov 9 21:27:24 2010 -0700

Add some movement prevention code. Keeps things on the grid

commit dc4b4b17e8b0d124ddfcd3899e77b39fa145983d
Author: Tyler Robinson
Date: Tue Nov 9 21:03:07 2010 -0700

Fix some flicker in Depaint

commit b411fb3de9706270a586a2f7560fc405fed934d0
Author: Tyler Robinson
Date: Tue Nov 9 14:42:57 2010 -0700

Bug fix, Bug fix, Bug fix, Bug fix...Other stuff...New things :D

commit f38e624094a29a3ea124e82991039777395e7fb2
Author: Tyler Robinson
Date: Tue Nov 9 02:06:34 2010 -0700

Better Multi-Selection. Looks wonderful...Check it out :D

commit b1bb75adcf6fb88a5261abdc8a1306dfa738b04d
Author: Tyler Robinson
Date: Mon Nov 8 23:43:23 2010 -0700

Merge the 2 GUI's.

This might be summarizing too much, but I've been cranking code better if I don't focus on updating the blog, and since I am posting my progress every time I finish something, why not use that :) Next week will have clearer posts, I hope :D

Gravity Shift Progress - Monday 11/8

On Monday, November 8, 2010 0 comments

Kinda fell behind this week. A lot, a lot, a lot of work has been finished though which I think makes it worthy.

Thursday Progress-
Added a GUI to our backend. Extremely simple but most of it worked as expected, most of the time.
This was shown in class, and was taken very well(I was actually suprised).

Since then, I've been cranking out features. You can now create entities and change their properties. It adds just fine and saves all of this info perfectly. We can also change the background now, there is cleaner drawing, beautiful zooming in and out, selection for single-select and multi-select which draws a selection indicator, better entity movement, and more. I've been just cranking code(as I know my time is little), but its turning out very well and so I'm motivated to keep pumping out more code.

The next plan is to work this code into Jeremy's front end, which shouldn't be too hard since he gave everything the same name, or nearly the same name. Just need to find time to do it.

Gravity Shift Progress - Tuesday 11/2

On Tuesday, November 2, 2010 0 comments

A ton of progress this week, but still not as much as I hoped. I have been working on the internal parts of the level editor, and have reason to believe that adding one or more entities, removing one or more entities, selecting one ore more entities, copy one or more entities, cutting one or more entities, pasting one or more entities, undo any of these operations, Redo any of these operations, and some pixel to grid conversions. There is other stuff but I can't remember all of it...It was a lot of logic and a lot of hours that I pushed into it. I've also been managing the Git stuff, and helping everyone who has issues(merges conflicts have been issue lately, so I'll be writing a reference for that soon).

Waiting on Jeremy's front end before I can test this stuff, but its moving nicely on my end.

Gravity Shift Progress - Thursday 10/28

On Thursday, October 28, 2010 0 comments

Not too much to report today. I've had a pretty busy week with CS4400 and life in general, so I didn't get much done outside of class. Here are the things I did do(including class):

Got the team up to speed on the level editor design. It went pretty well, but we won't know how good or bad the design is until we jump into the work(which I am hoping for a full lab day today so that we can collaborate on the ideas.

All of our CS guys have been able to update to git, which I have fully merged yesterday. We also uploaded the level editor into our project, so the group should be able to easily download the code without any real work. I think that now we have a firm base on workflow, we should be plowing through from here on out.

Lastly, I reviewed the Evil list a little bit. I do believe that its a doable list to work around but some of the things that we have to guarantee really sucks(like absolutely no bugs, whatsoever). I guess we will see how this goes but I plan on bringing it up in the Stand-Up meeting.

Gravity Shift Progress - Tuesday 10/26

On Tuesday, October 26, 2010 0 comments

Several things have happened.

First we've made some major progress on git. Casey, Nate, and Jeremy have both been able to push updates to the game(nothing major, yet), and all have said that its easier than it seems(which is how I feel too). This gave me an opportunity on learning how to merge the code, as well as resetting the HEAD of the current branch, along with editing remote branches(I feel these are all important for someone who is running the entire system).

On top of this, I wrote a design doc that further defines our level editor from the original definitions. This can be found here:

https://docs.google.com/document/edit?id=1moFbTO3htIemgeUpa1-shcrvQ-NwvlS5rE-fLFVWfR4&hl=en&authkey=CP760_gN

Me and Nate have started with writing the code, and have defined a Level(integrated with the Editor Interface that I mentioned in the doc), and an Entity. This is all minus the ability to import and export, as that is still up in the air on agreement with the group.

More on this later.

Updating the Contact List Tutorial

On Wednesday, October 20, 2010 0 comments

Do not attempt this tutorial before I demonstrate on Thursday(10-20-10)

Ok so the task here in this tutorial is to continue to help you get familiar with Git, by actually making changes in the repo. This is assuming you have set up Git already(See here) and that you have an understanding of VIM or have changed the editor to Notepad++(See here).

Disclamer:
As I know someone is going to run into the problem, I thought I would warn you: be sure that your msysgit is INSIDE of your Gravity-Shift folder before trying these commands. This is important because it won't work otherwise.

Okay, the first thing you need to do before you make any changes(to avoid merge conflicts) is to fetch the latest data from MY Git repo. To do this you do this command:

git fetch upstream

This will get all the newest files and changes that the team has made in a whole. At this point, you have these changes locally, but you have not applied it to your own version yet(so if you opened one of the changed files, you would not see any changes). To receive these changes, you must merge the code with this command:

git merge upstream/master

Stop for a second
Why "upstream/master" ? Well, what we are saying is that we want to merge the code from upstream's master branch. If we start using lots of branches(ones for specific bugs, ones for stable releases, etc) this will be important to understand, but for now always do "upstream/master"

We now have the newest code on the computer, which we should now see "ContactList.txt" in the Gravity-Shift folder. Open this and add your contact information into it. Do not forget to save.

The next thing you need to do is commit your changes. Simply do this command:

git commit -a

Which will prompt you for a commit message. This is REQUIRED, and would be best if you do clear messages so that your code is easier to review. The correct format is always "Present Tense" sentences, using words like Add, Remove, and Change instead of Added(Adding), Removed(Removing), and Changed(Changing). Try to be persistent on this format.

After you committed, you need to push your changes.

Alright, woah...
What is the difference between commit and push, and why do I need to do both?

Commit finalizes any local changes on your own local distribution. This means what ever changes you make are official on your own hard drive and that's it. Push, on the other hand, copies those changes into your Github repo(the one online) so that it can be shared with the rest of the team. It is very important to understand that these are separate things, and that committing does not always mean that you need to push as well. You should always commit any changes on a regular basis, but you should only push when you are ready to share with the rest of the team.

So to push your local changes to your online repo, use this command:

git push origin master

Ahh, another weird command
Calm down, we are just saying that we want to push our changes to origin(which is our personal repo's) on its master branch.

VERY LAST STEP!!!!
Go to my repo(See here) and in the upper right corner you will see a button that says "Pull Request" . Press this button, and fill in the popup box with your changes(same format as commit messages) and send it off. I will then be able to take your code and merge it into the main repo so everyone can receive the changes.

VIM text editor instructions

On 0 comments

So, while using msysgit, you will more than likely end up using VIM to write text at least once(unless you change it, which I will tell you how to do that at the end of this tutorial). A good example of when VIM is required is during a commit. The editor is extremely difficult to understand, especially without any instructions, which is exactly what this tutorial is for.

Lets make an assumption that I just made some change to the code; how bout I added the ability for the player to change colors. Once I had the job finished, I would commit:

git commit -a

This would immediately start the text editor, VIM. It would have a print out something like this:

(Your cursor should be here)
#############################
# You made a change that needs to be committed
# The following files have been changed
# (To reset to head, use git reset HEAD)
# WindowsGame1/Player.cs
@
~
~
~

Or something like this at least. Your cursor should be at the very top, if its not, you'll need to move it using the arrow keys.

1. Press the letter i to enter Insert Mode.

2. Type your message: Add player ability to change his color

3. Press the Escape key to exit Insert Mode

4. We now want to save. Type :w (do not forget the : in front of the w) and press enter

5. To exit VIM, type :q (do not forget the : in front of the q) and press enter

Your file will then report to git that you are done writing the commit message and are now ready to commit.

As a final reference, to start VIM with a file(it will be a new file if it doesn't exist yet) type this command:

vi

To difficult?
Yeah I agree, that's why I went in search of a different solution, which I will share with you. Be sure you have dowloaded Notepad++(found here) and type this command in msysgit:

git config --global core.editor "'C:/Program Files (x86)/Notepad++/notepad++.exe' multiInst -notabbar -nosession -noPlugin"

So the git config --global core.editor tells git you want to change the text editor. The 'C:/Program Files (x86)/Notepad++/notepad++.exe' is the location of Notepad++ so it might be different for you. You will have to browse your computer for the Notepad++.exe.

Gravity Shift Progress - Monday 10/11

On Monday, October 11, 2010 0 comments

As I mentioned, I was tasked with the opportunity to define what a "Physics Engine" would need, and how we would define it. I came up with this here:

The physics engine is built with 3 levels.

Top Level - Gravity Direction Control
---Attributes

* Gravity Direction

---Functionality

* Change Gravity Direction

Second Level - Physics Environment
---Attributes

* Gravity Magnitude
* Terminal Speed
* Gravity Erosion
* Directional Magnitudes


Third Level - Physics Objects

---Attributes

* Gravity Force
* Additional Force
* Velocity
* Position

---Functionality

* Update itself
* Load itself
* Collision Detection
---With other objects
---With the world
* Enforce Terminal Velocity


This is actually all subject to change(and will, most likely)

As a test of the theory, I rewrote some of the engine to reflect this model, and it works pretty well. Most changes that will need to be made is going to be initiated by what the rest of the group decides on their definitions(things like the level definitions and such).

Gravity Shift Progress - Friday 10/8

On Friday, October 8, 2010 0 comments

Alright, we are finally starting to make progress on the good stuff, which makes me very excited. The first exciting thing is that we have just about everyone understanding, at least the basics of git. The art people are going to struggle a bit with this, so I'm working on a new tutorial that uses TortoiseGit or maybe some other GUI that makes it easier on them. Hopefully I can find a good middle ground for them.

Actually, what I was thinking was that maybe we should break our project up for the art people. In the main repo(the one that contains all the programming) add the Content folder to the .gitignore file. From there, make a second project that just contains the Content folder. This way, the art people would not get any of the extra files that they would normally be attacked with, and we could just pull from their repo when any changes are made. I'm still on the edge about it because I'm pretty worried about how well that idea would even work, but it should definitely keep things as abstract and seperate as possible which is a good thing.

The second thing I'm excited about is that we gave out jobs on Thursday, in which the members of our team have to break up all the generic ideas that we came up with for a BETA version of our game. This should be what makes our product backlog and I feel like its going to really help move us forward by the time we meet up again on Tuesday. I've started us a wiki at:

http://github.com/DizWARE/Gravity-Shift/wiki/Gravity-Shift-Development-Wiki

so that anything we come up with is always readily available to all of us at anytime. As for my task, I was given the Physics Engine since I've already brainstormed on the many things that a physics engine would need.

Gravity Shift Progress - Catch up(10/1 - 10/6)

On Wednesday, October 6, 2010 0 comments

So I haven't updated my blog this week which is a big oops because I have actually done quite a bit over the weekend, so this will actually go over both the progress I've made between Thursday(10/1) to Tuesday(10/4) and the progress made between Tuesday(10/4) to Thursday(10/7).

Thursday(10/1) to Tuesday(10/4):

Sat down with the code again. The problem with the original physics engine prototype is that if I were to add 10 physics object into the environment, they should all react exactly the same in that environment. So I restructured a bunch of the PhysicsObject code, and have made a new PhysicsEnvironment code that gets passed to the PhysicsObject as a reference. Now, if the player changes values in the PhysicsEnvironment, then any other PhysicsObject that has that same environment will also experience the change. This method may be subject to change(maybe PhysicsEnvironment 's own all PhysicsObjects that are within it, and update each object every time the game updates).

During class: We brainstormed what needs to go on our backlog, which I think came out fairly well. The list is being managed by Curtis(Scrum Master), and we also talked about a very important aspect of keeping things together; Source Control. We decided to use Git, which I was actually the only member who has used Git. I managed to convince everyone on it, and our tasks to do by Thursday is to learn the system.

This morning (Wednesday 10/5) I wrote a tutorial for everyone on how to get Git up and running, and how to use it. Link is here:
http://dizgames.blogspot.com/2010/10/git-instructions-for-team.html

Git Instructions for the team

On 0 comments

Also, just a note(I'll probably bring this up thursday), as just users of the git repo, this should be your process for setting up(using a command line git program):

Step 0: Create a Github account

You need a github account before you can do anything. Go to github.com to get it

Step 1
: Set up your SSH keys

You'll be pulling your hair out if you miss this step. Be sure to read it carefully. This is assuming you are using msysgit(which I still recommend for the cs people)
http://help.github.com/msysgit-key-setup/

Step 2
: Fork Project

Forking the project is pretty easy. Go to http://github.com/DizWARE/Gravity-Shift/ and click the "Fork" button near the top on the right side

Step 3: Clone Repo

git clone git@github.com:
(Your Github Username)/Gravity-Shift.git

This will automatically add this git repo to as your remote upstream/downstream, under the alias "origin"

Step 4: Add the original repo for fetching the newest updates

cd Gravity-Shift
git remote add upstream git://github.com/DizWARE/Gravity-Shift.git
git fetch upstream


This will add the main git repo for global updates, under the alias "upstream"

At this point, you should not have to do the Steps 1 - 4 ever again(unless something happens). From here on out should be your update cycle for anytime you make any changes.

Step 5
: Make modifications

Adding/removing code or any files(images and such) will do this

Step 6: Committing your changes

git commit [Filename/s]
to commit one or more file

or

git commit -a
to commit all files

This will immediately start the default text editor(usually 'vi') to add a commit message.
Always, always, always fill out your commit messages, so that when you try to update your code on the main repo.
These commit messages should all be in present tense(important) and should start with a brief description on what is changed, and then a list of all changes. Here's an example after I added the ability jump in the physics engine, and the controls for it in the control scheme(hypothetical):

Add the ability to jump in the game
-Add the physics definitions for jumping in the physics engine
-Add the controls for jumping in the control schemes

Step 7: Push updates up to your fork

git push origin
(branch name)

(branch name) is usually master if you have not created and checked out a different branch. So basically, if you don't know, use 'master'

Step 8: Sharing your updates with everyone

In github, go to http://github.com/(Your Github Username)/Gravity-Shift.git and click the "Pull Request" button in the upper right hand corner

Step 9: Getting peoples updates from git

git fetch upstream
git merge upstream/master


Lastly, for those who are still doubting on the WHY of git, take a look at this video of Linus(inventor of git, and also the inventor of Linux): http://www.youtube.com/watch?v=4XpnKHJAok8
Skip ahead a bit, because he gets into the details near the end.

Gravity Shift Progress Report Wednesday 9/29

On Wednesday, September 29, 2010 0 comments

Yesterday, we presented and it really well. Thd EA guys gave us a handful of suggestions, including not going to extreme with messing with the enviromental variables, and to be sure to convey this to the player in a very clear message. They also said that we should ditch any thoughts on a story, stating that we would end up dragging down the experience. The also said that the gravity change should apply to other objects that make the experience a little more challenging, without stepping out of the realm of reality.

I fully agree what with what they said and feel it is very doable with the system I have already implemented. I'm very excited to see the results on thursday

Published with Blogger-droid v1.6.0

Gravity Shift Progress Report - Wednesday 9/22

On Wednesday, September 22, 2010 0 comments

Yesterday, our presentation went very well, and seemd to be very well received. We were asked to do a simpler level because watching our more complicated level is too overwhelming to allow the watcher to really catch the gimmick. There is only a minimal number of changes we need to make including the art(wasnt all quite as themed as we want for the panel). we expect to have 2 demos available for the panel to test, which i feel will add to our brownie points with the board.

So far i have added a new level to the game, and have recorded it, though i think I will have to rerecorded once I get our final art

Published with Blogger-droid v1.5.9

Gravity Shift Progress - Tuesday 9/21

On Tuesday, September 21, 2010 0 comments

Today, we are pitching our game.

This is the video of what we got:
http://www.youtube.com/watch?v=YcyNMpq_gKg

Since this video, I fixed a couple things, including the collision, some sprites, and some level design.

I also have prepared a demonstration with my more flexible physics engine. It allows the player to change all the physics environment settings on the fly, and actually feel the difference as they play. This prototype reports the values on screen so the player can actually compare whats going on. I want this to mostly be demo...something people will have to experience to fully understand.

Gravity Shift Progress - Friday 9/17

On Friday, September 17, 2010 0 comments

I spent some time on a couple things: First and most important was the addition of levels that fully scroll around. This means we are no longer restricted to having a level that is just constructed for what is initially on the screen. This includes parallax scrolling as well, for a 2.5D feel. I also added a gravity direction HUD, that replaced our big background arrow that we had. This is something we talked about yesterday, so I'm glad it went in so easily.

I also worked on my physics engine(the one we aren't using) and it is working now. It doesn't respond correctly to the ground, but the physics in the air is much better than the one we are using and is easily customizable. I tested some changes like higher gravity magnitude in certain direction or all directions, changes in terminal speeds, and changes in gravity erosion factors. This is still a proof of concept, so I won't put a ton of time in it, but we may be able to use some of the concepts for our final pitch.

I plan on making a new type of tile called "Deadly" so that we can add traps into our maps, allowing us to create challenges for the player, making it a true prototype of what we want to make.

Gravity Shift Progress - Thursday(before class) 9/16

On Thursday, September 16, 2010 0 comments

Not much to report today. Curtis also worked on a physics engine that used the platformer starter kit as the base. Mine still is in the process of getting to work, where as his works and is ready to improve. I'm thinking that once we get passed the prototype stage(its so obvious we will :D), we could replace this "prebuilt" setup with mine, which actually will have a lot more options and flexability.

We talked about an art style, which we have concluded that a stencil like environment would feel very inviting, and promote the simplicity aspect to it. We want to use colored stencils so that things don't blend together like they usually do on sketch art games, but the hand drawn feel is the aspect we want to capture. We also decided that we really only need to add a scrollable camera to make the games strong points really shine. We've also discussed what we might do to create these levels, simply. I was thinking it wouldn't be too hard to make a tile creator that visually let you drop down the tiles and parses it into the required text. This would also just be a temporary solution so we would get through the prototype, with plans of something more resourceful later.

Last thing I did was update Curtis' game so that no matter what direction you are, ground is ground and reacts as such. Not much but it feels more realistic now, which I like :)

Gravity Shift Progress - Monday 9/13

On Sunday, September 12, 2010 0 comments

I started writing the physics engine for the game, on Saturday, which was stemmed by a seeing a XNA 3.1 Physics engine that I thought about actually using. I began thinking of things a little more abstractly than I was before and procured a clear shot idea for how a specific engine might work.

The design aspects is pretty simple and go like this:

-A physics object in the realm of a gravity induced location is required to:
--A) Load itself
--B) Draw itself
--C) Update itself
I felt this was mainly required for an object that exists in a XNA game in general
To be a "physical" object it must have certain attributes:
--A) Velocity
--B) Directional Gravity Force
--C) Terminal speed(To limit velocity in any direction)
--D) Ability to check for collisions(against the world and other physics objects)

This is still a work in progress and I have yet to test if it works, but the code is very clean(something I've been stressing to myself). The class is abstract and is planned to be extended for things like Player, or Enemy(if we decide for some), or ForegroundObject(if we decide for some).

I also wrote a control scheme for the game as an interface. No matter that control scheme that is used(gamepad or keyboard), they should be tied in to the general controls of the game. From these I made two classes that implement the scheme(KeyboardScheme, GamepadScheme) that define the controls for those schemes. This should make it easy for us to support the different input devices for the player, depending on his medium for playing.

Theme and Goal: After class 9/9

On Thursday, September 9, 2010 0 comments

Our brainstorm and discussion can be found here:

We will be continuing on the topic over the weekend.

Gravity Shift Progress - Thursday 9/9

On 0 comments

On Tuesday, I proposed an idea of how we could easily create a full level quickly(maybe multiple levels), by programming a way to scan an image file with color codes, to define the collisions that the player may experience. I found a tutorial that did just this at: http://www.xnadevelopment.com/tutorials.shtml in which I have modified so that you can plug in new maps easily(I made 3 but its extremely easy to add more), the ability to pick levels, and have inserted some new color codes: Blue is player starting point(which the initial scan is something I added), Red is deadly spots(kills the player), White is walkable land, and Black is unwalkable. It works perfect and could easily be implemented towards the actual prototype that we will be working on.

Top 9 Decided - New Teams

On Tuesday, September 7, 2010 0 comments

The "Per-Game" teams have been decided, and Gravity Shift(the game I pitched) has been picked as one of these games. My game recieved the highest number of votes out of all 31 games that were pitched.

We are now required to get in our teams and discuss what we want to do with the prototype(which is due in 2.5 weeks). In our discussion, we went over the document and decided what was really weak or really strong about it and what needs to change(which wasnt much). We came to the conclusion that most of these things would be fairly clear once we developed the prototype.

My task before Thursday is to set up and invite everyone to a google groups account and email the tasks to everyone. The CS students are to find things that can be ported into the prototype easily so that we can get something that works really quick and the film students are tasked with deciding on some themes to define the visual element of the game. I plan on also requesting that everyone come up with some ideas with a level...things that would be fun and challenging for the player so that we can come up with a clear idea with a prototype level.

I plan on looking up a way to read in a picture and based on the pixel color, decide if it is walkable, deadly, or unwalkable. This way we don't have to hard code the levels, we would just need to define what each pixel color represents.

Published with Blogger-droid v1.5.8

And it came to pass, that a great game idea was born

On Saturday, September 4, 2010 0 comments

So it was a beautiful thing, sitting around at work spit-balling some "not-so-genuine" ideas, when BLAMMM, it hit me like a jackhammer. I came up with a delicious(Yes, this is the right word for this) idea for a XBOX360 Indie game. Here's the pitch I wrote up:

CLICK THIS LINK TO READ THE PITCH

I pitched it in front of class on Tuesday, so its no guarantee that it will actually be picked up, but I thought it went fairly well and it did stem some interest from the other students.

Yesterday I voted for 10 games that were pitched, including my own. I went based directly on how much work was put into their presentation, and if I didn't remember their presentation, how well thought out their document was. I am extremely hopeful that everyone realized my enthusiasm for my game, but I think all the games were good and should be an extremely valuable experience no matter what is selected.

Stay tuned to find out the Top 10 next week :)

Powered by Blogger