shawn's blog

Repetition

Posted in MCE by Shawn on May 31, 2011

Well, currently, with the puzzle game, I have around 13 levels, 11 of which are actually completed. One reason why  this is the case is because I had to fix each level.

Twice.

Because of a bug.  Then because of issues.

Well, let’s actually talk about things. The main character in the game can, well, jump. Jumping is essential to survival for some levels. And your jump ability should remain consistent. However, this was not the case with the very first character controller script. It was, in a nutshell, awful. The 2nd and 3rd versions weren’t that great either. However, I believe the 4th one is the one that was the one I started to use for levels.

This character was pretty cool. He would move and jump when I told him to, and it seemed like a match made in virtual heaven. However, there were times when I had a level running and looked away for a few moments in time. The player was supposed to jump during certain times, and if the player jumped, the level would be over with words of success written all over my screen. Unfortunately, from time to time, the end result was the beginning of the level (when you die, the level quickly starts over). This lead to testing to why the player was dying. I then booted up my test level (where I test all the elements that I want to include, such as traps or environmental tools), and had my player jump 21 times in a row. And what I saw was normal. The player jumping 21 times in the row, the first jump similar to the 21st jump, and everything else in between. This put my worries on the back burner, until it happen again when I wasn’t looking. So, I tested again and again and again. This time, I saw the problem. Approximately 5% of the jumps were much higher than they should have been. Inconsistency, something that I pretty much need in this game, was not occurring.

After many sessions of debugging, I decided to switch to an animation for jumping, instead of playing with positions. And this was a problem. My player animation would always start in the same spot. No matter where the player was. So, let’s say the player was at y = 50, once the animation started, it would start at y  = 0, something I did not want to happen of course. This was eventually fixed, by doing something I find silly (parenting the player to an empty object which has the animation attached), but it seemed to fix the problem. Because of this, the timing of the levels were off by a bit. I had to go back to level one and adjust the player’s starting position, and the timing of some traps and environmental objects to fix the levels. All seemed grand, and the player’s jump was consistent. The animation wasn’t want I wanted it to be, but I was too annoyed to fix it. But there was another problem.

The animation always ended at zero. Which means that if the player was on a moving platform that moved up, but the player needed to jump, the player would move through the platform in order to finish the animation. There were a few ways I could have gone about fixing this. I figured, I could detect if I landing on an object, and if I did, stop the animation. But, I wanted to give the previous code another go. This meant ditching the animation, which I didn’t like in the first place, probably the reason why the animation was ditched so quickly.

After even more sessions of coding, I fixed the problem and saved my changes. And the player no longer jumps 20 feet higher than they should during random jumping moments. That was good. The annoying part was tweaking all my levels again.

However, I’m down to fixing 3 more levels, as some of them didn’t require too much of a change (yay). Let’s up this is the last of the player edits, as this is taking too much time away from other development. I was actually planning on spending this evening making music. Instead, I need to fix levels. It’s okay, I guess.

But that’s it for now.

Tagged with:

Comments Off on Repetition

Roadmap – TriWeek1

Posted in MCE, Music, Unity by Shawn on May 24, 2011

Last year’s initial deadline for the IGF was October 18th. Which means that as of today, if things are similar to last year, the deadline for the IGF will be on or around October 17th. This means I have about 5 months left. 5 months may be a lot of time in…normal world time, but for me, it’s not a lot at all. Especially with my schedule of late, as the many things that call for my attention when I’m not (or even during) working on my game.

I have decided to create several roadmap iterations in Redmine, each of which last for three weeks. This should actually bring me right around to the first deadline. You are actually allowed to develop and submit past the deadline date, but only to update a game that has already been submitted by the deadline date. Even though this is true, I want to actually submit as close to a quality project as soon as possible, and leave that post-update time for fixing those wonderful bugs that seem to pop up at the right moments.

So far, I’ve only made three iterations, which span three weeks each (9 weeks total). The task are me playing it very safe, which means that while I think I may be able to reach something this iteration, I probably placed it in the next one. I rather move task up an iteration rather than push them back. I’d feel a bit more depressed if I did.

This iteration contains assignments such as fixing a lot of important bugs, modifying levels to support collectable items, and the wonderful music, something that I have been neglecting. I actually created a track and put it on the sidelines due to not liking it. A few weeks later, I created a different track, and eventually realized that I made something eerily similar to the one I made a few weeks ago. This could possibly be a sign that I should keep it, or that I should try and shoot for a different style of music. Of course,  I do not need to stick to one style, which is one great thing about being in charge.

In addition to my task, I have a nebula set up for other things that I would like to put it, but may not really find necessary/important. But, depending on how well I do, I may reward myself with including these extra features.

Somewhere within the next two iterations (6 weeks), I’m planning on putting out a more refined test version, which others can play. So, if you want to be first in line, let me know! You can also still grab the first playable build that I put out. It’s not going anywhere anytime soon.

But that’s it for now. I want to finish sorting out these roadmap details.

Comments Off on Roadmap – TriWeek1

High Speed Transport

Posted in MCE, Unity by Shawn on May 16, 2011

Well, within this puzzle game, the main player cannot move too far unless they’re on a moving platform that travels quite far. But that’s fairly boring. So that’s we shall introduce:

 

Made for high speed transit

Wonderful! Now with these high speed transport tubes, players will be able to travel from point A to point B rather quickly. Even better, we can connect tubes so traveling from A to B to C will happen much faster rather than if they had to walk. Or take a moving platform (which I hear are going out of style anyway).

In terms of designing levels, this will allow me to create much bigger environments, with more unknown values to the player. Which will probably be a bit more unfair to the players.

