Hey, I'm learning Japanese

ああ！これは凄いです！


So, yes.
(そうですね？）


I'm really bad, but I'm working at it.
Hope is to start making stuff in Japanese as well eventually.
Plus, how can you possibly go visit Japan without speaking Japanese?
You can't, without your hand being held.
No, I want to adventure.
I'll probably still make a fool of myself anyway!
Like that time I emailed Pixel about Rockfish and probably sounded extremely silly.
(because I had to use Google translate a lot--I didn't know how to say most of the things I was trying to. Fantastic!)


Plus, emotes.
(^o^)/！！！！！！！
かわいい
かわいい
かわいい
かわいいよ！！！！！！！！ですですですですですです

Just kidding. I'm not like that... I swear!!!

Level Editor Project

Here's a WIP screenie of my new level editor project. I'm making it because my other preferred editor, Ogmo, has been missing some features that I'd like to have.

It's a fully UI editor--You create and configure your entire project within the application. One thing I disliked about Ogmo was having to write out project XML's. It was nasty...!

I also tried to remove a lot of the redundancies and complexities of Ogmo. Some of the properties just felt pointless, and having to sort through a manual and tutorial repeatedly to find the info you want felt.. Well, unintuitive. That's why I'm placing such a heavy focus on getting it all done within the UI.

I disliked Ogmo's limited layering system, so instead my editor uses numeric z-ordering. I find this a lot more intuitive because in Ogmo I'd sometimes run out of layers to layer on my background tiles. The only way to get around this was to add in a whole new layer in the project file. A whole new layer just for maybe one or two tiles? Aaaaahhh... My level loading code got pretty nasty because of stuff like that. I also added rotation, scaling, and indefinite grid-snapping. This lets you use this editor easily as either tile-based or otherwise.

And finally there will be a "map" or "universe" editor. It's for designing the position of each level in relation to each other so that you can build your world-map visually. This is a feature I'm very excited for, because in my experience connecting levels has always been a painful and relatively blind process.

So, this post is running pretty long, but all in all this is my desired level editor. I'm very glad that I've made this and it's been very rewarding so far. Don't be fooled though, there's still much more work to do. When I'm "done" I'll release it (since it's a generalized tool) for anybody to use. Along with it I will also include the source code. Behold, my terribly kludgy Objective-C code! Har har.

See 'ya!

Also: If you want to follow the editor's progress follow me on Twitter @BlueSweatshirt(link in sidebar) or keep an eye on #OperationLevelEditor.

Concept: Action Tactics

Hello! Today I'd like to talk about an idea I had for a game. I'll go over the basic concept and then some specific details of how it should work. And most importantly, I'll talk about why. For one, I think this is a neat sort-of-hybrid-idea and I'd like to share it. And for two, I think it's good, as developers, to share the thought process that goes behind design decisions. So, here we go!

This idea focuses on the action(or battle, if you will) system in a game. It's a combination of what I like about both action games and turn-based games. In action games, you get high-tension combat with a focus on mechanical skill.(usually!) In turn-based games(particularly RPGs, I suppose) you get to coordinate groups of people and plan strategically. But for me, I've always wanted an action game where I control a party. That's very difficult, of course, since in an action game the action never stops. Well, this idea is kind of a cheat.

You have two groups on a playing field, presumably the player's party and the enemies. There are turns. Each whole party gets their own "phase" where they coordinate their team's actions. Within a phase each unit in a party has a turn. During their turn the player controls them like they would in an action game. Turns are limited based on time. Time, because, in an action game the action always goes on. Limiting by time is the most logical conclusion because you don't want the flow to stop. Time also happens to be a key balancing factor in most action games, so you keep that element. Overall, it helps the battle feel much more like you're playing an action game.

When a single unit's turn is done, it very quickly switches to the next unit. When everyone's turn is done there is a phase switch. There is never a pause.

Units can also "wait", forfeit their turn. Doing so adds the current time they had left to their next turn, so they can do even more actions. There are a few reasons for this. One, so that the player is not left waiting for their character's turn to end if they don't need the rest of their time. Two, to add another element of strategy to time. For instance, some powerful attacks may require more time to execute. It also rewards the player for using their time efficiently, another element of action game pacing.

For spells/skills/etc there would be hotkeys rather than menus. Menus take time to scroll through, and that really doesn't work with a time-based system.(that's why action games don't really have them!)

There would be no way to survey the battle and gain your bearings. It all just happens. During the enemy team's phase the camera does not shift focus to their units. Instead, you keep an eye on your own. In an action game you're never really afforded omniscience-- You have to observe with your own eyes, so the same concept is applied here. This also lets elements of stealth and deception come into play, which do sometimes play a role in action games.

Remember the goal here is to bring the turn-based game elements and benefits while maintaining the vibe and pace of an action game. If I wanted to do it the other way, and make a turn-based game with action game elements, I might do things like add menus to choose skills from and let the player be omniscient of the playfield. But in this case, I want to keep those action game elements. Where you're not some puppeteer, but instead directly in the action.

Secrets, Novella, and Nutella

Hello!
Unlike the usual trend of musings and teasings, today I'm simply going to talk about what I've been doing. While, yes, it is a tease, it is not entirely a tease on game development, something which I think I talk about for the majority of my time on here. So today I'm going to talk about art, writing, UI programming, and film.

Art
In my art class I just finished a surrealistic painting. Is it good? I don't know! But one thing is for sure: I need a ton more experience with acrylic paint before I'll be able to satisfy my personal expectations. I also need to work on my steadiness with a brush-- It's something I'm not used to using, so I tend to get pretty shaky with it sometimes.

I've also been working on my digital art skills for video games. Sure, I've done legions of sketches and stills, but it wasn't until recently that I've gotten interested in drawing/"painting" my game art rather than using low-res pixel-based art. I think it will propel the visual aspect of my games to new heights. And while, yes, I do have a certain love for pixel art and also for low-res art, it does not fit in with the kinds of games I'm looking to make. Also, I'd rather not do pixel art just for nostalgia's sake. And finally, aside from all that, it's been very refreshing and fun doing hand drawn game art! I'm enjoying it a ton.

Writing
I've begun writing a short novel in the spirit of NaNoWriMo. I missed the actual event, so I'm just doing this for the sake of it. I think pushing myself to write a 50,000 word novel in a month will seriously propel my storytelling skills. I'm just over a week in and I'm already building technique like crazy. I can't guarantee the novel will be any good, but it will exist. So far it's relatively cohesive, but we'll see if that changes. Once I'm done I'll be putting it up at my site for download.

UI Programming
Macs are awesome to write UI with. My nuances with Xcode aside, I've found designing and programming UI with Cocoa to be a pleasurable experience. Some things, like populating a table, require somewhat crazy amounts of effort in the eye of a beginner like me, but now that I've learned how all the pieces of the puzzle fit together I'm finding it to be a very effective and well thought-out model with lots of flexibility. My current project is a UI level editor for a secret game project I have an idea for. I'm making it both for the learning experience and for it's application, because I can see this game as being one that requires a ton of level design. If the level editor comes out any good I'll open-source it for all you peoples. I'm going to try to make it as user-friendly and efficiently coded as possible. *ahem* Let's see how well that works out.

Film
I'm beginning work on a short series called "Zombie Fast Food"(name may change). You may or may nor recall me making a trailer for this series earlier this year. Yes, well, so far they're related in name only. There is zombies, food, and survivors though, I assure you. This project is being done for my film class at school. The main goal with this series is to gain experience in a wide and balanced variety of film making elements and to use my surrounding resources well. Visual storytelling, cinematography, post-production, pre-production, makeup, etc. There are lots of run-down and rickety buildings amidst a forest-like setting here, so I thought that would work perfectly for a somewhat-cliche zombie movie. It breaks off from the zombie movie cliche in that it's not really a horror or action movie, per se, it's more of a drama. We'll see how this goes.


Anyway, that's all for now! I'll post results as soon as things materialize.

Wondering how Nutella got in the title? Keep wondering.

Design with Verbs

So lately I've been thinking about lots of rather esoteric things like "what's the secret sauce to video games?" and no matter how much time you spend in the thinker pose that philosophy will mean nothing unless you find a way to apply it in your life.

(Image Source)

The result of pondering such has been me thinking about better ways to approach designing games. I won't pretend like I spent hours on end deliberating over a delicate conclusion; it was about 10 minutes of thought in the middle of me fighting a battle in Final Fantasy Tactics. I figured that since what makes a game a game are the elements of interaction and change, that good design focuses heavily on defining what interaction and change embody in your game. In other words, how do you interact with and change the game world when you play the game?

And this brings me to my momentarily brainstormed montra: "Design with Verbs".

Putting Up Prototypes

In the next week or so I'll be adding some of my game prototypes to my website. Some of them are just rapid development challenges, others are just me messing with a new mechanic or concept. I'm thinking I'll include source code for most of them. These are less for playing and more for learning and sharing some ideas I've had for games.

Two Bold Words

SKYWARD SWORD


The Legend of Zelda: Skyward Sword has came out, and this officially marks my 1-week break from all serious game dev work.(I also happen to have a 1-week break from school right now. Convenient!)

So far:
This game is the shiz. Freshest and most invigorating video game I've played in a long, long time. Perhaps ever. I might do an analytical post soon on what exactly makes me tick in this game.(tick, in the extremely positive sense.) But for now?

I adventure.

Gimmicks & Designing with a Goal

I'll start off by saying that I dislike gimmicks in games. By gimmick, I refer to a mechanic of any general incentive that was made with the intention to extort you into playing for longer periods of time. Achievements, stars in games like Angry Birds, and even special tokens or something in a platforming game. These are things that don't impact the gameplay or deepen the experience-- they solely exist to entice the player to keep on playing.

In a way, I see it like adding sugar to fruit juice. The juice has it's own natural sugar, but the producer adds in more sugar to entice you into drinking more and to hook you on it... So that they can sell more juice! It adds no nutritional value, and it is in fact quite unhealthy.

At this point, when I go to play a game like Angry Birds, I simply ignore achievements and stars. Thankfully, they don't inhibit the experience(unlike the unavoidable added sugar) so I can ignore it. It doesn't "break the deal" for me, I can look past it and still enjoy the game. And it's not like I'm not an offender of this criticism either, I've certainly made pointless gimmicks in my games before.

The main issue here is, to reiterate, that the gimmick doesn't really do much to add value to the game or add to the experience. It's just there to hook you, like sugar. That's what I dislike! I dislike that kind of extortion which only serves to get you to play more.

Going back to the fruit juice comparison, some game developers even refer to watering down their juice so that you have to drink more to get the same amount out of it. That is also a big no-no for me, for the same reason. That is a deal-breaker for me, when the tacked-on extortion actually gets in the way of and interferes with my play experience.


And now that brings me to my second idea: Designing with a Goal.

Just like probably any piece of art, you design around a goal. One central idea you want to emphasize, or one outcome you are aiming for. Mario is about platforming, Zelda is about saving the world, Call of Duty multiplayer is about competitive engagements. Some games have a less concrete or clear goal than others, such as Zelda I'd argue. But the general point is that in some form a game is usually designed with a goal in mind.

As a designer, I've found that designing with a clear goal or theme in my mind helps me create, overall, a much more coherent experience. And I am not saying that you define limits for your game or narrow your focus, deciding to only focus on one core mechanic or idea. I'm talking about having one overarching idea that guides the vision for how you design your game. For instance, with Z4R, the overarching vision is to create a game that's focused on precision, thoughtful play, and having great touch controls. It's not about limiting your vision, it's about directing it.

And also, as a big fan of games, I've had a ton of influence from the games I've played-- for better and for worse. Many times I have included things in my game that do not fit my goal for the game. I included them because it seemed like 'convention' and because it's just something you do to make a more complete game, or I dare say, because it sounded 'cool'. No! I was making gimmicks which were bad in the original games in the first place. I was playing by convention and not evaluating my influences to see if they fit in with the vision I had for my game. They didn't.

I didn't want to create a game that extorted the player into playing more and more. Because my goal wasn't to hook them for hours on meaningless things, my goal was to create a deep and meaningful experience that was constructive and coherent. It wasn't like I needed to hook them for long periods of time to sell subscriptions.(*cough cough* WoW) My goal in mind was not to sell my game and loot my playerbase. It was to make a solid, 'legit' experience first and foremost.

And that is always the overarching goal in mind when I make games, to make a legit, awesome experience. At the very least, that is what I try to do. I have to be careful sometimes not to lead myself astray with conventions. I am an offender. You, if you're a designer, have also probably been an offender at some point. The idea is to make everything you design in your game 'matter' in terms of your overall goal. Directly or indirectly.

Design with your goal in mind.
Design with vision.
Design with integrity.


Much of the thought in this post was sparked by reading Adam Saltsman's post on "Contrivance and Extortion", so do go check that out as well.

PP2X+ Indev Video 1

Here's the first video ever of Pocket Protector 2X+(the official name for the revamped version of Pocket Protector)




In other news:

• The game will be sold for $1.99
• Donating $1.99 or more to my site will get you the game for free when it is done.

More to come!

The Good, The Bad, and The Ugly

A lot has been going on lately! So I'd like to give a quick summary of what I've been up to.

The Good
Three new projects have been started. While I am not ready to announce two of them, there is one that I will share: Pocket Protector is being revamped completely. I'm going back and expanding on the game to better take advantage of the engine I built and to realize the vision I had for the game. Some new features include an entirely redone menu system(you're welcome, right??), redesigned enemy AI, new spells, more enemies, and a redone dungeoning system. And that's just the tip of the iceberg, guys, I promise.

