Categories
Personal Development

Writing Tips for Non-Writers

I found a good post about writing through Wil Wheaton’s blog called Writing Tips for Non-Writers Who Don’t Want to Work at Writing by John Scalzi.

Scalzi presents a list of rules to follow to write better without exerting too much effort. I have tried to follow rule #7, “Try to write well every single time you write”, after getting introduced to Instant Messages and email years ago because I was afraid I would lose my ability to punctuate sentences correctly. Writing is about communicating, and it can be very frustrating to read terribly written IMs and forum posts.

In the comments there is some disagreement about the use of the word “alright” as opposed to “all right”. I have always used “alright” and never thought that it was the incorrect usage because I lost a spelling bee when I was in the 3rd grade due to that word. I spelled it “allright”. I was eliminated as soon as I got up there. I always remembered it. Now apparently the whole premise behind my loss was wrong. That spelling bee was a sham! At last, vindication!

Of course, language evolves. I think “alright” is a perfectly alright word to use (stupid spelling bee). I also wonder if ending sentences in a preposition will be accepted eventually. After all, the purpose of writing is to communicate. If you spend more time trying to be proper and by the book than is necessary to communicate to your audience, I think it has a tendency to be perceived as stuffy. of course I think that punctuation grammar and speeling is importent so it isnt like everything should be done away with

Please tell me you winced at that last “sentence”. B-)

I also found Elmore Leonard’s Ten Rules of Writing through the 43 Folders site. On the idea that writing doesn’t have to be formal or proper:

Or, if proper usage gets in the way, it may have to go. I can’t allow what we learned in English composition to disrupt the sound and rhythm of the narrative. It’s my attempt to remain invisible, not distract the reader from the story with obvious writing.

Categories
General

Happy Valentine’s Day!!

Or, for you single people, Happy Ferris Wheel Day!

Categories
Game Development Personal Development

Thousander Club Update: February 13th

For this week’s Thousander Club update:

Game Hours: 10.5 / 1000
Game Ideas: 58 / 1000

Since I technically started tracking the last week of January, I’ve decided to readjust the total numbers I should keep as weekly targets. Today I should have 63 to keep on track for 1,000 hours by the end of next January. Otherwise, if I kept the old numbers, I would constantly feel bad for not catching up with almost a month of inactivity.

I’m hitting my goals for game ideas, which are fairly easy to come up with each day. I could think of three to 10 ideas in a few moments.

On the other hand, game development takes time. I can’t immediately get one, two, or three hours of game development. While I can’t always dedicate hours of development each afternoon, I think I might need to come up with a simple list of 5, 10, or 15 minute game development activities. I managed to get 30 minutes of programming before going to my day job this past week because I was finishing up some code I wrote to experiment with TinyXML. I think if I can take advantage of more “weird” windows of time, I should be able to make greater progress than if I expected to work during scheduled sessions.

Categories
Game Development

Oracle’s Eye Development: Configuration Parser and Loader

Yesterday I finished by saying that I was working on adding a configuration loader . I added some stub code so that I would be ready to start working right away.

I realized that while I have coded a text parser before, I never had to worry about getting configuration data out of a file. What would I actually need? Before agonizing too much over it, I thought that it was more than likely that a ready-made, well-tested solution already exists. I spent some time looking through books, notes, and Gamedev.net before finding someone asking the same question I was: isn’t there a an easy to use tool so I don’t have to reinvent this obviously already solved problem?

One suggestion was boost::program_options. I looked into it for a little bit, but another suggestion was to use TinyXML. At first, I thought that using XML was a bit overkill for configuration files. At the same time, it would be ideal for holding the levels, and if I could kill two birds with one stone, all the better. The best part? TinyXML is already in my project! It comes with the Kyra Sprite Engine.

I spent the day reading the tutorial and trying out some test code. It took me only a few moments to get an XML configuration file to load successfully, and a bit more code allowed me to view a few of the elements. I spent the evening learning how the library works, and it seems easy so far. I wish there was some better documentation out for it, though.

My configuration file used to look like:

TimerInterval 80
SpriteSize 64
LeftEdge 64
UpperEdge 64
Ball velocity 5
Player velocity 5

and I wrote it before I wrote more than a single function to help parse it.

Now:

<?xml version=”1.0″ ?>
<!– Configuration for codename: Oracle’s Eye –>
<Config>
<Timerinterval interval = “80”/>
<Spritesize dimension = “64”/>
<Border leftEdge = “64” upperEdge= “64”/>
<Entity>
<Ball velocity = “5” />
<Player velocity = “5” />
</Entity>
</Config>

Unfortunately, I haven’t been able to do more than grab the root element, but I’m still learning how this library works. I’ll hope to be able to finish the configuration loader within the week. Afterwards, it shouldn’t be too much more work to write a level loader with TinyXML as well.

Categories
Games Geek / Technical

Red or Blue?

The following just happened today at my day job:

Me: (out of nowhere) Red team or Blue team?
Coworker: … uhhhh…
Other Coworker: What?
Me: Red team or Blue team?
Coworker: What is this about?
Yet Another Coworker: What’s going on?
Me: Red team or Blue team?
Yet Another Coworker: What’s that about?
Me: Why does everyone ask me that?!?
Other Coworker: (pointing at me) Dweeb.

