Showing posts with label Process. Show all posts
Showing posts with label Process. Show all posts
Saturday, March 21, 2015
Marketing Guide for Indie Game Developers
I just recently stumbled upon The Marketing Guide for Game Developers and wanted to share it. There's a LOT of good information in there, spanning the gamut from working on the quality of your game to working with the press, blogging, social media, advertising and so much more. If you're new to marketing like myself, definitely check it out!
Monday, February 16, 2015
Code Isn't Everything
I recently saw this Gamasutra blog post by Pascal Bestebroer, titled "My game's done. Now comes the stress, struggles, and adrenaline of a one-man team doing his own PR". And I thought... HOW RELEVANT!
For the longest time I was laser-focused on writing the code for my game. And I would occasionally blog about it. But I didn't give much thought to marketing the game after it was completed. Kudos to Mr. Bestebroer for starting his PR as early as the first week of development! This guy clearly has had more time in the trenches than I.
Marketing is perhaps more important than the coding of a successful game, at least by conventional definition of success. For me, I think just getting my game out on the Google Play store will be a success. But it's good to realize, as I'm learning, that you're not done once the game code is completed. And if you can get a head start on your PR efforts, the earlier the better.
For the longest time I was laser-focused on writing the code for my game. And I would occasionally blog about it. But I didn't give much thought to marketing the game after it was completed. Kudos to Mr. Bestebroer for starting his PR as early as the first week of development! This guy clearly has had more time in the trenches than I.
Marketing is perhaps more important than the coding of a successful game, at least by conventional definition of success. For me, I think just getting my game out on the Google Play store will be a success. But it's good to realize, as I'm learning, that you're not done once the game code is completed. And if you can get a head start on your PR efforts, the earlier the better.
Thursday, June 2, 2011
Phoenix Rising
You, my dear reader, deserve better than excuses. But I'm afraid that's all I have for not posting in such a long time... just one single excuse... life :) Things have been so busy, in fact, that I've barely had time to work on my game that I've alluded to in posts of olde. But if you somehow have my blog still on your "pages to check" list (or RSS reader for the web-savvy folk), I thank you for checking back. And I look forward to reviving this dormant space.
I have much to write about, having worked in XNA for about a year and a half at this point on a single game project. But I figure, as an old proverb states, that "even a journey of 1000 miles starts with a single step."
Btw, while I was gone Blogger added some new features. Just for fun, check out this blog in some new dynamic views (requires IE8+, Firefox 3.5+, Chrome, or Safari):
I have much to write about, having worked in XNA for about a year and a half at this point on a single game project. But I figure, as an old proverb states, that "even a journey of 1000 miles starts with a single step."
Btw, while I was gone Blogger added some new features. Just for fun, check out this blog in some new dynamic views (requires IE8+, Firefox 3.5+, Chrome, or Safari):
Tuesday, September 21, 2010
Three Lessons Learned
So I think I mentioned in my last post (two months ago?) that some buddies and I were working on a tower defense game that we hoped to demo at an upcoming conference in September. As you may have noticed, September has almost come and gone but I haven't posted any stellar updates detailing the success of our demo at said conference.
Part of this is due to an unavoidable stall in development progress, which brings me to my first lesson learned. When I realized the ever-increasing scope of the game I would soon be writing, I should have pulled in more developers. As it is, I am currently the only programmer among a group of two 3D artists, two concept artists, and one musician. Although there is a certain amount of pride in being able to take full ownership of the (increasingly large) code base, there is also much to be said for having a fellow to bounce ideas off of and having someone to share the load when you're not available.
Another thing that's bitten us in the development of our game is not understanding core requirements in the beginning. We think we have a great idea for a game and started prototyping the basics right away. For a simple tower defense game, you have enemies moving from one end of the screen to the other, and that's what we created initially as a 2D game. Once we had this basic prototype, we realized that it was pretty darn difficult to make projectiles with faux-depth in a 2D isometric view look right. So we had to make the leap to the third dimension, which involved converting our 2D sprites into 3D rigged/animated/textured models. We started creating 3D animated models right away before adding concept artists to the team; so the models had to be recreated. But once we had our concepts, we needed to make specific decisions regarding Art Style - the overall game appearance - and this required new models yet again. As a programmer I occasionally overlook these finer details; I mean, if all the characters on screen are moving to their correct destinations... it looks good! But the second lesson I've learned is that Art Style is something that should be seriously considered early on in a game's development.
Performance is also a major consideration for our game. Although we want to have the best-looking game we can build, we also want it to be playable for as many people as possible, so limiting it to the highest-end graphics cards didn't seem right. And given the fact that I was developing the game on a laptop with only 32MB of dedicated video memory at the time, I had a big problem creating a game I wouldn't be able to play! So we took a step back and realized that our 3000-polygon models probably weren't going to cut the mustard. But even with reduced-poly models, we wanted to do some fun stuff in our game like using outlines on our toon-lit models, particle effects, etc. And some of these special effects are expensive operations that quickly drop frame rate and can cause the game to lag. So as our designer likes to say it, the final lesson for today is to "prototype everything." Although he doesn't really mean to prototype everything. What should really be prototyped is all of the core systems of a game that could be rendered/executing together at the busiest point of the game's interaction: music, sound effects, lighting, particle effects, blur effects, and so on. And provide a way to instantly, with the push of a button, drop a hundred or more models on the screen to simulate the game at its most computationally-intensive point to see how it will perform in the worst-case scenario. Doing this type of prototyping early on can help identify where you need to save polygons or cut features that could prevent your intended audience from playing your game.
The cool thing about my team is that we're all learning as we go, and sometimes part of that involves looking back and saying "You know, we could have..." So I hope this helps as you start your next project.
Part of this is due to an unavoidable stall in development progress, which brings me to my first lesson learned. When I realized the ever-increasing scope of the game I would soon be writing, I should have pulled in more developers. As it is, I am currently the only programmer among a group of two 3D artists, two concept artists, and one musician. Although there is a certain amount of pride in being able to take full ownership of the (increasingly large) code base, there is also much to be said for having a fellow to bounce ideas off of and having someone to share the load when you're not available.
Another thing that's bitten us in the development of our game is not understanding core requirements in the beginning. We think we have a great idea for a game and started prototyping the basics right away. For a simple tower defense game, you have enemies moving from one end of the screen to the other, and that's what we created initially as a 2D game. Once we had this basic prototype, we realized that it was pretty darn difficult to make projectiles with faux-depth in a 2D isometric view look right. So we had to make the leap to the third dimension, which involved converting our 2D sprites into 3D rigged/animated/textured models. We started creating 3D animated models right away before adding concept artists to the team; so the models had to be recreated. But once we had our concepts, we needed to make specific decisions regarding Art Style - the overall game appearance - and this required new models yet again. As a programmer I occasionally overlook these finer details; I mean, if all the characters on screen are moving to their correct destinations... it looks good! But the second lesson I've learned is that Art Style is something that should be seriously considered early on in a game's development.
Performance is also a major consideration for our game. Although we want to have the best-looking game we can build, we also want it to be playable for as many people as possible, so limiting it to the highest-end graphics cards didn't seem right. And given the fact that I was developing the game on a laptop with only 32MB of dedicated video memory at the time, I had a big problem creating a game I wouldn't be able to play! So we took a step back and realized that our 3000-polygon models probably weren't going to cut the mustard. But even with reduced-poly models, we wanted to do some fun stuff in our game like using outlines on our toon-lit models, particle effects, etc. And some of these special effects are expensive operations that quickly drop frame rate and can cause the game to lag. So as our designer likes to say it, the final lesson for today is to "prototype everything." Although he doesn't really mean to prototype everything. What should really be prototyped is all of the core systems of a game that could be rendered/executing together at the busiest point of the game's interaction: music, sound effects, lighting, particle effects, blur effects, and so on. And provide a way to instantly, with the push of a button, drop a hundred or more models on the screen to simulate the game at its most computationally-intensive point to see how it will perform in the worst-case scenario. Doing this type of prototyping early on can help identify where you need to save polygons or cut features that could prevent your intended audience from playing your game.
The cool thing about my team is that we're all learning as we go, and sometimes part of that involves looking back and saying "You know, we could have..." So I hope this helps as you start your next project.
Thursday, July 15, 2010
Making Games on the Side
As a hobbyist/indie game developer, I found the following Gamasutra article of particular interest. It describes some of the challenges and sacrifices required to be a successful game developer, whether your definition of "success" is actually breaking in to the industry or simply making games for the love of doing it. Hope you enjoy the article as much as I did.
Making Games On The Side: Development In The Real World
Making Games On The Side: Development In The Real World
Friday, March 19, 2010
Happy (Belated) Birthday, GDJ!
It's hard for me to believe this blog is one year old this week. I started writing last March 14th, not quite sure where the journey would take me, and now it seems a whole year has passed so quickly. One thing is for sure, I have learned a LOT about the game industry through numerous news feeds I now read almost daily and from the extremely bright folks over at the Game Career Guide forums. I've dedicated a large amount of effort to learning how to write games, have gotten involved in my local IGDA chapter, and have met some really cool people in the process.
I created a very basic Pong Clone in 24 hours, worked in a team to create the puzzle game Befuddled at the Global Game Jam in a single weekend, and am currently working with some amazing artists to create an exciting tower defense game. This latest project is one of my biggest and best endeavors yet, so I'm very excited to see the end result within a couple months.
I created a very basic Pong Clone in 24 hours, worked in a team to create the puzzle game Befuddled at the Global Game Jam in a single weekend, and am currently working with some amazing artists to create an exciting tower defense game. This latest project is one of my biggest and best endeavors yet, so I'm very excited to see the end result within a couple months.
Wednesday, December 9, 2009
Game Deployment Woes (Just Make It Flash!)
In one of my previous posts I released a Pong clone game that, albeit not polished, was a fully working game and I was quite proud of it. Of course, as sometimes happens with the deployment of Windows-based games, I was dismayed when I learned nobody who actually took an interest (thanks to you faithful few!) was able to run the game :(
That's when the fun began. I asked one friend to make sure he had the DirectX runtime installed and even to reinstall it - no luck. I then learned the C++ runtime was required and had the same friend perform that install - no luck. I tried two different machines with the same installations - no luck. Finally I learned it was not just requirements on the target systems; it turns out I had included a debug version of a DirectX library in my project, which allowed the program to be created and executed, just not in a way that it would work!
You see, as a developer, I have all of the tools required to run any program I create. But other machines don't necessarily have these tools/environments. So I think I'll use the following plan for deploying my next game.
That's when the fun began. I asked one friend to make sure he had the DirectX runtime installed and even to reinstall it - no luck. I then learned the C++ runtime was required and had the same friend perform that install - no luck. I tried two different machines with the same installations - no luck. Finally I learned it was not just requirements on the target systems; it turns out I had included a debug version of a DirectX library in my project, which allowed the program to be created and executed, just not in a way that it would work!
You see, as a developer, I have all of the tools required to run any program I create. But other machines don't necessarily have these tools/environments. So I think I'll use the following plan for deploying my next game.
Create a game, coding and testing in DEBUG modeChange the project from DEBUG to RELEASE modeReplace DEBUG libraries with RELEASE librariesBuild the project in RELEASE modeCreate an installer project to install the game, the C++ runtime, and the DirectX runtime
- Create a Flash game that can be played from a web page in any browser!
Thursday, July 16, 2009
Quick Random Update
So, Gamasutra is on Twitter too. You may recognize them, or at least you should if you have any business as a video game developer/designer. Gamasutra is one of the most popular game-oriented websites with full-featured articles and commentaries on the state of the industry, game reviews, yadda yadda yadda. So now you can check out not only the website, but also the Twitter feed. Oops, sorry if that last link didn't work; I suppose I should have linked it the proper way: @Gamasutra!
Enough hype, this post is mostly me checking in for a quick progress update. I blasted through reading about lighting, textures, blending, and stenciling in my Direct3D book and then found out the exercises required a fair deal of re-reading. Lesson learned, I have to work through chapter exercises before moving on to more difficult chapters! The same applies to the Game Design Concepts course I'm taking -- it's much easier to keep up with the readings than work through the exercises, some of which I have to skip. FYI, you can follow discussion for the course on Twitter too; just search for #GDCU!
The topic of my next post will be the power of sine waves. Yep, I'm talking about those tricky oscillating waves you learned about way back in high school. I've found some interesting applications and want to show off some of the cool stuff you can do with them. And now that I'm finally understanding the basics of HLSL (High Level Shader Language) shaders, the part that tripped me up big time in the last book I read, you can expect some posts on that stuff too.
Just curious, when was the last time you used something from high school you never thought you would need again? What's the trickiest math you've used in game development, and does calculus ever figure into the equation (pun... fully... intended!)?
Enough hype, this post is mostly me checking in for a quick progress update. I blasted through reading about lighting, textures, blending, and stenciling in my Direct3D book and then found out the exercises required a fair deal of re-reading. Lesson learned, I have to work through chapter exercises before moving on to more difficult chapters! The same applies to the Game Design Concepts course I'm taking -- it's much easier to keep up with the readings than work through the exercises, some of which I have to skip. FYI, you can follow discussion for the course on Twitter too; just search for #GDCU!
The topic of my next post will be the power of sine waves. Yep, I'm talking about those tricky oscillating waves you learned about way back in high school. I've found some interesting applications and want to show off some of the cool stuff you can do with them. And now that I'm finally understanding the basics of HLSL (High Level Shader Language) shaders, the part that tripped me up big time in the last book I read, you can expect some posts on that stuff too.
Just curious, when was the last time you used something from high school you never thought you would need again? What's the trickiest math you've used in game development, and does calculus ever figure into the equation (pun... fully... intended!)?
Tuesday, June 30, 2009
June Monthly Checkup
Yep, another month has come and gone. Sadly I still don't have a finished game, but I do have some cool demos to show off in upcoming posts. I'm up to chapter thirteen (of twenty-two) in Luna's Introduction to 3D Game Programming with DirectX 9.0c: A Shader Approach and am learning a lot, but it takes a while to work through the chapter exercises. I'm also in the process of taking Ian Schreiber's free online game design course. My portfolio website is nearly completed; I just need to find a better host before posting the link here on GDJ.
So it's been yet another busy month of learning and experimenting, all while prepping for our big move to NC in August. After we get settled I plan to join the Triangle IGDA chapter so I can get serious about that whole networking thing.
So it's been yet another busy month of learning and experimenting, all while prepping for our big move to NC in August. After we get settled I plan to join the Triangle IGDA chapter so I can get serious about that whole networking thing.
Monday, June 22, 2009
Game Development Process
I read the article How a Game Gets Made in the free online edition of Game Career Guide magazine some time ago. It's quite a good read for anyone interested in the process, and I believe it's important for me as a programmer to understand what role I will someday fill as a game developer. What follows is a transcription of notes I took while reading to summarize the process; note that not all possible roles are covered and the steps are not listed in sequential order.
- Preproduction
This is the phase where core game design decisions are made, game elements are prototyped, and the game story is developed. A basic prototype of the game is developed quickly and shown to the producer who either scraps the game or gives it the go-ahead to move into production.- Designers document objects, characters, levels, enemies, NPCs, etc. for the game
- Artists work on character designs, level concept art, and storyboarding
- Programmers work on tools, document technical specs, and perform risk assessment
- Producer determines a production schedule and milestones
- Production
This is the phase where the game is fully developed based on preproduction planning and detailed design documents. Some experimentation is allowed as long as it improves the game. The development team follows a "production methodology" to keep track of and divvy up remaining work.- Must determine dependencies early to complete child tasks sooner and keep teams independent (max efficiency)
- Artists get a head start creating/texturing character models and world props (cars, buildings, crates, etc.)
- Animators generate animations for character models
- Programmers work on core functionality and data manipulation
- Level designers create rough sketches of all levels in the game
- System designer plugs in characters and tweaks animations and gameplay
- Sound designers work on effects, getting voice actors for character dialog, and music tracks
- Team meets periodically to review overall progress of the game
- At 2/3 of production timeline additional staff is brought in for QA testing; most features are implemented so it's time to squash bugs
- Postproduction
Postproduction is all about getting the game into the hands of consumers.- Final build of the game (the Gold Master Disc) is printed
- Marketing publicizes the game to popular game websites, magazines, and as TV ads
- Publisher handles game manual and box manufacturing, and has a distributor set up to deliver the game to retail stores
- Developers may be tasked with creating donwloadable content (characters, costumes, levels, etc.) to update and extend the game
Sunday, May 31, 2009
May Monthly Checkup
This has been a busy and difficult month with some unexpected events that nearly derailed my resolve to continue this journey. Nonetheless, I press onward, but with the realization that I may not be able to post as frequently or accomplish goals as quickly as hoped. So this is a pretty informal checkup this month and I've decided not to restate previously completed goals in favor of highlighting tasks that still need work.
The foremost goal in my mind is to complete a full game. I've started reading a new book that I plan to review once I've completed it, and the exercises of chapter five have me working on a 2D space shooter. Following completion of this mini-project I will start work on a PONG clone; the physics of a ball in motion (including collision detection) are quite interesting to me and may require further study.
I have been playing more games lately but don't own a fancy new console yet; picked up three older games for the original XBox (only cost $20 for the set) and want to get a Nintendo Wii at some point. Meanwhile, I have updated my old resume and started a portfolio site that is still a work in progress.
So that's about it for progress updates this month. I think my main takeaway from this month is that it's not how quickly you run the race... just that you eventually finish... and Rome wasn't built in a day. Finally, for some fun reading, check out The Escapist online magazine. They've got some cool game-related articles and a pretty cool RSS feed. Check out my devious guide for help with RSS.
The foremost goal in my mind is to complete a full game. I've started reading a new book that I plan to review once I've completed it, and the exercises of chapter five have me working on a 2D space shooter. Following completion of this mini-project I will start work on a PONG clone; the physics of a ball in motion (including collision detection) are quite interesting to me and may require further study.
I have been playing more games lately but don't own a fancy new console yet; picked up three older games for the original XBox (only cost $20 for the set) and want to get a Nintendo Wii at some point. Meanwhile, I have updated my old resume and started a portfolio site that is still a work in progress.
So that's about it for progress updates this month. I think my main takeaway from this month is that it's not how quickly you run the race... just that you eventually finish... and Rome wasn't built in a day. Finally, for some fun reading, check out The Escapist online magazine. They've got some cool game-related articles and a pretty cool RSS feed. Check out my devious guide for help with RSS.
Thursday, May 14, 2009
Staying Busy
Father forgive me for I have sinned... it's been two weeks since my last post. Wait, two weeks?!? I know, it's terrible and I am ashamed (not terribly, but a little bit). Rest assured, despite my recent silence some good things are happening.
Firstly, I'm reading a new book titled Introduction to 3D Game Programming with DirectX 9.0c: A Shader Approach. As I learned last time, I'm going to avoid posting a book review until I've read it all the way through, but I will say that I'm on chapter six (of twenty-two) and learning some really cool things I plan to highlight in future posts.
Secondly, I've been playing some cool free online games over at Armor Games. One of my personal favorites is Crush the Castle and my wife, who loves hedgehogs, has been hooked on Hedgehog Launch. Check 'em out!
Finally, I've decided to create a clone of the classic Atari game Pong. For those who never played, you can play a version in your browser here using pop-up windows! Pong is a simple game that shouldn't require advanced concepts. I'm hoping to dress it up with some nice textures and add a twist or two.
So there's a few things keeping me busy. Stay tuned for Pong updates!
Firstly, I'm reading a new book titled Introduction to 3D Game Programming with DirectX 9.0c: A Shader Approach. As I learned last time, I'm going to avoid posting a book review until I've read it all the way through, but I will say that I'm on chapter six (of twenty-two) and learning some really cool things I plan to highlight in future posts.
Secondly, I've been playing some cool free online games over at Armor Games. One of my personal favorites is Crush the Castle and my wife, who loves hedgehogs, has been hooked on Hedgehog Launch. Check 'em out!
Finally, I've decided to create a clone of the classic Atari game Pong. For those who never played, you can play a version in your browser here using pop-up windows! Pong is a simple game that shouldn't require advanced concepts. I'm hoping to dress it up with some nice textures and add a twist or two.
So there's a few things keeping me busy. Stay tuned for Pong updates!
Thursday, April 30, 2009
April Monthly Checkup
Has it been another whole month?!? Where does the time go? Here's my current goals checklist on my journey towards becoming a Game Developer.
"If you wanna be rich, you gotta do rich people stuff." - Dave Ramsey
"Wanna be a Game Developer? Do Game Developer stuff!" - Me
See any holes in my plan or have useful tips/pointers to help get me further along? Post a comment!
 |
Create a finished game. I did some good work on my SkyCop demo, finally getting a playable demo posted. I plan to design a smaller-scale (possibly 2D) game at some point but need to work on learning more fundamentals first. |
 |
Use personal projects to test different rendering techniques and programming methods. Check! See the SkyCop reference above. |
|
|
Continue learning and be competent enough to explain design decisions. In addtion to keeping up on the latest feeds for major game sites and participating in a couple forums, I've purchased five new books! Admittedly three of them were recommended for Ian Schreiber's Game Design Concepts course. The one I'm probably most excited to dig into is Game Coding Complete, which I'm hoping will be a good reference for proper structure and best practices. Despite these positive steps, I can't mark this item completed just yet. I am still learning, after all. |
|
|
Start networking! I'm staying active in a couple forums and planning to participate in a local IGDA chapter. The only problem is the local Columbus chapter (which I would still be a couple hours away from) appears to not be meeting at this time, so I may have to wait to participate with the Triangle chapter after we move to NC later this year. Attending the SIEGE conference is still a possibility, or I might consider a visit back up this way to check out the GameX Games and Media Expo. |
|
|
Play more games! I haven't bought a shiny new game to play yet, but I have tried out some independent games on Armor Games. Crush the Castle, where you get to use a trebuchet to destroy castles, is actually a lot of fun! Nonetheless I think I need to get better versed in newer games to mark this item completed. |
|
|
Update the outdated resume. This is a new goal and a worthy one I think will help me focus even better on my target. Darius Kazemi has some great tips on writing a resume for a game company and I plan to update my resume soon. |
"If you wanna be rich, you gotta do rich people stuff." - Dave Ramsey
"Wanna be a Game Developer? Do Game Developer stuff!" - Me
See any holes in my plan or have useful tips/pointers to help get me further along? Post a comment!
Monday, April 20, 2009
That Whole Networking Thing...
So, I'm on Twitter too, and I have mittens to thank for it. I read his GameDev.net post some time ago, have been kicking the idea around and finally signed up. The cool thing to me is that Twitter can be a great resource to see what's going on in the game industry from people who just enjoy working on games. Click the link above for a list of industry professionals you can follow on Twitter!
This brings me to one of my weakest points on my original checklist to becoming a game developer, which is also one of the most important to getting a job in the industry: networking. I've already been fortunate to meet some interesting people like Matt Zitterman and Grant Shonkwiler on the Game Career Guide forums, and I believe this is another step in the right direction to getting connected.
It's not always WHAT you know, but often WHO you know. What are you doing to get connected?
This brings me to one of my weakest points on my original checklist to becoming a game developer, which is also one of the most important to getting a job in the industry: networking. I've already been fortunate to meet some interesting people like Matt Zitterman and Grant Shonkwiler on the Game Career Guide forums, and I believe this is another step in the right direction to getting connected.
It's not always WHAT you know, but often WHO you know. What are you doing to get connected?
Thursday, April 2, 2009
Winding Road Ahead
Tonight I was awakened to the importance of reading a book in its entirety before posting a book review. My thrill of chapters 6-8 on the concepts of Direct3D animation and texturing in Beginning Direct3D Game Programming, 2nd Edition has quickly been eroded by the exponential complexity of chapters 9 and 10 on the High-Level Shader Language (HLSL). I am excited to learn about lighting/shading, environment mapping, bump mapping, reflection, and other techniques described in these chapters. But two frustrating evenings of incomprehensible reading have led me to conclude, as noted by a few other reviews on Amazon as well, that the book is not truly written with the beginner in mind. So I'm taking a new path.
I'm shelving the book... for now. I think it is still a good reference (up until chapter 9 anyway) and may be of use once I gain a better introduction to the concepts described in the later chapters. Until then, there are other resources, such as DirectXTutorial.com and the SDK Documentation itself, that will hopefully provide a more gradual learning curve. Could this be a major turning point in my journey to become a Game Developer? Surely the resources I select to learn Direct3D will affect my growth, but only time will tell...
What resources have you used for learning Direct3D? What worthwhile programming reference/guide would you recommend to someone who has never written a single line of Direct3D code?
I'm shelving the book... for now. I think it is still a good reference (up until chapter 9 anyway) and may be of use once I gain a better introduction to the concepts described in the later chapters. Until then, there are other resources, such as DirectXTutorial.com and the SDK Documentation itself, that will hopefully provide a more gradual learning curve. Could this be a major turning point in my journey to become a Game Developer? Surely the resources I select to learn Direct3D will affect my growth, but only time will tell...
What resources have you used for learning Direct3D? What worthwhile programming reference/guide would you recommend to someone who has never written a single line of Direct3D code?
Monday, March 30, 2009
Monthy Checkup
It's been a whopping two weeks since I started this blog, but it's also the end of the month, which means it's checkup time! At the end of each month, I will review my incomplete goals and determine how I'm progressing toward becoming a Game Developer. You may recall some of the following from my Inspiration post and I've added a few new goals too.
Dave Ramsey, creator of Financial Peace University and an awesome motivational speaker, says "If you wanna be rich, you gotta do rich people stuff." Likewise, if you wanna be a Game Developer, you gotta do Game Developer stuff! I found these testimonies of actual developers/designers working in the field to be quite interesting. They're a good reminder that there's more than one way to break into the games industry, and I know that I can do it!
| Create a finished game. I'm still in the process of learning Direct3D and playing with various techniques. SkyCop is a wide-open testbed for experimentation, but once I feel more confident in my skills I will design a smaller-scale game that I can actually finish. I've read numerous articles stressing the importance of showing potential employers you can create a finished product. |
| Use personal projects to test different rendering techniques and programming methods. Check! See the SkyCop reference above. |
| Continue learning and be competent enough to explain design decisions. I've exponentially ramped up my reading of game development blogs and articles on major sites like GameDev.net and Gamasutra. I want to get another book or two to learn technical/design concepts; I've heard Game Coding Complete is a good reference. |
| Start networking! I've started participating in the Game Career Guide forum; they have a bunch of bright and friendly people willing to help newcomers to the scene, and I'm hoping I will be able to contribute positively to the community. I'm also learning about different game development conferences and considering a trip to GDC next year or possibly attending SIEGE this year. |
| Play more games! I love playing video games, and remember the thrill of playing multiplayer Quake 2 and Unreal Tournament back in the day. It's hard to find the time these days, but in order to understand modern game concepts I really should buy a new game. That's my rationalization, anyway ;) |
Dave Ramsey, creator of Financial Peace University and an awesome motivational speaker, says "If you wanna be rich, you gotta do rich people stuff." Likewise, if you wanna be a Game Developer, you gotta do Game Developer stuff! I found these testimonies of actual developers/designers working in the field to be quite interesting. They're a good reminder that there's more than one way to break into the games industry, and I know that I can do it!
Tuesday, March 17, 2009
Quick Tip: Ready, Fire, Aim!
I ran across this article a few days ago titled Start to Finish: Publishing a Commercial iPhone Game by Niklas Wahrman. Interestingly, Niklas didn't initially develop his Asterope game for the iPhone. It started as a project for a Google Android developer competition and he didn't win, but I like to think he's raking in the big bucks now that it's available in the iTunes Appstore.
I think the most important point he makes is for the independent developer to take a "Ready, Fire, Aim!" approach to development. Simply put, don't over-plan, over-design, or over-engineer. It's easy to get caught up in the design of the game engine, the layout of the world system, and minute details. But getting bogged down in the design phase ("Ready, Aim, Aim, Aim..." as Niklas puts it) can be a major inhibitor to getting the job done.
I've also seen it mentioned in a couple different articles that getting the graphics nailed at the beginning, giving your early prototypes a polished look before working on gameplay mechanics, can be a big motivator to continue working on your game. Food for thought.
I think the most important point he makes is for the independent developer to take a "Ready, Fire, Aim!" approach to development. Simply put, don't over-plan, over-design, or over-engineer. It's easy to get caught up in the design of the game engine, the layout of the world system, and minute details. But getting bogged down in the design phase ("Ready, Aim, Aim, Aim..." as Niklas puts it) can be a major inhibitor to getting the job done.
I've also seen it mentioned in a couple different articles that getting the graphics nailed at the beginning, giving your early prototypes a polished look before working on gameplay mechanics, can be a big motivator to continue working on your game. Food for thought.
Monday, March 16, 2009
OOP & Vertex Buffers
In my previous post, I listed some minor issues I had with the book Beginning Direct3D Game Programming, 2nd Edition. And I have another one: the book does not teach good class-based design. Admittedly it's hard to blame the author though -- he has a lot of material to cover and is trying to illustrate core concepts without bogging us down in extraneous code.
However, realizing that my simple flight simulator needed a CShip class, I dutifully created one to encapsulate the required functions (InitDeviceObjects, RestoreDeviceObjects, InvalidateDeviceObjects, etc.) of the Common Files Framework. I thought it pretty slick that I could simply call m_MyShip->Render() inside my application class' Render method, and I didn't have a problem with my custom ship class having it's own vertex buffer until I read Bubba's post (#9) on this forum. Although I certainly am leery about taking coding advice from a guy named "Bubba", I'm curious about his comment that "The renderer should draw all objects from one vertex buffer."
Understandably, if I have multiple ships with the same geometry it is somewhat wasteful to use multiple vertex buffers (one in each ship instance, used by its Render method). So which way is best?
It may be time for me to invest in a "best practices of game development" book.
However, realizing that my simple flight simulator needed a CShip class, I dutifully created one to encapsulate the required functions (InitDeviceObjects, RestoreDeviceObjects, InvalidateDeviceObjects, etc.) of the Common Files Framework. I thought it pretty slick that I could simply call m_MyShip->Render() inside my application class' Render method, and I didn't have a problem with my custom ship class having it's own vertex buffer until I read Bubba's post (#9) on this forum. Although I certainly am leery about taking coding advice from a guy named "Bubba", I'm curious about his comment that "The renderer should draw all objects from one vertex buffer."
Understandably, if I have multiple ships with the same geometry it is somewhat wasteful to use multiple vertex buffers (one in each ship instance, used by its Render method). So which way is best?
It may be time for me to invest in a "best practices of game development" book.
Sunday, March 15, 2009
Inspiration
GameDev.net recently linked to this Game Career Guide interview with Jean-Francois Lévesque, describing his path toward becoming a Game Developer at Ubisoft Montreal in Canada. This post is one of a few leading to my recent fervor to work harder to break into the field. As I read the interview, I kept saying to myself "check, check, got that... I can totally DO THIS!!!"
I'd like to summarize what I believe were his most important insights and define where I am with each:
I'd like to summarize what I believe were his most important insights and define where I am with each:
- Learn the English language. -> Check!
- Have a plan. Read as much as you can on game development and work on your own games/projects in your spare time. -> Check!
- Have at least one complete personal project to show to potential employers. -> I'm still working on this one.
- Use personal projects to test different rendering techniques and programming methods. Continue learning and be competent enough to explain design decisions. -> I'm working on this one too.
- Expect rejection in the beginning. It may take a couple times, more college courses, or simply meeting the right people to succeed. -> This might be tough!
- Be willing to step up and ask for more challenges/responsibilities once you do get hired. -> This is me!
- If you start getting in over your head once you land the job, seek help and learn from your co-workers. -> No problem.
- Be prepared for a personal component AND technical test at your interview. Be passionate about what you do! -> I plan to keep learning as much as I can to improve my technical competency, but I know I can easily show my desire to work on games!
- Have a personal website so employers can learn more about you. -> Check!
- Start networking! Attend job fairs and gaming conferences, participate in video game-related forums, and do everything you can to make new contacts in the field. -> I need to work on this one.
Subscribe to:
Posts (Atom)