The Bad
I haven't had nearly as much time to work on things in the past few weeks. I got sick, have tons of schoolwork, and have been swamped with preparing for college. Despite that, I've been doing what I can to try to keep my pace.

The Ugly
Z4R is coming along just fine, but it's taken the backseat for now in lieu of my other projects. Technical issues from working with the iOS platform have slowed development greatly due to my unfamiliarity with it's innards, so it's nice to be working on a game like Pocket Protector again where I can focus on the content & features rather than the technical side of things. I expect that development will be slow on Z4R for quite some time while I continue to familiarize myself with the iOS platform.


To close things off on a POSITIVE note, I'm opening a suggestion box for Pocket Protector in case there is anything you'd like to see in the new version. I'm very interested in your feedback!
Suggestion Box

Z4R has ditched it's black and white style, officially!

So there I was a week or so ago, sipping my coffee, and all of a sudden I had this startling, unexpected realization. 

These graphics are ugly.

Well, turns out I was right! While black and white may be a neat style, I don't think it was giving me what I wanted for my game, and that's why I changed it.

I still wanted the sprites to be a bit blocky, but I also wanted some higher fidelity, so I doubled the pixel resolution of my sprites. I think the result is looking quite nice. So behold, Z4R's new graphic style.

Read some more details about my game after the break, including a story teaser!

Mac and iOS are merging

Are iOS and Mac OS X merging? Will Mac OS XI and iOS be the same thing? Or will it happen even sooner? Only time will truly tell, but there are a number of factors which scream "yes" to me.

1. App Store

Mac now has an app store. Wow, Apple is now in a prime position to merge the Mac and iOS app stores. They both function very similarly, and I wouldn't be surprised if the only thing that separated both stores in Apple's data servers was some metadata for filtering which app would show up on which store. In other words, it'd probably be hella easy for Apple to make both stores merge. Distribution is crucial, after all. Especially since all iOS apps go through the App Store.

