Working with others is hard. But being able to work remotely and have all your files merged together nicely is really cool. I'm talking about source-control/versioning software, a tool that lets you maintain history of the changes to your files, as well as allowing everyone on the team to merge their changes to the project seamlessly. There are a couple different versioning tools out there, but the one I'm most familiar with and enjoy using is Subversion.
Since my team has decided we might consider selling our Tower Defense game at some point, we finally decided to remove its open source label and get smarter about how we secure our project. So I decided to set up my laptop as a Subversion (SVN) server; I know I should really use a spare server but I don't have one lying around. So I installed SVN server, got the repository and permissions set up, configured my router to forward the SVN port to a static internal IP address, and... VOILA! I had a working SVN repository accessible via the internet.
Unfortunately my upload speed, which measured .96Mbps on speedtest.net, was providing an abysmal 120kBps download rate for my team members trying to update their working copy of the project -- and let's not even mention the 2+ hours spent on the initial checkout! By comparison, downloads from our open source provider were roughly 1500kBps. I was a little perplexed as to WHY my 1 meg-per-second upload rate was so slow until I saw this forum post, specifically the comment by JC316. Megabits are eight times smaller than Megabytes, and when I did the math I realized that 120kBps (120,000 * 8 = 960,000 bits) is the same as .96Mbps (.96 * 1,000,000).
The reality is that my upload speed is just too slow. We don't have an office to work out of yet and I don't want to shell out $100+ per month for internet service just for a better upload rate. We're considering other closed-source SVN hosting services for now, but I have to wonder...
As an indie startup with team members working remotely over the internet, how do YOU collaborate?
Wednesday, July 6, 2011
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.
Sunday, July 18, 2010
Concept Art
As mentioned previously, I've been working on a fairly complex tower defense game for about eight months now with some very talented 3D and concept artists. Although I'm not at liberty to disclose full details of our upcoming game, for which we've set a demo deadline of September 2010, I can show off some concept art. As a programmer, I'm learning the importance of having quality, researched concepts from which our 3D artists can generate models that are animated in the game. Below are a couple defense units and a couple enemies to show a small piece of what we're working on.
Defense: Light Infantry
The light infantry in our game is the player's first line of defense against attacking enemies. He wields a javelin and is a bit clumsy at first but improves his skill (e.g. throwing more than one javelin at once) when upgraded using cash earned from killing enemies.
Defense: Heavy Infantry
The heavy infantry does more damage than light infantry and attacks rapidly in a wild rage when upgraded. A couple possible renderings are shown.
Enemy: Cyclops
The Cyclops is one of the boss enemies in the game.
Enemy: Minotaur
The Minotaur is another boss enemy in the game.
So those are just a sneak preview of some of the artwork going into our tower defense game. Note that this work is copyrighted by Insert Coin Interactive and may not be copied or reproduced in any way. I look forward to showing more work and hopefully also some in-game screenshots when we're closer to demo completion!
Defense: Light Infantry
The light infantry in our game is the player's first line of defense against attacking enemies. He wields a javelin and is a bit clumsy at first but improves his skill (e.g. throwing more than one javelin at once) when upgraded using cash earned from killing enemies.
Defense: Heavy Infantry
The heavy infantry does more damage than light infantry and attacks rapidly in a wild rage when upgraded. A couple possible renderings are shown.
Enemy: Cyclops
The Cyclops is one of the boss enemies in the game.
Enemy: Minotaur
The Minotaur is another boss enemy in the game.
So those are just a sneak preview of some of the artwork going into our tower defense game. Note that this work is copyrighted by Insert Coin Interactive and may not be copied or reproduced in any way. I look forward to showing more work and hopefully also some in-game screenshots when we're closer to demo completion!
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
Thursday, July 1, 2010
Exciting Announcements!
I can hardly believe it's been two months since my last post. Where does the time go?!? I haven't been posting lately but have a feeling that will change soon. And I have a lot of exciting announcements I couldn't wait to share!
First, and I know I promised not to use this blog as a personal forum, but I simply must share that my wife and I are expecting our first child! She is actually due to arrive today, so please cross your fingers, wish us luck, and if you are inclined to do so, pray for us and our baby girl. If you're interested in more updates please feel free to add me as a friend on Facebook.
Second, I just discovered today on the IGDA NC forum that EA is hiring software engineers for full-time and contract positions. The NC branch of EA is located in Morrisville, so if you're a game developer living anywhere near the Triangle click the link above and submit your resume.
Third, I learned recently that Ian Schreiber is doing another summer online course, this time focusing on Game Balance. If you enjoyed his Game Design Concepts course you will most likely be interested in checking out Game Balance Concepts.
Fourth, check out Darius Kazemi's GameLoop unconference. It looks like an awesome time to learn about all things game-related, so you should totally check it out if you live anywhere near Cambridge, MA.
Finally, I've been working on a tower defense game that I alluded to way back in January and I'm happy to say my team and I are making outstanding progress. But a number of things have changed. Instead of it being a 2D game, we're now doing 3D (and understand why 2D isometric tower defense is near-impossible). We've also switched our platform from XBox 360 to the PC, and are making some dramatic changes to our original art style. It's amazing to see what our graphic artists can do, and I plan to post some screenshots soon. Tentative plan is to have something we can demo at an upcoming conference in September.
So there's a lot going on, which hopefully explains the fewer posts, but I have been learning a ton of cool stuff that should make for some interesting tutorials right here on GDJ. Until next time...
First, and I know I promised not to use this blog as a personal forum, but I simply must share that my wife and I are expecting our first child! She is actually due to arrive today, so please cross your fingers, wish us luck, and if you are inclined to do so, pray for us and our baby girl. If you're interested in more updates please feel free to add me as a friend on Facebook.
Second, I just discovered today on the IGDA NC forum that EA is hiring software engineers for full-time and contract positions. The NC branch of EA is located in Morrisville, so if you're a game developer living anywhere near the Triangle click the link above and submit your resume.
Third, I learned recently that Ian Schreiber is doing another summer online course, this time focusing on Game Balance. If you enjoyed his Game Design Concepts course you will most likely be interested in checking out Game Balance Concepts.
Fourth, check out Darius Kazemi's GameLoop unconference. It looks like an awesome time to learn about all things game-related, so you should totally check it out if you live anywhere near Cambridge, MA.
Finally, I've been working on a tower defense game that I alluded to way back in January and I'm happy to say my team and I are making outstanding progress. But a number of things have changed. Instead of it being a 2D game, we're now doing 3D (and understand why 2D isometric tower defense is near-impossible). We've also switched our platform from XBox 360 to the PC, and are making some dramatic changes to our original art style. It's amazing to see what our graphic artists can do, and I plan to post some screenshots soon. Tentative plan is to have something we can demo at an upcoming conference in September.
So there's a lot going on, which hopefully explains the fewer posts, but I have been learning a ton of cool stuff that should make for some interesting tutorials right here on GDJ. Until next time...
Saturday, May 1, 2010
IGDA Takes a Stand on Censorship
I just read an awesome post on GameDev.net titled
IGDA Condemns Video Game Censorship and think it's awesome to see the IGDA taking a stand on censorship like this. I totally agree it is the responsibility of parents, NOT the government, to determine what children should and should not play.
So yeah, check out the post on GameDev.net, cuz it's awesome.
So yeah, check out the post on GameDev.net, cuz it's awesome.
Subscribe to:
Posts (Atom)
Posts
