However, my work at DigiPen has me make games, and when I got the chance to make whatever wanted I decided to make a puzzle FPS called block. And it was the first FPS made in DigiPen's internally developed Zero Engine. So I wrote a lot of code from scratch and honestly the controls were not as good as I hoped. But for a game made in a month or so with little to go off of, it was a good proof of concept. I have some fond memories of the project.
(P.S. This was from my website, if you saw it there before)
Game summary
Block is a game where the player manipulates the world through placing and removing blocks within the environment Using this ability they need to navigate challenges and puzzles withing the game world.
Playtest results
The game simply was tedious in its first iteration; it was a long slog of block placing because simply people saw the answer to the puzzle and then needed to sit back and built it. This is hardly idea for a super awesome puzzle game.
What I changed
Simply making the player build less seemed to be the correct answer. the action of placing blocks themselves is not an autotelic experience its simply a means to an end. Therefor I made changes to minimize and speed up the block placing as well as fine tuning the controls.
What went right
The game has a wow factor; people look at it and immediately get a sense of wonder an possibilities This was by far one best parts of working on this game since it was just cool to work on. Also defining blocks to regions helped guide players as to where they were supposed to be looking and helped subtly lead the players to their goal.
What went wrong
The block placing and regions internal code wasn't flexible; it was hard to make changes and get things working the way they should've. Often small changes meant large rewrites of code and lots of wasted time.
What I learned
Simply this was a project where there just wasn't time to further refine where the mechanics needed to be for the concept to be viable. Also the level design challenges would've bogged down development considerably. Also I believe there is a way for this mechanic to work but the production schedule just doesn't allow for more time to experiment and iterate at this time.
