Time Eater and Circle Cat Games have to update their list 

Sorry about that!

That's a good attitude to have.  I think that we just want to fully get across just how difficult it is to make a game, particularly one of a large scope, and especially if you haven't done it before. 

Don't give up on the making of your game, but perhaps you should put this one on the back-burner until such a time as you have some experience.  There's no better way to kill your dream game than to make it as your first game (my experience at least).

Ah, ok.
I interpreted:

Here's the deal. I have an area which is 720p:
1280x720 pixels..

As meaning you had actual image data that you were trying to minimize the size of.

If you are really concerned about space, make sure you deflate your bytearray before saving it to the SharedObject.

 

I second what Allen said.  You are making a game idea right now, not a game.  Since this is your first game, I'd suggest just digging in and starting to code.  I say this out of personal experience. I had 5 or so abortive attempts at making a game before I finally managed to finish my first one.  You are going to fail a lot before you make one game that you are proud of, so I'd suggest getting started right now.

I've only played around with it briefly, but I know the guys behind it, so I might as well give it a plug.

Akihabara is a good engine if you want to make 8/16-bit style 2d games.  It's somewhat akin to either FlashPunk or Flixel, only html5 not Flash.

No worries!

Even better, I just recalled the readUnsignedByte() method of ByteArray, spits out your byte exactly as you wrote it, no unwrapping needed!

Yup, this.

Although, why don't you just use a BitmapData?  I know you said that shaving off that 1 byte is important, but is it really?  Why do you think it is so important?  Mostly asking out of curiosity.

I honestly don't care about the Indie Stone one way or another, but "We're indies and this is what you get when you support indies," (Paraphrased, but essentially what they said in response to both the lack of proper backups and the lashing out by lemmy), really pisses me off.  It besmirches the names of all indie to try to make their fuck-ups look normal. 
I'm not saying that I haven't made mistakes.  All of us have.  But don't drag the rest of us down with you.

I also like to use

Code:

#pragma once

in addition to the #ifndef,#define,#endif enclosures just to be safe.

Don't forget to #define twice in case the compiler misses the first time. Just to be safe

Ok, I deserve that. What I really meant was, I like to use #pragma once; However, #pragma once isn't standard across compilers, so I still use the enclosures.  Overkill? Certainly, but it's what I do.

I also like to use

Code:

#pragma once

in addition to the #ifndef,#define,#endif enclosures just to be safe.

The following should be the code you want.

Code:

#ifndef _OBJECT_MANAGER_
#define _OBJECT_MANAGER_

#include <list>
#include <string>
#include "BaseObject.h"
#include "ImageManager.h"

typedef std::vector <cBaseObject* > ObjectVector;

class cObjectManager{
public:
 
  cImageManager* ImageManager;
  sf::RenderWindow* mainWindow;
  ObjectVector objectVector;
cObjectManager(cImageManager* ImageManagerPTR, sf::RenderWindow* mainWindowPTR){
ImageManager = ImageManagerPTR;
mainWindow = mainWindowPTR;
}

void CreateInstance(std::string type, int x, int y, std::string imgLocation){
if(type == "player"){
objectVector.push_back(new cPlayer(x, y, ImageManager -> ReturnImageFromFile(imgLocation)));
}
}

void UpdateAll(){
//loop to update all goes here
for (ObjectVector::iterator it = objectVector.begin(); it != objectVector.end(); ++it){
(*it) -> Update();
}
}

void RenderAll(){
//loop to render all goes here
for (ObjectVector::iterator it = objectVector.begin(); it != objectVector.end(); ++it){
mainWindow -> Draw((*it) -> Sprite)
}
}
};

#endif

 

Things you were doing wrong:

1) You were confusing the typedef of ObjectList with the defining of a member variable ObjectList. 
2) You were confusing the defining of the member variable with the instantiation of the member variable.  If you want to instantiate the vector with size 0, you should do it in the constructor; However, you don't actually need to do that. A standard container class member variable is always instantiated as being of size 0.
3) You weren't using the typedef for the iterator (the point that people were trying to make earlier with the introduction of the typedef).  This is probably a symptom of 1.