2. Fullscreen

This one's a no-brainer. iOS apps work in full screen, and now Mac apps can work in full screen. It's a simple comparison, yes, but there could be quite a bit to it. In the initial transition, for universal apps I can easily see the iPhone variant running in windowed mode and the iPad variant running in full screen. It's a possibility.

3. New gestures

The new multitouch gestures are pretty much the same ones you can use on iOS. There is developer support which functions extremely similarly across OS's for tracking multi-touch behavior. Mac apps are also beginning to react much like iOS apps would with the gestures— very springy, with inertial controls and a "stretchy" feel are now present on the Mac-- identical to the way it behaves on iOS. If Mac users are more familiar with the same gestures used on iOS, then it will be much more natural to use iOS apps from the start. And that might be exactly what Apple is trying to do; trying to get you eased into the "iOS way" before they integrate the OS's entirely. Smooth transition!

4. Same foundation powers Mac and iOS

To put it simply, iOS runs a variant of Mac. They're both built on the same foundation, but have different "presentation" layers. All the nasty stuff down below is relatively the same. This is important, as it means that iOS apps can effectively run on Mac since they all have the same "plugs". The iOS simulator is NOT an emulator. The actual code is being run on the machine, not through an emulated abstraction layer-- that's why apps will run faster on Mac than they do on iOS. If it was an emulator, and it tried to mimic the kind of environment needed the run iOS apps, there would be massive performance hits. To put it simply, nothing is in the way of iOS code from running on Mac. "it just works".

5. Changing UI conventions

Some of the latest Mac apps have been quite different from conventional desktop apps; they've had large buttons with obvious page-based navigation. Gee, sounds like iOS! App icons now have "badges" just like iOS has. These are all small changes, but a lot of +1's really add up over time. Oh, and did I mention the twitter app? It looks identical to its iPad cousin. If the code is so portable that you can port an app from iOS to Mac with minor visual and functional changes, Apple must be doing some big stuff under the hood.

If this trend continues for 10.8, I will have very few doubts that iOS and Mac will merge. The groundwork for it has already been laid. It was possible from the start. How long has this been part of Apple's master plan? Was iOS intended to merge into Mac from the very beginning? Was Apple initially using the iPhone, back in 2007, to test if touch was the new way to go? Was the iPad an extension of these tests? I see something "revolutionary" on the horizon. And quite frankly, I'm extremely excited for what the future brings.

DISCLAIMER:

Don't be afraid to fact-check and correct me. There might have been some details I missed. Please let me know.

How I Design Games

For the past eight years or so years I've had a fixation for creating video games. For the longest time, I was under the impression that the key to success was having an amazing planning document. It's taken me a long time to figure out my ideal way of doing things, and I'll give you one hint: it doesn't involve making your planning document amazing.

First of all, clear you mind of the concept that a planning document should be to any extent pretty, organized, specific, or "finished". Worrying about these things is pointless. You're out to make a game, not a planning document. Don't lie to yourself. Don't worry about appearances at this point, either. You can work on the concept art of your characters another time-- the game design document is about behavior and how things act. Specific details are best left to work out during the actual development, where you can actually test if certain things work well or not.

Next, clear your mind of the notion that your planning document is a "document". Clear your mind of the stereotype you place on creating a "document" and what you try to achieve in doing so. Now, let's recreate your definition of a game design document: "A place to write down all my ideas and keep notes of things I should try".

Notice I said "try", not "do". A decision in a game should never be final. Not until the game is "done", and I mean it. Your goal is to make a good game, and at any given time a mechanics shift might make it necessary to rework other elements of the game. It's fine, it's usual. Get used to the mindset that no idea is cemented in once you write it down, it'll be a service to yourself.

In fact, I would specifically encourage you to keep "try" lists. If you have a mechanic you're hazy on, write down a list of your different ideas on how to approach it. All too often I made the mistake of trying to design the final idea first. Bad! Write ALL OF YOUR IDEAS DOWN. Use a deductive approach, and eliminate the approaches you dislike until you're left with your most favorable one. I've found that in the process of this testing, you'll sometimes even think of a totally new approach which you'll like and end up going with.

Finally, I'd like to share what I think is the most important idea of this post. Don't write your document top-to-bottom. Don't work out every little detail of a concept before moving onto another. Outline your whole game, and then get more specific. I'll repeat. Outline, and then get more specific. You do this so you can see a picture of your whole game as soon as possible, and design it with everything on the table in front of you. When you work on things by just going top-to-bottom(not referring to writing on the page, but in your approach to working out your ideas on paper) you tend to get all stuck up in designing one concept without considering the others. It then becomes easy to focus on a small, possibly insignificant, chunk of your game when you really should be paying attention to the game as a whole. I can't emphasize enough the importance of this point. This approach has become absolutely fundamental for me to get anything done.

Bringing everything together:

• Don't worry about style, neatness, or polish.
• Save the artwork for later
• Don't try to be super-specific. "Come on, don't sweat the details!" - Hades(Hercules • Disney)
• Leave working out the details to testing.
• Write all of your ideas down.
• Try all of your ideas before settling with something that's "final"
• Be open to reworking concepts as the rules of the game change
• Design your game as a whole, not "top-to-bottom".

Hope it helped!

If anyone else would like to share their approaches, please email it to me or post a link or something in the comments. I love this kind of stuff!

Z4R - The Daily Saturn

Do you like storylines? I do! That's why I made one Z4R.

Behold, The Daily Saturn, some sort of newsletter ran by some sort of publication company on some friggin' planet.(I assume it's not Saturn.)

Read it here!

Spoiler: it's about the game's storyline.

Z4R - The following weeks!

'Dames and 'gents, take off your sweatshirts and relax. It's time for me to fill you in on what's been goin' down these past few weeks.

Following the first few weeks of development, I've gotten a LOT done. Frankly, there isn't much to play, so it's arguable that I haven't 'done anything'. But! On the inside, there are some nice, finely tuned gears that are ready to handle my game.

I've yet to do any true benchmarking, but I believe my game can push about 1000 stretched images and still retain 60 fps. This is great, because my game will probably never exceed more than 50 or 100 images on screen at once.

I added two enemies, a simple drone which flies through the screen(traditional cannon fodder!) and then a sweeping enemy which will sweep through and fire some bursts of bullets at you. It's all pretty simple for now, but it's a start! With that, of course, I've added bullets and damaging. Each enemy will have a unique weak spot which will net you extra points if you can nail it-- more on that later.

Behind the scenes, I made 5 new enemies'(including the sweeper and drone) graphics and design, but have yet to implement them. This engine for my game is written entirely by me(aside from gfx/sound which is done by cocos2d), so I have to add functionality on a need-by-need basis.

Lately I've been heavily considering changing up the art style to incorporate color. I'm not entirely sure how I'd like to do it, but some life definitely needs to be breathed in to this rather drab feeling shooter.

Oh yes, and, my summer vacation has finished and I've now returned to school. It's slowed things down a bit, needless to say.

The Hunt

I made a game for the Twitter-centric No Text Game Jam, somewhat hosted by Shelby Smith. You make a game using the "no text" theme in under 8 hours.

It took me about 3 and a half hours of work time.(lots of in-between breaks, heh)

In this game you play as a hunter in an African tribe. The God of the Hunt has offered you his help, but he can't communicate with you directly! He draws cave paintings to try to help you figure out what button to press to kill your prey. Be careful though, some of your prey may be hostile! One wrong move and you may never seen your tribesmen again.

Since there's no text, I don't need to tell you this story is never directly told in-game.

You can download the game now, right here.

