Research on the isometric perspective, day 2...?

Okay. So. We had a meeting with our teachers. Showed them what we had and some of the actual gameplay concepts.

The conclusion of this meeting, after having had a meeting only between us in the group, was to scrap the isometric perspective and go strictly top down. Why you'd might wonder. Well. Thing is we've had an idea about limiting the players line of sight with a flash light kind of from the start. And one of the group members figured out a cool way to do this.

Only in top down though. But in such a cool way that we all, including the teachers, found that the isometric perspective wasn't that necessary anymore. Cool huh?

The things that have been done since is mostly trying to create some cool graphics, since we decided on the perspective to use, and implement some of the features we've brainstormed. Our aim for the time being is to have a playable rough demo by Wednesday this week.

And I'm sorry for hook and baiting you all the time with me promising to post screen shots and playable files. I will stop this teasing and just put things up when I feel I can.

Research on the isometric perspective, day 1

So, today we started to experiment a little on how to make this game a reality with an isometric perspective.

One great tutorial was found on the developer of Game Maker's web site, yoyogames.com.

Tutorial: 3-Dimensional Games (zip file, 1.1 MB)

Help us a lot with realizing that the programming didn't have to be that advanced to have the character walk behind walls and be visible through walls in a good way (which is something we had discussed that we thought could be a big problem to solve). For my own reference I'll just make a quick list here:

* Solved the problem with depth (for example getting behind walls) by setting the value of depth on objects to -y
* Solved the problem with the character disappearing behind walls, thus being harder to control, by making him visible with an outline. This is made possible by having an outline on top of the character at all times, with a value on it's depth that always puts it on top of all other instances.

While the others to in our sub group research their parts, one of them trying to animate sprites in all 8 directions we'll be needing (this is one thing that makes us doubt the perspective, LOTS of time for animations in 8 different directions), I took a file merged between the cube character demo I did and one that was a test on isometric environmental objects (like floors and walls) and started playing around with what we'd learned.

The result was a, rather buggy but still, room with cubic hog zombies going after the player, avoiding each other as well as walls. These could be killed but not much more.

Just some half an hour ago I looked at the file again, just wanted to clean some things up. Ended up with:

* Fixing a problem where the bullet didn't stop at one zombie, but continued through and could kill many zombies in a row.
* Making the player killable by zombies. This sends the player outside of the playable area, so needs a fix later on. Can't just destroy the player instance, since the zombies are searching for it and destroying it returns an error.
* Extending the playable area with a "corridor" to see how it felt to explore a bigger map.

Still needs a lot of work and we might even end up not using this. But we'll continue working on this until Friday and I'm planning to share what we have come up with no matter if we'll scrap it or not.

All for today, tomorrow we'll start writing on the story and hopefully progress on this research.

Design Document

Today we met up in school to write our first take on our Design Document. For those that don't know what part this has in the development process, it's a document where the game is explained in all from story, things you can do as a player to what resources are in the game. Everything more or less.

And the document is never finished. Things are added, others removed. And that's the reality and beauty of it. :)

We also decided that we had to share the work load and I got assigned with two others to look up the answer on the question: "Can we both make a good game and a good looking isometric viewed game on time?"

So that is what I'll be doing next week, a little research on the isometric perspective.

Small steps

Today we didn't meet as a group in school, but decided to take the day off to reflect on the brainstorming and such.

So I decided to look on the control scheme we have discussed to use and see if I could implement it in the application we use, Game Maker 7.0.

Took quite I while, mostly because I'm unfamiliar with writing code like this.

But I got it to work eventually and I'll be attaching and .exe (.exe2 just take away the 2, google doesn't allow .exe to be uploaded) to show this off as well and some screenshots. EDIT Coming up later, flooded with work at the moment!

A little later I went back and just replaced the triangle sprite with an isometric cube, to see how it would look. We are discussing at what view the game is gonna have, everything from isometric to 2D platformer. But haven't come to a conclusion yet. Thing is, isometric would be the coolest but does also require the most work graphics wise. We'll see!

Just a note before I wrap this up; I'm noticing myself that this blog leans a little towards being a development blog from my perspective more than from the groups perspective. But maybe that can't be helped. This initiative is my one as a way to follow our work and to share it with those interested. But I will be trying not to make it look like I am taking all the credit for this!

Designing our first level

Today we took a take on level designing. We used a technique we learned from a guest lecturer which goes like this:

* You make some notes with stuff like "room", "ammo", "money" written on them
* Then you take turns taking one note
* Depending on what note you get you're going to put this into an existing or by you created room

And that's about it.

Our next challenge was to take the product of this and make it into something real. First we just made a square room with all this rooms in. But many of the group's members found this to illogical and weird.

So we decided to each take a setting and create a level based on the setting and the level we designed.

The settings each one did where:
* School
* Big Brother House
* Apartment complex
* Office
* Supermarket
* Jail

After some quick voting, we found the school setting the most fitting for what we had to work with.

The ideas for the other levels where still saved tho.

Have some pictures to share here. Hopefully, we'll get some scans or something like that soon enough too so you can see more of the maps we did. Until then!

Welcome to Press Start to Rewind

Hi and welcome to the Press Start to Rewind Development Blog.

But what is Press Start to Rewind?

This is a school project for a Swedish course called Spelutveckling (Game Development) where we in a group are supposed to come up with the idea for a game and realize that idea as good as possible.

So, as you've might have guessed, the project name for our game is Press Start to Rewind.

The whole concept of what the game is about and what you do is quite vague at the moment, but here's what we've come up with so far:

* You play a character in a zombie apocalyptic setting. You don't know why this has happened, you just fight for your life.
* As story progresses you'll notice that you're not progressing forward in the story, but backward.

Yeah. Well, maybe more actually. But that is the base concept. Zombie survivor game where the story progresses backwards.

We also had a brainstorming session today where we like spit out everything that came to mind that would be cool for the game. Obviously, as with all brainstorming, a lot of this will have to be cut in the end.

So, this was the first entry of the development blog for PSTR (as I will be referring it to from now on). Stay tuned for more.