Wednesday, October 12, 2011
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
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
Sunday, September 25, 2011
![]() |
| 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!
Monday, September 12, 2011
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.
Friday, September 9, 2011
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!
Saturday, September 3, 2011
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.)
Spoiler: it's about the game's storyline.
Monday, August 29, 2011
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.
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.
Saturday, August 13, 2011
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.
Subscribe to:
Posts (Atom)