I’m the whimsical one at work, if you couldn’t tell. B-)

Categories
Game Development

Oracle’s Eye Development: Jumpstarted!

This past Saturday I worked on Oracle’s Eye for the first time in over a month. When I last worked on it in late December, I was trying to update the Frame Rate Independent Movement code I created. It was good enough when I implemented it, but I had a nagging suspicion that I didn’t do it right. I never did check in the changes I had made, and since it has been so long, I had to figure out what I was doing and then do it.

Originally, my code required that the Ball and the Player had movement functions that took an argument. This argument was the delta. For example, the Player could move 5 pixels each frame. 30 frames per second would mean that the Player should move 150 pixels per second. Of course, each frame might not be exactly 1/30th of a second, so I would have to calculate how far to move each frame so that the movement seems smooth. If, for example, a frame takes 1/30th of a second, then the delta multiplier should be 1. If it takes 1/10th of a second, then the multiplier should be 3. A frame that took 1/60th of a second would result in a multiplier of 0.5.

The sad thing is that it wasn’t all that clear how it should work when I originally implemented it. Also, I didn’t understand how to repeat the exact results in case I wanted to script it, nor did I know how it would work if I ever wanted to run a networked game on multiple platforms. After reading through a few more tutorials, I decided to fix it. I based my new code off of Sol’s Tutorials. Running the example game, I noticed that it isn’t terribly smooth itself. It periodically seems that the player’s ship takes small jumps. Perhaps it isn’t the best example to use? I’m open to better implementations if they exist.

This implementation works by setting game updates to specific time intervals. If the Player should move at 5 pixels per frame, then each update will result in a movement of 5 pixels. Multiple updates can take place during each rendered frame, but it is really easy to track the movement for each frame and use the data to accurately reenact it. For instance, I could eventually code replay functionality, which would be a great way to show solutions to the puzzles. I had to change a lot of the code to allow for this change, which shows how fundamental FRIM code is to a game engine. It wasn’t terribly difficult, and it didn’t take me too long.

The best part is that I’m familiar with the project again, which means that I won’t feel apprehension whenever I think to work on it. There were a number of days last month when I felt guilty for not working on the project. I just felt uneasy about the project, and while originally it was probably because I needed to focus on the direction to take it, it eventually was due to the fact that I hadn’t worked on it and had vague thoughts about not understanding it. Rationally, working on it would necessarily bring back familiarity, but it can be tough to pinpoint the fear sometimes.

I decided to focus on coding a configuration loader next. Basically, if I wanted to change the speed at which the Player, the Ball, or the game engine ran, I would have to recompile. Being able to load the configuration dynamically without recompiling or even rerunning the game would do wonders for productivity. I wrote some stub code on Saturday, and I will work on it this week.

Categories
Game Development Personal Development

Thousander Club Update: February 6th