Smoothies, Smartphones, and Serenity

Hello, welcome to the "mobile" era of computing. I'm currently chilling on the beaches of Waikiki, sipping a delicious fruit smoothie, and writing a blog post on my iPhone about my enthusiasm for the direction computers are going in.

With a smartphone, you're not tied to a desk. Hell, I'm at a fancy beach writing this post. I can go anywhere and take care of my business. I don't have to worry about my battery, I know it'll last me all day. I can use it while strolling down the main street, because it's so easy to handle. When sunset comes around, I'll stop for a moment to get that perfect picture of the pacific dusk, post it on my Twitter, and be on my merry way. Later that night I'll have a laugh with my friends, reading the silly comments they posted about my photo. Tomorrow I might go on a jog down the beach while enjoying some tunes streamed from Pandora. It's a much needed jog, too. I have to make up for those years and years of me spending 8 to 12 hours on a computer, you know! But hey, I don't fret. I can be anywhere, and do anything.

Yes, this is the life!

These devices are totally the future. I love them, and that's why I want to involve myself with them. These amazing little pocket devices are immensely powerful-- they give us, human beings, power. No longer are you tied to that desk. Walk free, as I do, enjoying both the real world and it's cyberspace in perfect harmony. It's just great being able to do any of your computing, or gaming, anywhere and everywhere.

That's the beauty of where computers are going. "mobile" isn't simply referring to the device. It's referring to us.

Now excuse me, I'm about to go inland for a traditional Luau. Aloha, brother!

Mini Project: “Z4R”

Today I’d like to talk about the iPhone shmup I’m making and some ideas I have for it. I consider this a mini-project, but it very well may take several months to finish.

A screenshot of the current testing version. Looks spiffy, huh? Click for full res

 

I’ve got a couple core ideas tied to this game. The main gameplay mechanic is supposed to revolve around ammo conservation, and precise aiming. The challenge & reward mechanics will all be based around making a precise shot. One motive of this idea is to challenge the idea that touch screens don’t make well for precise input—I believe I can make a game where it’s entirely viable to be precise.

The second reason comes from me noticing that most shmups throw around bullets without any kind of retention. It’s practically a staple of the genre to fire impractical amount of ammunition towards your enemies.(how do you even hold that much on your ship?!) Not only that, but players pretty much just hold down the fire button or turn on “auto fire” and simply spray bullets randomly. I think there is an untapped potential, so to speak, in bringing in elements of precision aiming into the genre.

As a segue, one of the few virtues I see in the FPS genre is that aiming and ammo conservation play a big role. It’s actually important(usually)—and the player has to be smart about how they handle their lead. Inversely, imagine a FPS which allowed all players unlimited ammunition and where they’d never have to reload. It would be much more chaotic and mindless, surely. So in some ways, this game is a amalgamation of what I like about the “standards” of the shmup and FPS genres.

For now, the name is pretty much temporary. It’s based on my old series of Z4R shmups. I might keep it, who knows! I made the logo just for fun

Breaking away from the segue, the second core idea of this game is the visual art style. I want to challenge myself to create a beautiful game using black and white(or more accurately said, grayscale) and chunky pixels. I don’t expect this to be an easy task, but I think it’ll be a huge payoff in the end if I can pull it off.

Getting a little more technical, for the aiming I’ve minimalized the control scheme to single axis movement. The player can only move left and right, like in Space Invaders and Galaga. It’s easier for the player to initially control the game this way, but more importantly it puts a greater emphasis on the aiming and precision mechanics which I strive for. If the player could more on the Y axis too(vertically), then they would be able to move within an inch of their enemy and blast them, removing the need for thoughtful aiming. It’s these reasons which led me to this.

“I believe that ideas for a game design should not be polished until it’s actually running. What I do is play while creating, feel and think about what would make me like this game more. The problem with this method is that you can’t effectively create planning documents.” – Daisuke “Pixel” Amaya

As for how exactly I’m executing this game’s precision aiming emphasis, I’ve yet to completely decide. I’ve got a few ideas in mind, and I’m already starting to try them out. Whichever I think works the best will be what is present in the final game, naturally. I would normally try to plan this stuff out completely ahead of time, but thanks to my experiences from Pocket Protector and a quote from Daisuke “Pixel” Amaya(quoted above), I think I’d rather take that approach this time.

Drowning In Hot Cocoa

Have you ever read a super-duper-long Wikipedia page?

Well, imagine that five times over in full pages of text. Yes indeed, that's how much I've read about Cocoa(the framework Mac/iOS is built on) in the past two days.

Objective-C is an incredibly difficult programming language for me to work with. While I acknowledge it's just a different approach to many of the same concepts I'm used to in other languages, it does feel quite bloated. Thankfully, you're actually able to use C and C++ seamlessly with Objective-C, so that's been a life-saver for me. Cocoa itself though, I've found to be a pleasantly well thought-out library and it's been great working with it so far.

On another less chocolaty note, Flash runs *ahem*, not so well on the iPhone. A blank frame of Flashpunk drawing one orange square topped off at 30 frames per second. I understand that Flashpunk hasn't exactly been optimized for efficiency, but I don't see any great way of getting around this-- Flash is just slow on iOS. It might work well enough for UI apps and slow-paced games, but not for something fast-paced like Pocket Protector.

So with that, I now know I'll have to stick to native development. The possibility of Pocket Protector getting an iOS port has lessened, but is not completely gone. It was initially intended as a mobile game, so I might still carry out that intention. That said, it probably wouldn't be for a while. Don't get your hopes up, but if I were to do that I'd also add more content and refine the game quite a bit.

For native development I've relegated my attention to two main libraries:
- Polycode
- Cocos2D

Polycode is a cross-platform development library. The creator, Ivan Safrin, is actively working on(and for what I know, almost done with) an iOS port. Polycode is a pleasure to work with, and if you're into cross-platform libraries you'll love it.

Cocos2D is Cocoa-centric, so I believe it only works on Mac and iOS. It's another excellent library, but doesn't have quite as much PC support as I'd like.(which Polycode does have.) So far it's been a nice, simplistic library. I wouldn't say it's anything to write home about, per se, but it's much better than writing pure OpenGL ES code.

Once Polycode for iOS is in a usable state, I'm quite confident that I'll be using that to develop my games. The prospect of developing on Mac/Windows/Linux/iOS all with the same code base is very valuable to me. In the meantime, I don't see myself doing cross-development.(making the game/app for multiple systems as the same time with different tools/languages)

I don't have much to show for my progress on iOS yet, since it's just some images moving and stretching around the screen. Once I get something cool going, I'll post up some screenshots or a video.

New Ventures

Today I graciously received a MacBook Pro, and that means it's time forrrrr.... Making iOS games! I'm right about to pay that developer fee, then I'll be up and ready to get going.(opting to pay the dev fee now because on-device testing is valuable to me)

Immediate plans are to get some of my flash projects up and running on iOS. Later I'll be more focused on native games, I can imagine. I'd like to make a UI app, but I'm currently not sure what I'd make.

There's a very strong possibility that Pocket Protector will get a revamp and be ported to iOS. Very strong.

Rant to Nintendo

Let me put it this way, Nintendo

If you refuse to give us free games, or those on price-par with those on other mobile platforms, then at least deliver on your promise of "premium". If you want to sell me a $10 game, that's fine. But if I can get a better game, in terms of both play and production value, on my iPhone for $1, then you're not giving me premium content. You're giving me overpriced piles of horse shit, which I won't buy. Premium means it's the best-- of the highest quality. So if you're going to charge me a premium price, you better damn well give me premium content. You no longer have my trust as making the best games, let me just put it that way. If you want me to buy your stuff, first help me trust you again. Give me great games at great deals. Prove to me that I didn't waste $250 on a 3DS. Prove to me that I made a good decision buying your console and not Sony's. This is the last straw Nintendo-- if you can't deliver what I, as a gamer, want, then I'll simply leave you behind. I'm open-minded, and love games of all varieties. But a shitty game is a shitty game. Give me the premium content which you keep promising. Give me a reason to put my 3DS in my bag every morning.

