Expanding Game Design

[rileyw]

Requesting that https://github.com/Deceth/Battle-City/wiki#game-design be expanded upon with the core gameplay and/or the basics.

@Deceth mentioned in #19

We want to add layers of strategy, while sticking to the basics.

To do that, new items should stick to the existing recipe:

• build a factory
• it makes items
• you pick the items up,
• you use or drop the items

This is the game design content that we need to capture and develop upon to revive the game.

Also need someone to rally the "veterans" to contribute to this task since I imagine @Deceth shouldn't have the sole opinion on the topic. :laughing:

[rileyw]

@Deceth How much of the original NES Battle City influences the basics? I have been watching game play videos from the original Battle City, and there could be some interesting concepts adapted to the current game design.

[ndizazzo]

AFAIK There's very little in common with the original NES game. The whole base-building concept is an addition, and it's a level based arcade shooter. The only real common things are that they both have tanks. I'm sure Battle City is a throwback to the old NES game, but a lot of the basics seem vastly different.

[rileyw]

I noticed that the sourceforge.net Battle City project referenced the NES game as an inspiration source, but I was wanting to verify that statement. You are right that both games have a limited set of attributes in common such as name and player unit is a tank. How much of a gameplay gap is there between the original Codehammer version and our current version?

[ndizazzo]

Again, AFAIK when Remote and I and Mark were developing this originally, it was a 1 to 1 clone of the gameplay in the last version of BC by Codehammer. Since then Remote took it and ran to the finish line, still with the 'clone' mentality in mind. Since then I think Deceth has added several things relating to game modes ( dodgeball ), changed a bit of the UI, and added a few items.

[rileyw]

What design documents were y'all using for the 1 to 1 come development?

On Wednesday, July 24, 2013, Nick wrote:

Again, AFAIK when Remote and I and Mark were developing this originally, it was a 1 to 1 clone of the gameplay in the last version of BC by Codehammer. Since then Remote took it and ran to the finish line, still with the 'clone' mentality in mind. Since then I think Deceth has added several things relating to game modes ( dodgeball ), changed a bit of the UI, and added a few items.

— Reply to this email directly or view it on GitHubhttps://github.com/Deceth/Battle-City/issues/63#issuecomment-21501837 .

---

Riley Wills Programmer/Analyst Computing Services Abilene Christian University

[ndizazzo]

There wasn't any public doc. We collectively chatted about core mechanics from what we remembered. Between the 3-4 of us, it was pretty much everything.

[rileyw]

Very helpful! I would really like to see the core mechanics / game rules documented before new features or revisions are created. From my background with the game I have little idea about the core mechanics; therefore, I can't decipher between feature or bug in the game code. LOL

What ever happened to the other developers anyways?

[ndizazzo]

Yeah - a good first step is outlining how things should be working and the design of the game. That'll help identify any bugs that need to be addressed before they're built on top of.

[rileyw]

@Deceth or @ndizazzo Do either of you have a preference on the method for documenting/outlining the game design? Using a combination of branch.com and hackpad.com we could collaborate and work through the process.

[ndizazzo]

no preferences here - though - does GitHub not work for this kinda thing?

[rileyw]

GitHub works and it'll reduce the number of systems we're using. :+1:

What should be the protocol for documenting the game design? I'll propose the following:

1. Continue to use existing game design wiki page
2. Open GitHub issues to cover game design topics
   • Should we limit the number of design topics we have open at one time in order to focus conversation and obtain definition?
   • @Deceth We will need you to label issues accordingly
3. Discuss design topic in issue, and arrive at agreed definition
4. Upon agreed definition, the game design wiki page will be updated by issue commenters to reflect this definition
5. Issue is resolved by using "Resolves #{issueNumber}" in the wiki page edit message

Other protocol proposals or adjustments to this one are requested.

[ndizazzo]

I think that's a fair protocol to follow. As a pre-warm step, we should stub out as many articles on the wiki as we can, and continue to do so as think of them, one per topic. IE: Buildings, economy, items, movement, etc...

This works because I usually have little bits of time between builds where I can write up small chunks of gameplay notes.

[rileyw]

Great idea and I am curious if we can compile a template for these stubs so we can a standard set of information that we can follow from stub to stub.

[Deceth]

I'll definitely be around contributing in the issue topics :)

As for templates... I'm not really sure off the top of my head. Maybe we can pick one topic to start as a new issue, work on it, and once we get to the point of transcribing the info to the wiki, we'll have a better idea of what we need as a template going forward for the others.

[ndizazzo]

Yeah honestly, lets just wing it, and forget filling in a template. Too much process/formality kills momentum in my experience.

[rileyw]

Reference document: http://www.gamasutra.com/view/feature/130127/design_document_play_with_fire.php