While I could more easily catch up with the number of ideas I need for this week, I know it will be incredibly difficult to catch up with the number of hours to put in. After all, during a week, about 21 hours need to be fulfilled in the first place. To catch up with the previous hours I missed would be terribly difficult. But as Scott says, actually achieving the 1,000 hour mark is not as important as keeping development at the front of my consciousness. In the past 15 minutes to a couple of hours a week was considered good enough, but I joined the Thousander Club to do great. My status so far(actual#/for the week/for the year):

Game Hours: 7 / 21 / 1000
Game Ideas: 37 / 21/ 1000

So I did a little better with regards to new game ideas than I needed to for the week. Ideas are a dime a dozen, as they say, but it is still good to have them. There is no need to lose any creativity to forgetfullness since I’ll be able to leverage it in the future with new ideas.

Game development hours showed a marked improvement over the previous week. A few hours might not be directly related to Oracle’s Eye, but I’m counting my practice time with The Gimp since I think it is a skill that I can leverage with game development. I was using a number of tutorials, including the ones mentioned in an indiegamer.com post as well as a few Gimp-specific ones. You can see the results of my work from Friday and Saturday morning here:

First attempt 35KB
Second attempt 57K
with planet! 55K
with atmosphere…kinda 54K

The rest of my time was spent on programming, and I will cover what I did in another post.

Categories
Personal Development

Game Development at Full Throttle

Action wrote an article called If you knew you would succeed, how would you go about your work? that I found to be pretty insightful.

If you knew your current project was going to be a success, would you get more passionate about it? Would you exert more effort to see it through? Would you try to complete it faster?

The point here is…if you know you’re going to succeed…why are you hesitating and slowing down progress towards your goal? You may make routine progress…but if you’re going to succeed, why not take steps to reach that success sooner and more deeply?

I’ve dedicated this Saturday to game development. The last time I did so was for Game in a Day, and it was definitely my most productive development session. I think that taking such massive action should help jumpstart progress on Oracle’s Eye. In the past I would have only a few moments of real work at a time. Now, I want to take my game development full throttle.

Categories
Marketing/Business

A Great Game Demo

How to Be a Demo God by Guy Kawasaki gives 11 tips to entrepreneurs looking for venture capital at Demo.

While I don’t plan on being involved in Demo in the near future, I was wondering how his points can apply to a shareware game demo. Some of them don’t seem to fit at all, such as “do it alone” instead of with a partner. Then again, making sure you demo runs on its own instead of requiring the existence of exotic-third party applications might be something that would be desired.

So how can they apply? I’ll try to answer, but feel free to chime in with your own thoughts. I don’t have the personal experience of putting together shareware demos myself, so what follows is what I’ve gleaned off of the various shareware marketing and sales articles and posts out there.

  1. Create something worth demoing. It’s generally understood that your game better be able to stand up on its own. Not all good games sell well, but all bad games definitely don’t sell or sell for long. The demo is supposed to be a small part of that awesomeness that is your game. If you are showing a small part of junk, your customers will know. Don’t begrudge this fact; it’s how shareware is supposed to work. The way to compete is to make a good quality product.
  2. Do it alone. I suppose if I stretch I could say that your game shouldn’t require your players to install five different third-party libraries that aren’t included with the demo. Maybe another interpretation is that getting onto a shareware compilation is also bad; being one of the “best 100 Windows games”, for instance, you’ll get lost in the crowd. If someone tries your game demo and likes it enough to pay for the full version, how likely is that person to say, “But let me check the rest of the games to see if I like something better”?
  3. Bring two of everything. Some people lose sales because the demo couldn’t run on certain computers. If DirectX support is not available, OpenGL might work better. Message boxes might pop up and disappear before a person can read them, so use a log file to store the error messages. Having a Windows version AND a Mac OS X version might double your possible sales.
  4. Get organized in advance. Your game’s demo is part of the marketing of your game. Don’t just take the full version and cut out a bunch of features and throw it out there. Really think about what would make it a good demo. How does it fit into the rest of your marketing plan?
  5. Reduce the factors you can’t control. If your demo requires the Internet to function, it should say so. Otherwise, don’t assume an always-on connection because it might not be there. What resolution do you need? Don’t assume that your customers will have a 1920×1200 resolution monitor. If you do need certain factors to be there, you should state so in your system requirements. Those should be easy to find on your website, I think.
  6. Get to it. Do we really need to learn who you are or what libraries you used as soon as I start the demo? Show me the game! I don’t know if showing Buy buttons is a bad thing that early in the demo, but I would imagine that until the person plays the game, having a BUY NOW splash screen before getting to the main menu would be more of an annoyance than anything.
  7. “Do the last thing first.” I read that Daikatana is actually a decent game, and I’ll be playing it this year to learn for myself. I also read that with all the hype surrounding it, people were turned off by the first couple of levels. They were apparently boring. I think it will probably be fine to say, “The full version features even more weapons!” but the demo should at least feature some awesome weapons too. If you have a puzzle game, I think putting only easy puzzles in the demo is a problem as well.
  8. Then show the “how.” I’m not sure how to apply what Kawasaki was saying to the game demo, although I suppose a tutorial would be one way. IGF finalist Flashbang Studios’ Glow Worms is a good example of a game that had a nice tutorial to show you how to play. On the other hand, I know that Darwinia, as great a game as it is, was hard to get into at first. I didn’t know how to get the game to recognize my mouse gestures because I didn’t know I was supposed to be on a specific screen to do them.
  9. Cut the jargon. Your customers want to play the game, not reconfigure their computers. While drivers need to be updated and libraries need to be installed, don’t expect your customers to hunt for files or do anything out of the ordinary.
  10. Don’t take any questions until the end. I’m not sure if this one applies at all. If your customer has a question, answer it! Also, record it and resolve to fix your demo so that those questions are addressed before they ask. Make it so you don’t have to worry about being asked questions until the end.
  11. End with an exclamation point. Your demo should start awesome and it should end awesome. Don’t fizzle out or people will think that with the exception of that first part, which they’ve already played, the entire game is boring.

I suppose there is a challenge applying these tips to shareware games. You can’t depend on the player making it all the way through the demo, so you can’t easily define the “end” of it for that potential customer. Perhaps it shows that there is a flaw in your game demo? Should your demo be so good that people play through it completely, or is it possible to be better even if the person only plays a portion of it? If the person stops part of the way through, will they simply uninstall and forget it or will they actually drop you a line to tell you why? With a shareware demo, your captive audience isn’t forced to sit and watch for six minutes. Your demo better be spectacular and make the potential customer want to see more.

Categories
Game Development Personal Development

Thousander Club Update

Besides attempting to work on game development for 1,000 hours this year, I also wanted to come up with 1,000 new game ideas. The Thousander Club is definitely a great way to raise your game.

As a reminder, I should have about three hours or ideas per day. Below I list my actual numbers versus the numbers I should be at:

Game Hours: 1 / 83
Game Ideas: 11 / 83

Ahem. Not so good, but I didn’t join until the second week of January. Still, it doesn’t justify the majority of the missing numbers.

If I notice that I am getting down on myself too much for not hitting the right numbers, I might start displaying them differently. Until then, I think it is good to know what progress I am making as well as how far along I should be. I will try to post these updates regularly on Monday.