Thank you.

New Game In The Works

I'm not going to reveal many details yet, but I've begun working on a new game with Andrew Nare(known on teh interwebz as Sakar). You can check out his blog here.

It's a game in the same vein as a castlevania or metroid(metroidvania), but it's got some unique twists, both in gameplay and in story, which will set it apart from the mold of the genre. Oh yes, and it's being targeted mainly at mobile devices. Don't worry though! There will be a PC release as well. Stay tuned!

Pocket Protector Postmortem

Eight months ago I was looking towards the future with blazing excitement. Today, I look at the past with mixed feelings. I look back upon my journey, and I am ready to acknowledge the mistakes I’ve made for the sake of progress.

First and foremost, I made a huge mistake underestimating the amount of work it takes to make a cohesive experience with randomly generated dungeons. I can probably attribute 40% of my entire development time to working on the generation algorithms. Heed my advice, randomly generated environments is not an easy way out by any means. It’s like trying to tame a wild beast. You have very little control. The more control you put on it, the more same-y everything will start to feel, and the generation will become stale. The trick is finding a balance, I’ve found.

The greatest problem I had during development was a lack of direction. It might seem trivial, but choosing and sustain a direction can be hard on your own. Ideas constantly flooded into my head during development, and I was constantly inspired to try new things. It wasn’t a bad thing, but it slowed my development time by a ton. Why? At first I programmed things with one idea in mind, but then I wanted to do something I hadn’t originally intended, and I’d have to go back and hack my code to make it work with my new idea. I was doing this daily for the first 3 or 4 months. Afterwards, my code was an absolute wreck and I was nearly forced to go redo all of it.

From that, I’ve learned the true value of planning a thorough game design document. I made a 6-page plan for this game, and in the end only about 1 page of it actually ended up in my game. My design document wasn’t nearly as specific as it should have been. I didn’t consider balancing, tweaking, progression, challenge, or reward. I conceptualized characters, enemies, and environments and dabbled with some features I’d like to have. That’s not a design document. Not on it’s own, at least. A truly useful design document, I’ve learned, should contain specifics and detail the utmost details of player interaction with the game.

The importance of having such a clear document, is that then you’ll know what to program your game for. If you want to leave yourself leeway in design, such as for more weapon or enemies, then you know to do it ahead of time, instead of going back and hacking in support for that later. It’s crucial to development time to never have to take steps back. For one, taking steps back is completely demotivating and hurts your development momentum. Notes for the future!

In retrospect, one of the biggest mistakes I made was choosing a low pixel resolution to make spriting easier for me. Let’s be clear—It didn’t make it easier. It made it harder. The main character is 11x12 pixels. With some good pixel skills you can fit quite a bit of detail in there, but alas it’s still only 11x12 pixels. If I went with a much larger resolution I’d have had much more opportunity to detail my game.

Flash is a great platform for making games. It’s well suited for making nearly any 2D game. Flash is very portable, and very developer friendly. Flash game portals, however, are not developer friendly. I’ve found that they often have a very narrow view of what games they want for their sites. Which is a shame, but that won’t stop me from using Flash for commercial games in the future. I simply won’t be aiming to get my game sponsored on a game site at all.(unless it seems like it fits what game portals want)


That concludes my Pocket Protector postmortem. I guess it was fairly short, especially in respects to how long it took me to make the game. I guess that’s due to all of my trial-and-error’ing along the way. That’s a lesson in itself.

Website!

The Man In Blue Sweatshirt website is officially up!
Check it out now at http://maninbluesweatshirt.com/

And, that's not all! With this release of epic proportions, there must be game release to compliment it. Yes, Pocket Protector is now released exclusively on my website!

Coming soon: Postmortem on my eight-month journey with Pocket Protector.

To the Ebay of Flash games!

Pocket Protector's testing phase is over, and I'm now officially calling the game complete. The testing helped immensely, and it led to many significant changes in the usability of my game. So, I'm really glad I took the time to do that.

Pocket is officially up for bidding at FlashGameLicense.(well, currently going through the approval process) Now the real crunch time begins!

Pocket Protector is almost complete!

All eight beautiful stages are complete.

The shops are full of items.

The enemies are plentiful.

And the hats are elegant as ever!

Pocket Protector, ladies and gentleman, is nearing it’s very final stages of development. It’s been a long time since I started this game, almost eight months ago, and to see it nearing completion is almost surreal. It’s a satisfying and wonderful feeling, to be honest. After all of the time I’ve spent pouring my creativity into this game, it’s almost ready to be called a product.

Here’s a fun little fact I calculated! If I were to have spent the same amount of time on this game at a day job at minimum wage, I’d have made $21,840. Even so, I don’t regret a single minute I’ve spent on this game! It’s been a wonderful creative and learning experience. That said, I am still kind of hoping to get some sort of return on this.(can you blame me?)

Anywho! I’m looking for testers now! Here’s a little criterion, but don’t let it scare you away!

• Must provide detailed first impressions
• Report any bugs found, giving as much situational information as possible.
• Give detailed suggestions to improve the game.(if you have any)
• Must explore all of the various game options and give detailed feedback on how they work both individually and as a whole.(in this case, I mean try all the weapons and spells and tell me how well they worked individually and also how well they worked in comparison with each other, same for spells, etc.)
• Provide a video of you playing, preferably for the first time. Audio is not necessary, but commentary is appreciated.
• You may not under any circumstances share this game's file with anyone else. Sure, your friend can play it, but don't go giving the game file out or uploading it to a file sharing server. I have no way to prevent you from doing this, so please just don't be a dick.

All done! It’s just here to help insure I get quality feedback. If you’re interested in testing my game, email me at jackmakesgames@gmail.com. Tell me who you are, why you’d like to test my game, and how well you’ll be able to comply with my requirements above.

Thank you!

Blue Sweatshirt signing out.

Upcoming: AI

For my next (trick) article, I'll be writing about my approach to game AI, how I define AI, and what makes AI different from "behavior". Stay tuned!

Photographilia

To settle any potential picturelust, I’ve uploaded these three pictures for your enjoyment:

OOOOH, shiny! I’m guessing this is the Mineral Deposit.

Frickin’ glowing mushrooms, mannnnn!

Spoiler: The mushrooms restore your MP, so in this stage you’ll get wreak havoc with your Magic. Plotline justification not included!

Awww, how cute!

Spoiler: He’ll kill you.

Let's finish this!

Hey everyone! My school year has just finished and I am now officially in my last year of high school. My personal agenda aside, this summer my goal is going to be to finish up Pocket. I have so many cool features planned, and I plan on working quite hard getting them all in over the summer. I'll have plenty of time, after all!

Among the features planned:
• a clever skeleton
• an overprotective arachnid
• a vein to strike riches
• summoning the power of a bartender

Circle Pads and Peep Shows

No blog is complete without a proper dosage of “porn”, so first I’ll give you a little peep show on what’s up at the moment:

Oh snap! So what can we dissect from this… Hmmm… There’s a little circle thing on the bottom left instead of the minimap, there are strange boxes with doors which have enemies crowded around them…. And the stage is purple with gold bits strewn about.

I’m not sure where this is, but it’s pretty obvious what that circle pad is for, right? Duh…

Touch screen controls have arrived!