Tangential:

Make sure that you delete all of the instances that you create, a la:

Code:

~cObjectManager(){
for (ObjectList::iterator it = m_objectList.begin(); it != m_objectList.end(); ++it){
delete (*it);
}
}

Another tangent:
Is there a specific reason you are using a list?  Will you ever want to access a specific object?  If so, then a list is probably a poor choice. 

I'm going to use Adobe AIR, mostly because it's exceedingly easy for me to write and port the code around.

If you don't think your game can win, don't enter.

I don't know if my game can win. Should I not enter?

Nobody knows if their game can win, but you have to have some thought as to whether you think it can win.
Also, I want to make it clear, I think a person can enter as often as they wish, but a given game should only be entered once.

How about 'Hidden Boss'? It sounds a bit better than Secret I think

Yeah, 'Hidden Boss' sounds more like the standard phrase for this sort of thing (I'm thinking Akuma, originally).

@Fallsburg: I'm not going to take sides in this Fez thing, but I really disagree with that last thing. Many people create several games with potential, it'd just be horribly mean to disallow retries.

Why is it horribly mean?  If you don't think your game can win, don't enter. It's not mean, it's simple, and what every other similar competition in the world does (to my knowledge, I don't know of any other festival that allows something like this, certainly nothing on the importance of the IGF [in its respective field]).  Maybe the IGF should be honored for trying something new.  But maybe the IGF should see that it isn't working out as planned.

And this isn't necessarily about Fez (I got out my sarcastic meanness about that with my two jokes).  I just think this is a poor way to run the contest(I can start my own, I'm not in their shoes, whatevs).  Maybe my idea is even worse, and I just don't realize it, but I think the fact that this argument (in the rational, classic sense) is reason enough to doubt the way it's being handled currently)

*edited for grammar

i may or may not enter depending on if i can find the money -- perhaps i could offer limited pre-orders of SD for one day and see if that will cover the entry fee

@fllsburg - people don't usually enter the same exact game, they do work on it during the year so that it's improved each year. braid was entered once before it won a prize i believe

No, trust me I understand that people aren't entering the EXACT SAME GAME.  That would be silly.  But they are entering the same game in some manner of thought. 

Yeah, it's running a bit raggedly for me.

Trying my best to not take sides here, but if you don't think Fez should win, submit a better game? No competition can be as level a playing field as you want unless everyone starts out broke.

Yeah, it's almost like the competition is devoted to helping smaller developers get noticed or something.  /sarcasm

Or

So, the way to go about it is:
1) Create good looking art
2) Use the publicity of IGF to fund my game
3) Actually make the game
4) Use the publicity of IGF to market my game
5) Win
/yet still even more sarcasm

My stance is:
Release the best damn game you can.  If it wins, congrats, you've won your prize, please step to the side.  If you are unhappy that it didn't win the highest award, and you're going to make it better, etc. then that is too bad, you should have waited a year (x2,x3,x4, whatevs) until you were done.  If it doesn't win then try again in the future.  It's not that hard.

I think it should go further then not allowing finalists to re-enter.  I think no one should be allowed to re-enter.  None of this iterative bs.  Maybe this stifles creativity, I honestly don't know, but I don't know of another competition that allows people to enter the same work, year after year.

i think that's the most abuse-able system, and also boring (just hitting the air 1000 times to gain your strength or jumping 1000 times to increase your jump height is boring) -- i've never played a game where it worked out well

Agreed. In theory it is the perfect system, but it has never (in my mind) been implemented correctly.  I think the key would be to do it in such a way that grinding was impossible.  Just brainstorming here, but doing it in such a way that repetitive actions are noted and ignored (i.e. picking a lock once or 100 times has the same benefit) would seem to get most of the grinding out.

I also second Serapth's opinion that it should be data driven.  Your code should be the shell that runs things, not the content.

I would recommend Inform7.  It is an interactive fiction engine that lets you write in almost normal prose. It will let you write out your adventure/story without the need to write up an engine.