Oh, but if you do use a high speed tube, just make sure that you don’t run into one of these on the way out:

A Mace

Oh, they spin too. So be sure to look before you leap. Or pause before you transport? Well, whatever if is, think before you do anything.

But that’s it for now. I need go get back to designing levels for my next playable build.

Comments Off on High Speed Transport

High Speed Saving

Posted in MCE, Unity by Shawn on May 13, 2011

This past week had me dealing with a few new aspect of the puzzle game built in Unity, some of which the player will be interested in.

The less memorable, and probably taken for granted, addition is the ability to have the game save the player. It should save automatically. I still need to do some testing, but the game should save after a player beats a level. And grabs an collectable item!

All throughout certain levels, there will be items that the player can collect. Eventually, if they collect enough of these items (whatever they are), something will be unlocked. To be 100% honest, I do not really have too clear of an idea of what these collectables will eventually unlock. However, it will add to making levels a bit more complicated if the player wants to fully complete each level.

The final thing that I added was a new environmental tool, one that allows for potentially high speed transportation of the player. This should be useful to create larger levels, and possibly higher paced levels.

This was a rather small update, but there are some really important things that have been added. For the future, possibly this upcoming week, I have some more aspects that I want work on. First, I want to work on implementing the high speed transportation device within a new level, something that I am pretty exciting about doing.

I also need to begin working structuring the games levels. I want a fairly simple world structure for the this game, one you’d find in a number of platformers.

That’s it for now. I actually hope to have another build soon with more artwork available. I have a ton of fun ideas for the high speed transportation device, and I should probably finish what I have in my sketchbook.

Comments Off on High Speed Saving

Overestimation

Posted in MCE by Shawn on May 9, 2011

Huh. What an odd word.

But it actually turns out I was overestimating how much work I would actually be able to do. In a previous post, I remember saying that I wanted to try and design at least one level every two days. However, making those plans is a fault on my part.

Time. I have time. I’m not under the gun of any publisher or a boss of some kind. This means that I can work at my own pace. If I want to take a few days off, then I can. I don’t want to, but it’s nice that the option is there for me to take. And time is something I should and will give myself.  And time is something that I need. This puzzle game is one that will test the players memory, and their ability to plan accordingly. Timing is very important in this game. For both myself and the player. For example, I was working on one level not too long ago, currently Level Eleven. In order to get this level to work, I need to adjust certain elements by tenths of a second. If something is two tenths of a second too fast, or starts three tenths of a second too early, then the player will die in an unfair way. Well, more unfair than the game is initially.

(The game isn’t fair. In a fun way.)

So, instead of trying to do too much, I am going to need to take my time with each level. Each level needs to be thought out and run through a decent number of times. It’s great when a level seems to work out right away, but more often then not, they don’t.

What goes into making a level?

Well, first, there’s my sketchbook. In my sketchbook, I draw whatever I want. Which, in many ways, is awesome. I usually do not think if what I’m trying to implement is practical. One reason why I like video games. Also why I really enjoy Philosophy. But, in the sketchbook, I draw the level, the traps and the goals (either timed or destination). I then work on the potential solution for the level. I say potential because mocking up a level sometimes doesn’t turn out the way I want it to when I actually test the level. But the potential solution is what I aim for, but remain extremely flexible on changing.

When I have something that seems interesting, fun, etc, I start designing. I try and recreate everything as I drew. I throw in the traps, the player, and different environmental tools, such as a moving platform or something else that the player can interact with, but die from a direct confrontation with said object. After the screen resembles the paper as much as possible, I work on the implementation of the solution.

Now, I have a spiked ball shooter that…well…shoots metallic orbs with spikes. I also have parameters which control when I want the object to start shooting, how many shots it should take, how fast the object shoots, and the interval at which the object fires. Everything can be extremely adjusted. For example, in Level Eleven, I actually spent a good deal of time adjusting the interval of a shooter from the initial 4.5 shots per second to a final 2.15. That took some time to get there, because I also spent some time adjusting the speed of a moving platform as well. Basically, the end result will result in the player stringing a cool set of moves together. There’s a lot of tinkering and play testing to get something right. So there’s a puzzle for me to get the puzzle game to work. Lucky for me, I like puzzles. Hopefully, players will like them as well!

But I guess that’s it for now. I still need to finish tweaking this level….

Comments Off on Overestimation

Progress – May 2nd

Posted in MCE by Shawn on May 2, 2011

I told myself that I would have a post, mostly because I haven’t had one in a bit. It’s okay though.

This one will be small, but I’ll cover what I’ve done since the last update.

I haven’t continued reading that book, mostly because I read on the bus, and I recently bought the new Pokemon game and have been playing that on the bus instead. So my update for that book will come later….probably.

I’ve only made one new level since my “Play This Game” post, but that doesn’t mean that I’m not doing work. I’m working on new traps and things that will destroy the player. Such as a revolving mace. On and this thing:

 

A Block!

 

Lovely right?  Well, it looks like a cool texture now. But don’t step on it. Why?

Spikes!

Because rusty spikes hurt.

I have new ideas and things that I plan to include in levels, but that doesn’t mean that I can neglect actually designing levels. Which means that I should get back on working on my levels.

And if anyone wants to play what I have now, let me know! I’ll have to provide you with either a link or a CD. Currently, I have a Mac build that’s available for download, only because someone with a Mac requested that I did such. However, if anyone with a Windows based computer wants to play as well, they’ll simply have to let me know, and I will provide the product.

But that’s it for now.

Comments Off on Progress – May 2nd