This Week
We’ve been occupied with work all week, day in and day out. It’s incredibly stressfull, but to be fair, we’ve been very productive in our respective line of work.
I’ve been mapping out, re-designing, adjusting numbers and writing on our Game Design Document. There’s so much to do, and so much to test when it comes to Game Design. It’s almost like a obsessive compulsion disorder; I can’t get enough of Game Design.
Spent quite a lot of time reading up on Level Design and Mechanics from Game Designers such as Randy Smith (Thief Series) (Link) and Hideo Kojima (Metal Gear Solid series) (Link).
Elements of the level can form “environmental tools” for the player. Which elements constitute environmental tools depends on how the stealth system of the game works. If the stealth system involves hiding in shadows, then areas of darkness and shadow are environmental tools for hiding. If the stealth system involves guards who can hear the player’s footsteps, then areas of quiet flooring are environmental tools for moving silently. Hard cover, such as support pillars and stacks of crates, are environmental tools for hiding behind. Sometimes a single level element can provide multiple types of environmental tools; for example, shadowy recessed alcoves provide both darkness and hard cover to use for hiding.
– Randy Smith
Progress
Anthon has implemented this great parser for a program called Tiled Map Editor, which enables us to build and test environmental sprites, location and level designs. This has allowed us to experiment with perspectives (Should the walls be tilted to allow more detailed walls or should they be flat top down?) and with scale (How big is to big when it comes to building rooms and corridors?).
We’ve also experimented with how the character should be steered. Anthon’s original solution was for the character to move Up and Down on the X and Y axis without regards to the player’s direction. I came with the suggestion that we’d try to make the controlling of the character smoother and more involving by always having the character moving towards the location of the mousepointer when the character is moving forward. We both agreed that this was a better choice, as the controlling feels tighter and a lot more controllable.
Our three artists has been hard to work, and we’ve implemented quite a lot of their sprites and animations in the game already (which is easily testable with out map editor. It’s a life saver). So all in all, the game is coming together now.
A mockup of the game in it’s current state, excluding the HUD that is photoshopped.
Next week
The game design document is due tomorrow, and as I’m writing this it’s just about ready to be sent in.
This means that tomorrow, I’m going back to code duty under the supervision of Anthon, our Lead Programmer. We’ll be working on getting our absolute bare minimum core mechanics in before next friday. If I thought that his week was stressfull, I can’t even begin to think about next week.
The goals we’re looking at hitting next week is for the player to be able to shoot and use at least one item. It is also paramount that we get a very basic AI working, a AI that reacts to the player moving into its Field of View.
Seeing as I’m the game designer, I’ll be doing my best to make sure that we don’t stray away from the cores we set out to create, and by Thor do I hope that we’ll manage to stay on track.
That’s all for now, thank you for reading.
Perkulatorn's Game Design Blog 
The blog post clearly states that the focus has been placed on both level design and balancing, as the topic of work is the Design Document. What could be interesting here is knowing what kind of numbers you changed, what part you redesigned and for what reason.
Another thing that’s interesting is to know how you decided and changed the balancing. Assuming that these features being adjusted are not already inside the game. How does one do balancing and changes without testing?
Would be very nice on a more detailed description on what was actually changed, instead of the “Stuff got changed”. Knowing what you actually changed and for what reasons could be helpful for others, while just mentioning changes is not.
What i really liked with your post though, is the part where you refer to other games, and the reference text from Randy Smith. was a good example on how you can use terrain to take a very large role in the level design.
Overall i’d say that the blog has some nice parts, though explaining some parts in further details would make it be useful for others reading the blog. for example:
Was some of the things changed due to some sort of problem? In such a case there’s a high risk of another one running into the same “trap”. While if it would be so that a blog that has been read earlier mentioned this, the “trap” could most likely be avoided and the project goes on without interruptions.