And with that there is the option to replace the minimap with the circlepad. While many touch screen devices with flash embedded probably have a keyboard, we obviously don’t want to leave the others out. So in the options menu(by the way, I added an options menu) you can now toggle on/off the circlepad as well as change it’s size. It’s important that you can change it’s size to accommodate different screen sizes and player preferences. My circlepad also supports easing—The farther the player presses to the outer ring the faster the player will go. There is error with a direct implementation of that idea, though. The player would have to consistently float their finger around that outer ring to sustain maximum walking speed. Ouch much? Therefore I implemented it so that you only have to be 50% towards the outer ring for max speed… Much better! It’s the little things.

I’m adding more things for you to fight in the Cave

And I’ll just leave it at that—letting your imagination take you the rest of the way. One hint for you, though: Gauntlet.

Top-Down Attacking

Time for a technical post!

So today I was working on an AI of a smarter variety for Pocket, and rather than flinging itself at the player or shooting them, it instead attacks them with a sword. This is a different “hit box” entirely, which extends from their normal “hit box”. The enemy closes on the player and hits them. But since my game has entities facing left/right/up/down, I faced a problem. Check out my diagram here to see the problem and how I tackled it. I hope it helps!

Official website coming! Yay?

After I get paid for my most recent jobs I'll finally have the money to purchase a decent server to host my portfolio website on. Huzzah! This is very exciting for me. The basic website is already done, but there's no doubt that I'll be improving it once I get the website up initially.

This is going to be great!

Protector Rush -- Play it Now!

Debut article

So, Protector Rush didn't make it so well on FGL. Go figure, huh? Oh well, though! I'm going to put it up on my dropbox so anyone can play it. Have fun!

Play it now!

For some reason the game's view is totally expanded beyond the intended frame when in fullscreen mode. If anyone knows a fix to this, please drop me a comment.

Action Non-Action Game

So I was sitting here thinking about “what games are like” and about how they reward players. Psychological characteristics of games and all the like. Most action games appeal in two ways right now: “good job!” for killing someone, and through the (supposed) male instinct of putting yourself over someone else.(in the case of multiplayer of course)

Regardless of the particulars in execution, I think it stands that action games reward the player for killing and fighting. That’s probably a big reason why they’re labeled ‘action’ games, after all!

I’m not ready to claim my side on the whole, “should games be about fighting/violence” debate, but I am ready to strike an interesting point.

The epitome of action games which reward violence. CREDIT: G4TV

 

What if you made a game that involved fighting, violence, etc. but that was not the point of the game? The player would not be glorified for it. The action would be part of the plot, just like basically 100% of literature with violence involved. I’m not saying violence in games is bad, I’m just entertaining this different approach.

Imagine a Metroid or Castlevania where the real focus was on advancing the story. You would traverse levels overcoming enemies, certainly, but the enemies would only be present as a challenge to advance the story, rather than dedicated punching bags.

A great example of this type of game is Sword & Sworcery EP by the Superbrothers. CREDIT: IGN, obviously

 

One merit of this idea is that it indeed makes more sense if you’re trying to cast the player in the shoes of the protagonist. Unless the protagonist is a blood-thirsty marauder, they’re probably more focused on resolving the current conflict within the story. In a cliché example, “oh no my girlfriend has been kidnapped, I must save her!”, the hero is probably more focused on getting his girlfriend back.

Oh that Castlevania! CREDIT: Gameaxis

 

The idea of this type of game is that there are no level-up mechanics, no serious emphasis on fighting at all.(that is, unless it plays a role in the story.) Again, the player isn’t rewarded for fighting or killing; it’s simply there because that is your story. Your story, o’rly?

This approach to creating the game demands a different method, of course. Now you must design your game around your story, instead of designing a story around your set of game mechanics. In this type of game, the story is king.

You might be screaming “visual novel!” right now, but that’s not the idea.

Visual novels, while great, they’re not what I’m getting at exactly. CREDIT: astatalk.com

 

The idea is to create a game which isn’t about rewarding the player for violence or drudgery upon others. It’s a game which is story-focused, but still retains it’s game-like aspects, such as in Zelda or Castlevania, and does not leave itself as a sequence of cutscenes or interactive “quick-time” events.

I’m not saying I’m the first to think this up—I’m not. But these are my musings on the idea. I’m very interested in taking this approach for my next game. What do you think?

Fascination with pink?

Mockup Week Day 7: Graveyard

YAAAAHHH!! *huff* *huff* *huff*…. It.. *huff* *huff*.. Seems fitting that a graveyard is under a layer of hot magma. *huff* *huff*

These tombstones are spooking me out, and I can’t help but feel like a nasty monster is going to come get me. The ground here is dark, and the air is filled with echoes of the dead. I don’t like this place.

Mockup Week Day 6: Lava Layer

Needless to say, that lava looks HOT. You definitely don’t want to be mucking yourself up in that. Soooo, how far down into the ground are we now? This is definitely not good.

Mockup Week Day 5: Mineral Deposit

We’ve hit gold, Smithy! Wow! The walls of this cavern are strewn with colorful gems. If only we had a pickaxe. Ick! We just go out of a garden of glowing purple mushrooms, now we’re in a cavern full of expensive gems. Bloody hell, what could be next?

Mockup Week Day 4: Radiant Garden

And as you descend to the next level, you see glowing mushrooms. Apparently you were exposed a tad too much to the poisonous mushrooms from the previous level, since you must be crazy to see glowing mushrooms.

But wait, you aren’t! This mystical mass of otherworldly fungi is known as Radiant Garden, referred to in myths are the best place underground to get a tan.

Mockup Week Day 3: Fungi

Well, I see what all that water has done! Moss, mushrooms, and other fungi have grown everywhere down here. Oh my! Let’s watch our step, and hope we don’t pick the wrong mushroom to eat. Gee, this is pretty surreal… I’m sure things will get normal later.

Mockup Week Day 2: Wet, Wet, Wet

Apparently someone dug into a huge underground water reserve! This place is wet, wet, wet, and it’s making my boots soaked. Down here its cold and chilly—Staying too long might catch you a cold. Brrrr!

Mockup Week Day 1: Dry and True

Dry and True! The dusty, dry, rocky cave that we’ve all seen before. The ground is sparse and rocky; and the walls seem to be red to very much the tone of red clay. The carving of the walls and floors suggest that this cave was not created by natural means; So who did this? Tomorrow we can go deeper to find out!

Mockup Week!

Starting tomorrow, every day I will be posting a mockup of a new "stage" in my game.

Stage of what, you may ask? As you descend the Cave you will traverse radically varying landscapes; each unique landscape is a stage.

I will be posting a picture along with a short teaser on what each stage will play like.

See you tomorrow!

Coming First: "Dry and True"

Protector Rush

As a sort of weekend project I decided I’d try out Flixel! With that, I began writing a small flash game which would be sort of a “prequel” to what goes on in Pocket.

It was fun!

Working with Flixel was kind of a pain at first since I had been working with FlashPunk for the past 8 months. That said, me and Flixel quickly warmed up together and became great friends.

For kicks, the game is up at FlashGameLicense. Let’s see if I can get a sponsor! I’ll post it here if it looks like my FGL venture isn’t getting anywhere.

The game was inspired by a certain game in dev over at TIGSource, as well as Final Fantasy XIII and the desire to make a game that’d work on Android phones.

Coming next: MOCKUP WEEK

Just a little piece of art!

Here’s a break from the recent Pocket updates!

A little bit of scribbling from me, this was pretty fun to do. It took about two hours—still need to work on that background if I decide to continue on it.

Optimizing

Lately in Pocket's development I've been focusing on some of the things I outlined in my "Pocket's Future" article, along with some other usability and deep code improvements. But, one outward-standing thing I've done since the past update is add a lighting system and some puddles.

These operations are very transparency-heavy, as are many of the effects in my game. And guess what? Flash seems to suck with transparencies.

