Welcome to Update 1! On the agenda:
1) Design philosophy
2) Name suggestions (Open until 5PM PST on Wednesday, Nov. 13)
3) Status report
4) Looking ahead
For those of you just joining us, last week I decided to get the ball rolling on making a Giant Bomb themed adaptation of WindJammers. The original plan was to have a design document posted today, but I've decided to heed the advice I've received from some GB community members and forego a long preliminary document in favor of more "on-the-fly" iterative design. Since so much of what will make this game is the feel of the action, it doesn't make a lot of sense to try to commit to design choices regarding controls, character differentiation, etc. when a lot of those those aspects will live and die in how well they are executed. However, I have cooked up a design philosophy, a set of goals that all other design choices should serve. They are...
Section 1: Design Philosophy
1) Accessibility - low barrier to entry. New players should be able to quickly feel comfortable using and understanding all gameplay elements, including characters, abilities, controls, and level objects.
2) Transparency. Players should be provided with clear real-time feedback to ensure that they understand how their choices impact their in-game success. Random or "hidden" elements should be minimized or removed entirely, and audio-visual feedback should be clear and immediate.
3) Risk-reward. Players should be encouraged to take chances that can help them seize the initiative in a match. Design should favor aggressive play and calculated risks over passive "safe" play.
When combined, these goals form the driving tenet for the game's design: players should be playing their opponent, not the game. That is to say that players should be spending their time thinking about positioning and head games, not struggling with the control scheme. They should be encouraged to use the full suite of options at their disposal, not just rely on a single move or tactic.
So that's the plan. The trick will be enhancing the core WindJammers experience to create a richer metagame and more varied matches without adding so much that it loses its pick-up-and-play sensibility that makes it a great spectator sport. WindJammers actually has a ton in common with Divekick, as both are stripped down, fast-paced 1-on-1 showdowns, so don't be surprised if I take a few design cues from Iron Galaxy.
Section 2: Name Suggestions
Internally, I'm using the name SummerJammers in honor of the late great Ryan Davis, the eternal King of the Summer Jams, but I think now is the time to open the floor to folks who would like to suggest a name. Just suggest a name in the comments, and if you see a name that you like that hasn't already been seconded by another user, then quote the name in a reply with "seconded." If folks could edit their suggestions when possible to indicate they've been seconded, it will save us duplicate seconds and help keep things orderly. Get suggestions in by Wednesday at 5PM Pacific Standard time and I will run a poll over the weekend to get us a winner.
Section 3: Status Report
I spent the early part of last week trying out various development tools that people suggested, and after a few underwhelming candidates, I fell madly in love with XNA via MonoGame using Samarian Studio as my IDE. For the uninitiated, that means I'm using an open-source version of Microsoft's XNA game tools (which they recently stopped supporting). For the target platforms of PC/Mac/Linux, things should be pretty straightforward, and there's built-in support for mobile platforms as well, though there may be some minor coding and design changes needed (which is something I look forward to outsourcing to you fine folks).
Once I decided on MonoGame, I familiarized myself with XNA's drawing and I/O methods, which were ridiculously easy to get up and running. This is my first time using C#, so I spent a good chunk of time reading up on best practices with regards to naming convention. Most of my coding experience is in Java, C++, and Python, and I was surprised by how little C# resembles the burning hellscape that is C++ despite the similar names. It's a much easier language to use, though I must say I'm not a big fan of not having to explicitly refer to an object member using the "this" keyword" (I've made a habit of always using it, and when I open the doors to community contributions, the style guide will remind you to always use it, as well).
Speaking of community contributions, let's talk about how I'd like all of that to work. As I mentioned when I announced the project, I'll be handling the core of the game since I'm trying to bone up on design and coding skills. Once I have a working prototype of the core gameplay (two things throwing discs at each other with local 2-player action) I'll start asking for folks to volunteer as either contributors or department leads (in areas such as art, sound, music, networking, etc.), and my role will largely shift to a managerial one (though I'll still be tweaking gameplay and working with anyone who wants to help with testing). Folks have been asking about putting the project up on GitHub, essentially making it open source, and while there are no plans to do so in the near future, I'm amenable to doing it down the line once the project has legs to stand on. In managing a project like this, consistency trumps quality, so I don't want to open the doors until there's a strong "voice" established and guidelines are in place to help keep code readable and flexible.
In fact, most of the actual coding so far has been organizational in nature. I've mainly been working on scene management tools with the objective of making everything as modular and independent as possible. I've been making good use of XNA's "services" (which experienced coders will recognize as essentially being global singletons). For the less code-educated, these services provide a way to assign certain types of events to be handled by particular objects. So for example, I've created a class of objects called Scene and an object called a SceneManager to deal with changing, running, or stacking scenes (so, for example, if there's a menu you access by pausing the game, it can just hold the game scene off to the side while you deal with the menu and then bring it back when you're done). The SceneManager handles all scene related events, so I've made the SceneManager class implement an interface called ISceneService, which just means that it's guaranteed to be able to handle any events that need to talk to an ISceneService.
The really cool part, though, is that I can use XNA's service framework to configure things such that if an object ever needs to handle an ISceneService problem (like the player selects an option that closes the current scene), all it has to do is shout "HEY I NEED SOMEONE TO HELP ME WITH THIS ISCENESERVICE PROBLEM" and the SceneManager will roll up and take care of things. The cool part is that it doesn't have to ask for the SceneManager by name - it just shouts that it needs whoever is in charge of scenes and waits for the service to send someone! When it comes to laying the groundwork for a project that will eventually have a lot of people working on it from all over, this is freaking awesome! If I end up needing to change the guts of the SceneManager class - or even replace it entirely with a new class like SceneOverlord - it won't affect anybody else. They just ask for the ISceneService manager and are none the wiser!
Section 4: Looking Ahead
So that's that! Not a lot of game to speak of so far, but that will change by our next milestone, which I'm setting to be two weeks from now.
Update #2 Due at 5 PM PST on Monday, November 25: Create a basic "practice" mode that can be used to test/iterate things like player movement speed, disc speed, controls, and basic physics.
Target features:
- straight toss in player-determined direction
- player "dash"
- basic player/disc hit detection
- simple "incidence = reflection" disc physics
Screenshots will be provided!
That's it for this edition, folks! Remember to get your name suggestions in by Wednesday! And mods, if these updates should go in Off Topic instead of General Discussion, let me know.
Log in to comment