Sounds really exciting!

I have a question about one of the rules:

According to the rules page linked to in the first post, "... you may use code, art, and audio that you or others may have made in the past (the explicit limitation is that you may not use existing game logic (i.e. you may use libraries and engines, but you still have to actually make the game during the 7 day period))".

My question then is this: where does boundary lie between "code that I made in the past" and "game logic"? For example, if I find that I want my entry to have an inventory, would it be acceptable for me to rip out and retrofit the inventory system (specifically, it stores items, displays them in a grid, and allows rearrangement and selection of them) from another game of mine? What about my physics character controller?

The extremes seem fairly clear: I would presumably not be allowed to use, say, an RPG combat mechanic that I had previously created, and would be allowed to use the Bullet physics engine. It's the cases in between that I'm uncertain about.

I apologize about my delay in response, this weekend was a bit hectic and i didn't have much time to check up and compose an appropriate response.

The entire idea of that rule is to allow frameworks/api's/engines/graphical/musical assets that already exist to be reused, this is partly because it makes things easier when you only have a week to work on the game, but it's also because honestly we have no way to say you didn't build that super amazing thing in a week. we have no way of knowing if you really only keep yourself to a 3 man team, or forcing people to only work on their submission in that 7 day period. An skilled artist could potentially find some obscure open source game and reskin it to match our theme if they really wanted to. at the end of the day, the idea is to make the game logic itself entirely from scratch. However most of these rules we can't actually ensure aren't being broken, it's the spirit of the competition that we hope will prevent people from breaking any of the rules. so, if you think that an inventory system is too close to being gameplay logic, then re-write it from scratch, or you can consider it generic enough to be apart of an engine and/or framework library. honestly each person is going to have to use their own best judgment on what constitutes breaking one of the rules of the competition, and where they draw that line.

I have a question about one of the rules:

According to the rules page linked to in the first post, "... you may use code, art, and audio that you or others may have made in the past (the explicit limitation is that you may not use existing game logic (i.e. you may use libraries and engines, but you still have to actually make the game during the 7 day period))".

My question then is this: where does boundary lie between "code that I made in the past" and "game logic"? For example, if I find that I want my entry to have an inventory, would it be acceptable for me to rip out and retrofit the inventory system (specifically, it stores items, displays them in a grid, and allows rearrangement and selection of them) from another game of mine? What about my physics character controller?

The extremes seem fairly clear: I would presumably not be allowed to use, say, an RPG combat mechanic that I had previously created, and would be allowed to use the Bullet physics engine. It's the cases in between that I'm uncertain about.

Disclaimer: I am not a judge so it doesn't really matter what I think. This is just an opinion.

An inventory system is walking a fine line. If the inventory is complex and/or an important part of the gameplay then it must be gameplay logic, as I see it. And therefore ought to be written during the week. Personally I have a hard time imagining an inventory system that is not a first-class gameplay element.

A physics character controller, on the other hand, I think is okay - as long as it's your traditional sliding bubble with maybe some special handling for slopes and stairs. Such things are generic and reusable. A different choice of physics framework or use of a high-level engine and you may have even been provided with one to start with.

Regarding my "code-reuse" question, thank you all for your responses.

Indeed, I asked in order to keep the spirit of the rules: in order to hold to the spirit of something, it helps to understand that spirit.

so, if you think that an inventory system is too close to being gameplay logic, then re-write it from scratch, or you can consider it generic enough to be apart of an engine and/or framework library.

I'm inclined to lean towards re-use, actually: it's my standard practice to rip out useful parts of previous projects and reuse them, modified as called for; in some cases these develop into properly reusable modules. Indeed, this is perhaps part of the cause of my uncertainty: I find that most elements that aren't very specific to a given game are potentially reusable to some degree.

For example, I've been tinkering with a "pencil illustration" shader of late; I doubt that I'd have much difficulty in finding a place for it somewhere, despite it being a fairly specific aesthetic.

I apologize about my delay in response, this weekend was a bit hectic and i didn't have much time to check up and compose an appropriate response.

Not to worry: busy times come up, and it was hardly a long wait.

An inventory system is walking a fine line. If the inventory is complex and/or an important part of the gameplay then it must be gameplay logic, as I see it. And therefore ought to be written during the week. Personally I have a hard time imagining an inventory system that is not a first-class gameplay element.

A physics character controller, on the other hand, I think is okay - as long as it's your traditional sliding bubble with maybe some special handling for slopes and stairs.

From my perspective, either could be rather generic and not part of the core gameplay, or rather specialised and a focal gameplay element.

For examples: A very generic character controller could be used in a great many games, from shooters through RPGs and adventure games. Similarly, a simple inventory system could be used interchangeably by any of those (the latter two genres especially). On the other hand, the character controller for a game like Assassin's creed is probably fairly central to the gameplay, and has features specific to that gameplay, while an investigative mystery adventure game might use its inventory extensively, allowing the player to closely examine, combine and draw connections about various objects and clues. (And naturally, there are cases in-between: my current character controller has at least one feature that I'd probably remove for a shooter in the vein of Serious Sam, for example.)

Honor is going to play a huge role in this. The only think keeping you honest is yourself. The other way we can track "Progress" is by watching what happens via their livestreams, post updates, content updates, and journal entries.

Actually, that might be part of the answer itself: perhaps, in my first post in my project thread/journal/whatever, I should simply declare what components I'm reusing.

On another topic: So, can I take it that we're not starting in the first week of September, then? :P

Wait... wait... You've all started, and simply haven't told me, haven't you? ;P

"midnight September 22nd to midnight September 29th. all times are EST GMT -5." - first post in this thread (it's been updated)

Ah, I hadn't seen the update--thank you for pointing it out!

[edit] Just to double-check: the midnights are, as seems to have been the case in the previous competition, the start of the stated days, not the end: that is, "midnight September 29th" is one hour before "1am September 29th", not "1am September 30th"--is that correct?

[edit] Just to double-check: the midnights are, as seems to have been the case in the previous competition, the start of the stated days, not the end: that is, "midnight September 29th" is one hour before "1am September 29th", not "1am September 30th"--is that correct?

Correct.