Some statistics taken on my computer:

When my game is idle in The Pocket it reaches a fairly constant FPS of 125. When I disable the HUD, which is quite liberal with transparencies, the FPS actually doubled. Yes, that's right, up to 250 frames per second when idle.

On average my game took less than a millisecond to update, when in action it would usually take a single millisecond, and in heavy action it can reach 2 milliseconds, with a rare 3. Whereas, the render update constantly takes between 4 and 20 milliseconds. Most of the rendering burden seems to fall on the transparency operations. When disabling all transparencies, my game will stick to the lower side of the spectrum, and with all transparencies turned on in a effect-heavy Cave room the update time will nearly reach 20 milliseconds and above.

With those clock rates, at about 25 ms to update, my game gets about 40 frames per second.. Ehhh~ The ideal rate in my game is 60.

So this brings me to my important point today: Optimization!

It is so very very very important to do clocking tests like these when making games, you have no idea. I'm glad I discovered this now. THIS is why you make a graphic options menu-- Just saying. On a lower-end computer than mine, a player might run at only 10 fps with all effects on! But if I allowed them to be turned off, that same computer could run the game at the desired 60 frames.

Since I'm going to try to support flash devices like Android with this game, optimization tweaks like this becomes even more imperative, I think. Even if update speeds aren't a problem for the phone, battery power most definitely is for every device user, and with that it's important to give them options to lower the CPU usage of my game.

Another very important method I've found in reducing battery usage is allowing the player to adjust the maximum frame rate of your game. Estimating, a game capped at 30 fps only takes half as much battery power as one running at 60 fps. That could mean A LOT for a device user, who manages every task process to conserve their battery. Making my game more power-efficient and easier to run on devices is obviously necessary if I want to make my game at all viable to play.

Splash Splash

Image embedding is being a hater soooo:

Click this to see some epic puddle action

Update Batch!

Hey everyone! Today I'm going to talk about some recent updates I've made to my game, and my methodology behind them. So, I'll jump right to it!

Most notably, I've changed a few things in the Cave generation.(what else is new?) As you might have noticed from playing, the difficulty curve is rather... Well... Insane. You can be in one skinny hallway, go down a floor, and be mobbed by 100 enemies waiting in a large open cave area with no cover or way out to be seen. You try to block-dash your way to safety, but your shield breaks and you get F@#&'ED.

To add to that, I wasn't even able to get past level 15 at best. Ouch!

So for one, I mellowed down the algorithm's a little bit. The room size doesn't blow up so quickly now, and most importantly I changed the enemy spawn method. Before, my "level builder" code would scan every empty space, and take a random chance and place an enemy there. The disadvantage of this system is that while it does fill up all space rather evenly, cramped floors become rather sparse, and large open areas become rather hellish.

To that effect, I changed the spawn method to become quantity-based, where the generator will predetermine how many enemies it will spawn, and then pick fitting places for them on the map. In the end, it gives me much more spawn control, and later it will allow me to do some cool black magic with enemy spawn patterns. Now the difficulty is much more manageable.

Now then, a small update on the HUD. As pointed out by JWK5, it was nice that the magic gems in the HUD would "blink" when you killed an enemy to show off that you were gaining MP, but it wasn't enough information for him. He wanted to know how close he was to getting his next full gem, so that he could plan around it. And for a while I thought about it and came up with a method that would make sense-- The gems slowly saturate until they hit full, where they begin glowing in the center. Overall, this works out very well. I suppose it's obvious that you should provide the player with this kind of information, so they can better plan their moves.

To add onto the graphical increases, I've been broadening the tileset and adding more variations. Grass tiles are no longer awkward blocks, and I've created more dirt variations and stuff like that. I also created new torches, which I'll talk about in a bit. Soon there will be small water puddles and things like cobwebs in the Cave. While they don't impact the gameplay at all, they tremendously add to the experience and engage the player in my game. Creating this kind of atmosphere helps me pull the player into my world and have them, at least somewhat, feel the world of my game and make the experience much more 'real'.

And now I've been working on the game's story. Well, implementing it. Now there is finally a much needed intro dialogue when a new Protector is created, and it gives a short and sweet introduction to the general mood of the game. The goal of the introduction isn't actually to tell the player anything, the goal of it is mostly to make them want to know more. With that, I've began adding parts of the Cave's story(yes it has a story), and I rewrote my text wrapping algorithm and it now works excellently.

For my last update, last night I added lighting. It might surprise you at how amazingly this affects the game's atmosphere. Or, maybe it won't! Either way, it definitely helps give a great sense of depth, and it'll let me do cool things like day/night cycles and make the cave totally creepier. That's where the torches come in, of course!

Anyway, that's all for today! Next time: a gameplay teaser trailer!

Thanks for reading!

Pocket's Future; Pt.2

Hello readers! This is part 2 of my little series on where I'd like to go with Pocket Protector. Read to to learn about my ideas to "flavor up" the game, and better dazzle the players!

So, I realize that peoples' expectations for Flash games tend to be fairly low. This gives me two options. One, I let these expectations act as a crutch for myself and allow my game to deliver a fairly low amount of production value. Option two, I take this opportunity to make my game even more of a standout. I choose option two! Although my game isn't visually or soundingly stunning, and although it will never rival that of a first party game, keep in mind it is in Alpha! That said, the visual style is probably going to stay pretty constant from where it is, but I do have plans to increase the atmosphere exponentially.

That said, it's immediately obvious that the atmosphere of "The Pocket" is nothing but lacking. It fails to really warm you up to the silly community of Pockets that live there, and fill you with the quirky and comedically misled society that I'm aiming for.

For one, I need music in my game. I'm slowly working on my composing skills, but it's taking it's time. Music and sound is a huge part of a game's atmosphere, of course, and I really want to get that right in due time. To boot, some extra sound design would greatly benefit me. Perhaps some minor, silly voice acting would be appropriate, to the execution of The Legend of Zelda: Ocarina of Time.

And finally, I think I need to 'liven up' the Pocket a little bit, visually and interactively. More hints of people living their, and more things to do and explore! More on that in a bit.

One thing that I'm constantly suggested to attempt is multiplayer. Everyone says multiplayer would be great. First off, online multiplayer is very unlikely, and it's the only way I can see the game working with multiplayer. "Hot seat" gaming doesn't sound very good, it simply doesn't fit my gameplay or the topology of my control scheme. And from what I've heard, Flash isn't the best at live network gaming. In the future I might look into it, but for now the answer is "probably not". I wouldn't even think about attempting that without funds to set up a reliable server. That said, I think multiplayer would be absolutely awesome in my game, and if I were ever to redesign my game and reprogram it, I'd definitely make it with multiplayer in mind.

So, if you've really explored The Pocket, you probably saw the currently un-enterable building called "Protector Place". I really want to flesh out the world of the game by adding a full library of various things to read about the game. Learning about the backstory on your own whim instead of simply button-spamming through a cutscene so you can get to the action yourself. I'm actually pretty excited for this, although perhaps it's questionable at how significant this will be to players. Let me know, I really want to hear what people think!

Lastly, talking about the far future of my game! I'm very interested in porting and advancing my games for other platforms. If my game is successful, I might have a good leading entry into getting somewhere. I'm thinking about creating an Android port, as the game was originally intended to be a handheld game. But my 'dream port' would be for the Nintendo 3DS, which is probably unlikely, but that would be awesome. Although, know that the first thing on my to-do list after I finish the first complete version is to optimize the game for touch-screen devices, like Android!

So that's it for today! This was part 2 on my series about Pocket's future.

Next time: Some recent updates to the game, and design theory from me about why they're important.

Later!

Pocket Protector 2.5 Released!

Haha! Guess what people?!

Pocket Protector Alpha 2.5 is ready to be played! The link in the sidebar has been updated-- Have at it!

General update list:

- Bugfixes

- New player notification system

- Shops

- Break room

- Cave generation improvements

- Arrow box trap

- Score multiplier

- Books

- GUI improvements

- Balancing

- Did I mention bugfixes?

Pocket's Future; Pt.1

So, today I'm going to start talking about my future plans for Pocket! Is this a futile hype attempt? Maybe! But I'd like to share some of my ideas for where I'm going with this game, and hopefully get some feedback. After I wrote out my outline for this post, I knew there'd be no way to do it all in one writing. Therefore, read on, for this is Part 1 of a two part series on the future of Pocket Protector!

First off, I've designed my game core to be very flexible to my demands. When I started this game, I knew I'd be shifting my gears quite a bit, and adding content that I had never planned in the first place! This game has been designed to be updated after official 'release'. As time goes on, the idea is that I'll continue adding to the game.

So, right now, if you've already played the game, you've noticed there's only one area to go into: The Cave. It's nice, but I'm sure that after a while you got tired of seeing those brown walls. If you're not sick of them already, you will be. For the future, I plan on designing entirely new levels to explore, built on entirely different generation algorithms. I wouldn't want to recycle the same old code skinned with a different tileset. I'm aiming to provide a completely different level-diving experience in each separate area.

One that I have in mind is the "Deep Forest", or perhaps a Jungle, full of wildlife and flora, neither of which would necessarily be 'kind' to you. And of course, to honor the age-old RPG tradition, I've been entertaining the idea of creating a dungeon. Wouldn't it be awesomely creepy if prisoners were shrieking at you from inside their cells as you went by? I hope the player doesn't do anything to simultaneously open all the cages. *maniacal laugh*

One thing that keeps coming to my mind as 'absolutely awesome' is status effects. Yeah, I know, when you or I play RPGs these status effects are like, "Ugh, again? f***". But, alas! Effects like poisoning, burning, and even more obscure effects sound like a whole lot of fun. Wouldn't it be awesome if the Red Burst spell set enemies on fire? I think it would. What if cave bats poisoned you? Even cooler: What if you used a spell to "set fire" to your weapon, letting you swing a flaming sword or shoot a burning arrow, or what if some natural gas was spewing out of a hole, and you used a fire spell on it, causing a massive explosion? Things like this all sound pretty fun to me.

But of course, I want to keep giving the player new things to do. That's what all of my development is right now, as I near the first complete release. After that, I want to start giving the player more slots to equip weapons and spells, and I want to give the player many, many more magic crystals.(current can only obtain one.)

Isn't that boring without other things to put in those slots, or use those magic crystals with? Yes. *reader nods*

I want to begin adding more powerful magic spells to the game. Higher cost, higher output. Typical RPG fare, I suppose! While trying to avoid typical tropes, I'm working on designing lots of strategical spells, and those which work with and have an effect on the environment. We'll see!

So everyone, thank you for reading! That concludes Part 1 of Pocket's Future. Next time: Pocket's Future; Pt. 2!

A Protector In Every Pocket

So here I am going to formally introduce my Pocket Protector project.

Pocket Protector started when I was bored in class, early this month last year.(there's actually a post on it~) At the time, I was working on a game called "Messenger Boy", which didn't go over so well in the end. After that game epically failed, I reminisced to the utter fun I had making Pocket Protector, and hence continued my work on it.

The game draws upon experiences from my favorite action RPGs and score-based arcade games, and the overall goal of this game remains to be a easy-to-play, addicting, yet involved and in-depth Flash ARPG. From the beginning I knew I'd have to encounter the limitations of Flash before too long, most importantly the limitations of the players.(note: flash game attention span.) Nonetheless, it hasn't stopped me.

When I was thinking up the name, I wanted it to be something simple and at least relatively catchy, so it became "Pocket Protector". The name comes from my idea that this game would be be played as a handheld game, and it was a totally funny idea thinking of a little critter smashing baddies in your pocket, contained in your smartphone or whatever.

Oh, and there's that link to play the game in the sidebar. Click it, play it, give me feedback! Yeah!

My next article: Ideas for Pocket's future!

Pocket Protector Alpha 2.5 Feedback

Returning from the grave

To centralize my work once again, I'm bringing back this blog in full-force.

First article: Pocket Protector, the Flash game that breaks the mold with the bald.

Cave/Dungeon Generator Breakdown

I've been requested to write an exposition on my level generator-- So here I go!

First off, you can download the functions used to generate my levels HERE

If you don't have Game Maker, just open the file in any text editor you'd like. #define denotes a new function.

The breakdown:

To function, my level generator is based on a grid of true/false booleans. True means the space is filled in.

The very first thing my generator does, is go in and fill every space of the grid with TRUE. And here, we run into the first variables my generator works with: Width and Height.

WIDTH - Defines the width of the grid

HEIGHT - Defines the height of the grid

Derp.

Next, my generator selects two random points on the grid as START and END points. If they are too close or too far apart, the generator will select another set of points, ad nauseum until it selects two points it's satisfied with. Two variables are used for this:

MINDIST - The minimum distance between start and end

MAXDIST - The maximum distance between start and end

Now, the basics are pretty much covered. That's all the setup it takes to begin generating.

The next thing it does is enter a while loop, denotated by a variable called 'keep', a boolean variable so that we can abort the generation at any time.

My generator works on a random 'path carving' system. It's direction is randomized, with a chance for it to change every loop. Although the direction is randomized, it is tailored to have more probability to go towards the END point, which is the ultimate goal of the generator.

DIRCHANGE - This is a probability(out of a hundred) that the generator will change direction.

The path carving goes in a single unit of it's direction every loop cycle. As this is going, if the path gets close enough to the END point the direction will stop being random, and the path will be carved straight to the end.

KILLDIST - The distance from the END point at which the path will stop moving randomly, and move straight towards the END.

Quick stop: There are only two conditions where the generation will stop:

1) The carving point hits the END point.(desired)

2) The loop iterates over 1000 times. I created this as an initial failsafe, however, and it might not be necessary for you. Might cause trouble with larger map generation where the iteration really do go over 1000.

So, while the generator is going along it's merry way, it has a chance to create a tributary. Although this is a term for a river branch, I could not think of anything better at the moment. It's the same idea as a river, though. Tributaries use two variables:

TRIBUTARYCHANCE - A probability that the generator will make a tributary

TRIBUTARYKILL - A probability that the tributary will stop in it's tracks

My tributary carving is done from creating another loop within the original while loop, almost identical to the original loop for initial path carving. Tributaries act on the same DIRCHANGE variable to change direction, but are not tailored to go towards the end point.

With the TRIBUTARYKILL variable above, the tributary can also stop at any moment.

If the tributary makes a turn and hits a block that has already been carved out, it will also stop.

As a twist, if a tributary hits the END point, it will NOT stop.

Those are the basics of the cave generation.

Smoothing is operated by a simple algorithm that iterates through the grid and does neighbor-checks on the grid to see if the grid point should be solid or free. They're very easy to understand. I wrote four different variations, all of which give very different and interesting results.

Refinement is a process which doubles the size of the grid(stretches it), and then performs smoothing on the doubled grid.

Very useful for creating different variations of caves.

What if you want a large, open cavern, but it seems like my grid is restricted to more path-like generation? Assume your game operates in a 64x64 map.

For example, you can create a 16x16 grid and generate. It will be fairly small, and lots of the grid will be open, much like an open cavern. Through doing the refinement process twice, your grid will now be 64x64, and you will have achieved a large, open cavern, rather than a small tunnel-based map.

That's all for me,

I'm still discovering the very potential of my generator, myself. But it seems there's quite a bit I can do with it.

Until next time~!