Game Hours: 409.25(previous two years) + 119 (current year) = 528.25 / 1000 Game Ideas: 710 (previous two years) + 63 (current year) = 773 / 1000
Ugh, I’m still in crunch at the day job, and it looks like I’ll be crunching for some time.
Still, I managed to update the main title of Walls so that it no longer calls itself Minimalist, and I added a copyright notice to this screen as well.
[tags]game, game design, productivity, personal development, video game development, indie[/tags]
Anthony Salter has become disheartened when he sees what some game developers are able to create in 10 days for the TIGSource Demake Competition. When you see HouseGlobe, the demake of the award-winning space RTS Homeworld, in action, you’ll be in awe. 10 days?!
If you read the comments, though, you’ll see the secret.
We made House Globe in 10 days, yes, but this is what we had before we started:
– A DirectX/OpenGL engine with Lua scripting and sound/music support
– TCP/IP hand-shaking between instances of the said engine
– Tools for creating/loading textures to the game
…
What I mean is, like the previous posters said, if you have the tools you can really pick up pace. So please consider that it took us 4 years to make all these tools.
Most of the work over the 10 days was just creating art and sound and play-testing. The tech was already there, and the game was written on top of that tech fairly easily. Contrast the work of Oxeye Game Studio with how my Ludum Dare entries went (see my post-mortems for LD#11 and LD#12), and you’ll spot the difference right away. I’m still learning how to manipulate technology to do things that resemble a game, and OGS has already done that work over the last few years!
I think this example ties into the idea of the overnight success taking years of hard work, and it shows that I definitely need to stop letting things get in the way of my part-time game development if I hope to ever make other people look at my work and drop their jaws the way I did when I saw HouseGlobe.
[tags] demake, indie, game development, business [/tags]
Game Hours: 409.25(previous two years) + 118.5 (current year) = 527.75 / 1000 Game Ideas: 710 (previous two years) + 63 (current year) = 773 / 1000
I’m still in crunch at the Day Job, and so there is very little time left in my week to do much else. Still, I managed to work on Walls a little bit, although I would like to implement more than one feature or bug fix a week.
[tags]game, game design, productivity, personal development, video game development, indie[/tags]
Jay Barnson wrote Business Rules for Indies, in which he tries to apply Jack Welch’s “cardinal rule of business” to indie game developers.
Never let anyone come between you and your customers or your suppliers. Those relationships take too long to develop and are too valuable to lose.
While game portals are a good short term solution for developers who are trying to reach a large number of players and paying customers, they aren’t so good for the long term.
In business, finding a new customer willing to pay for your products is much harder and much more expensive than selling your products to existing customers, who have already shown a willingness to buy from you. But if you sell through a portal, you don’t have a customer. You get paid, but by the portal, as a cut of the sales. If you were to sell directly to your customers, however, you not only get the sale, but also a relationship with your customer.
If you sell a game through a portal for $20, you get paid a small percentage. The portal gets the lion’s share, but of course the portal is the one with all of the traffic and customers, and so you are essentially paying for the chance to sell greater quantities than you could on your own.
If you sell a game directly for $20, you get to keep the income. You might not get as many sales on your own, but what you do get in this situation is customer information. YOU know who is willing to buy the kind of games you make, and so YOU can sell them expansions, sequels, and affiliate products. You can address them in newsletters and tell them about new sales you’re offering. That $20 is just the start of how much that customer might buy from you over the lifetime of your business. You trade short-term financial gain for future profits.
The theory sounds all well and good, but with so much competition out there, how can you hope to get ANY attention unless you’re on a portal? And if you’re on a portal, you aren’t allowed access to customer information, and in some cases you aren’t even allowed to let your customers know who made your game! The portals have become the new form of publishers, which is what being indie was supposed to get you away from.
Dan Cook’s The Casual Games Manifesto addresses all of this and more, but the essence of the article is that you need to develop a relationship with your customers, whether they found you directly or through a portal. Can you integrate your games into a service that YOU and YOU alone provide? Then the portal becomes your access point to customers and not just a distribution channel.
The Casual Games Manifesto got me thinking about specific changes I can make to my business model. If I make one game, and it takes me three months or three years, I have to compete with all of the hundreds of games released in that time. But if I create a game tied to a service I provide, am I competing with the same games anymore? I think what might make such a change hard for indies is that providing a game service requires outsourcing or hiring others to build and manage it. Then again, are you doing this as a hobby that pays a little bit for your pizza and beer, or are you running a serious business?
Either way, don’t feel that you need to let the portals come between you and your customers. If you don’t want them to, you have options.
[tags] indie, business, portal, game development [/tags]
I haven’t heard too much about Google’s browser project, Google Chrome, but I recently learned about this comic by Scott McCloud that describes the work being done. Pretty sweet. Combine Google’s goals with the goals of Mozilla Ubiquity, and the web will be a very foreign yet familiar place.
What does it mean for indie game developers? General stability improvements across all web browsers, richer application development, and a feeling of safety by users should all lead to more people feeling comfortable playing any kind of game they want.
My favorite thing to imagine is that game developers will stop making games for Windows exclusive and start making games for everyone. It’s currently too difficult to make web-based apps behave consistently because every browser implements Javascript and renderers differently. It’s why you still occasionally find bank websites that require you to use Internet Explorer even though they aren’t doing anything more complicated than YouTube, which works on any browser so long as you have a working Flash plugin. With Google’s work on Chrome, it looks like any browser can take advantage of the same APIs and libraries, which means a more consistent experience for all users.
But what about the games? I know id is already porting Quake 3 Arena to the web, and Runescape already shows that you can have a very successful web-based MMORPG, but what about real-time strategy games? Action games? Sports games? Heck, what about entirely new genres that take advantage of the new open standards being developed by Google and others? Intel’s research on portable gaming on a big screen might also have applications if we can start using our phone’s browser to play games in front of the MythTV box and TV, giving proprietary consoles more competition.
The future of web games is definitely going to look and feel different, and whoever shows us what it can be stands to gain a lot.
[tags] google chrome, browser, web game, indie [/tags]
Game Hours: 409.25(previous two years) + 117.5 (current year) = 526.75 / 1000 Game Ideas: 710 (previous two years) + 36 (current year) = 746 / 1000
I spent part of my week making the goal look obviously different from the obstacles in the game. If you’re wondering why I bothered, you should read Game Design for the Color Blind Player.
I spent the other part of my week in crunch at the day job or resting from it.
[tags]game, game design, productivity, personal development, video game development, indie[/tags]
Overall, my game placed very low. Still, I managed to come away with the gold medal for my journal and the bronze medal for my food entries. My timelapse video came in 4th place. I rule at participation.
I intend to rule LD#13 in December, though. I’m going to spend the next couple of months getting ready for it.
Game Hours: 409.25(previous two years) + 116 (current year) = 525.25 / 1000 Game Ideas: 710 (previous two years) + 36 (current year) = 746 / 1000
I had every intention of working at least an hour each day to guarantee that I’ll have at least five hours by Saturday. Instead, crunch hit at the day job, and badly. I was working on Saturday and Sunday for the first time in…months? That’s sad.
I made a little progress, so that’s good, but eating, sleeping, and working at the day job is taking up most of my time, and I’d rather not take away from the only things keeping me healthy.
[tags]game, game design, productivity, personal development, video game development, indie[/tags]
My 2nd Ludum Dare didn’t go as well as my first. While I managed to get Tower Defender submitted, it can’t be called a game so much as a tech demo.
What Went Right:
Simple game mechanics still work.
Like my LD#11 Minimalist entry, I wanted to use simple mouse-movement-only controls. I feel that mousing over your units to make them attack made sense, and while I only had archers available in the end, it seemed to work. It’s too bad there wasn’t more of a game built around the mechanic, but I intend to flesh it out after LD.
I had an office door I could close.
My cats are incredibly reliable. If I am doing anything that looks like productivity, they will insist on sitting on my lap, resting on my arms, and otherwise preventing me from working. Being able to close the door on them helped keep me focused on game development. Towards the end I got lax about keeping the door closed, but the cats left me to work for the most part.
Using Test-Driven Development
Test-Driven Development, or TDD, is great for designing your code. Also, since code changes often, you can feel confident that your changes won’t break functionality since your tests will tell you if they did break. More than once, I was surprised that a seemingly innocuous change resulted in failing tests, so I was able to keep the game working at all times. I know that I wouldn’t have caught one specific crash problem right away, and it might have resulted in a non-working game for hours, preventing me from submitting anything. Since I found those problems sooner, even in code that wasn’t directly being tested, I felt that using TDD was the right thing to do.
What Went Wrong:
Learning Test-Driven Development while using it.
I know quite a few people would disagree with the use of TDD during Ludum Dare, but I think what burned me was my inexperience with implementing it. I spent too much time trying to figure out how to apply it to rewriting code that I already had written. My first bunch of tests were helpful, but all I ended up with at the end was a slightly smaller Game class with a separate Timer class, and it seemed that if I applied TDD to the entire project I would barely have an SDL window by the end. While my normal projects might benefit from test-driven design, my LD game needed to get finished in 48 hours, so I had to alternate between writing tests first and skipping tests. I’m sure once I get some TDD experience, I’ll be much faster and know when it is in appropriate to write tests. For LD#12, it was a learning experience.
I still didn’t have a good handle on SDL
Last LD, I noted that I hadn’t practiced using SDL much, and right before LD#12 started, I realized that I still hadn’t done so. I never had to render animated sprites in SDL before, and I skipped it in favor of static images moving around, but not before spending precious time learning what I would need to do it. Again, there was too much wrestling with technology instead of game development, and this time it prevented me from finishing my game.
Working long hours really does screw with your productivity
It’s common in the programming world to find people working Twelves, especially in the game development industry. Crunch times are intuitive. If a project needs to get done in a week, and there are two weeks of work to be done, then have everyone work longer each day. Well, it is common knowledge, even if that knowledge isn’t applied, that working longer hours doesn’t translate into greater productivity.
I experienced these issues firsthand with the 2nd day of LD#12. I realized I had worked about 12 hours straight by the end, and I was making sillier and sillier mistakes. Sometimes my tests would save me, but since I didn’t write tests for a good portion of my code, I had to figure out what I did wrong most of the time. Bugs were finding their ways into my code a lot easier, and debugging was painful. When I did LD#11, I got plenty of sleep and took frequent breaks, and ended up with a finished game. I wonder if I could have done LD#12 better if I took a few more decent breaks during that 12 hour stretch.
I didn’t get game play until the very last minute.
I knew that getting game play up as quickly as possible was important, especially in a timed competition, and yet I believe I struggled so much with the technology that the game didn’t start to form until I had minutes left to package it up and submit it. I think if I had used a few more hours in a productive way, I could have made something enjoyable.
What I Learned:
I still have a lot to learn.
It’s weird when you feel confident going into a competition like this and then hit a wall due to your own lack of knowledge. I was depending on TDD, SDL, and common game programming concepts such as OnMouseOver, but I didn’t have much experience with them before this competition started. I like using LD as a learning experience, but next time I’ll focus on learning only one tech or tool for LD at a time.
Test-Driven game development is awesome.
Yes, the learning curve slowed my productivity down, but I already saw many benefits from using a test-first design for my coding. I could see that my code base was going to be much better for it, particularly in terms of my ability to make cross-platform games, but I had to stop applying it due to time constraints. I was already trying to incorporate TDD into my main development before LD, but now I see that it’s going to provide better benefits than I originally thought.
I need to work on my pacing for LD.
It seems most of my productive work happens during the 2nd half of Ludum Dare, and it makes me wonder what happened during the first 24 hours. I saw that more than a few people had working prototypes up and running within a matter of hours, and I want to make sure my future LD entries are in a playable state as early as possible, too.
Once again, 48 hours resulted in a bunch of code and experience I didn’t have before the weekend started. Even though my submission can’t really be called a game, it has potential, and I had a lot of fun working on it. The next LD is in December. A few months should give me time to develop my skill and technology base.
I was rereading Programming Linux Games the other day. I love rereading books because there will always be something that you didn’t notice the first few times through. This time, I learned two ways to render sprites much more efficiently than I was currently doing. I had heard about these two techniques, especially from my first readings, but I forgot about them.
Understanding colorkeys
In Chapter 4, Mastering SDL, John Hall talked about setting colorkeys to simulate transparency when drawing sprites. If you’ve ever seen the image files in many games and tutorials, you’ll notice that they aren’t transparent images. See Aaron Cox’s sprite tutorial for an example. Usually the sprite being rendered will be surrounded by a certain color, sometimes hot pink, but no matter what, there is a color instead of complete transparency. The reason why the sprites render as if they are transparent is because that color is set as the colorkey, and SDL knows not to render it.
Why not just use alpha values in an image? You get the same effect, right? While the end result might look the same, the amount of processing power you need is not the same. To render alpha values properly, there are calculations needed for each pixel. The surrounding pixels are taken into account, and the final value is determined before the color is set. With colorkeys, the pixel is either rendered or not rendered.
If you have a game in which it is possible for many sprites to overlap, calculating alpha blending for otherwise blank areas of multiple sprites will slow down rendering time. Maybe faster computers won’t even blink, but you might be increasing your game’s minimum hardware requirements needlessly.
Understanding Display Format
SDL allows you to load images from a file into an SDL_Surface. To render them to your screen, which is also a surface, you simply blit them together using SDL_BlitSurface(). Hall also warns that doing so with slightly incompatible surfaces can slow down rendering. If your sprite is in one format, and your screen is in another, SDL must convert the sprite to the screen’s format before rendering. It does this transparently so you don’t need to specify anything, but do you really need to do these calculations every time it renders?
No. SDL_DisplayFormat() will take a surface and return a surface that is in a format that is optimal for fast blitting to your screen.
Here’s what threw me off. My code was organized like so:
if (!isSDLVersionUpToDate() ||
!initializeSDL() ||
!initializeWindow()) ||
{
My code first checks to make sure you have an up-to-date SDL version on your system. Assuming that’s cool, it initializes SDL using SDL_Init() and gets my program ready. Then it creates the window and sets up my main screen surface for rendering.
All fine and good, except my sprites were getting loaded in initializeSDL(). (NOTE: Yes, this is bad. The name of the function didn’t indicate that it was also loading sprites. I was the one who wrote this code, and I was the one getting burned by it). When I tried to change my sprite loading code, SDL_DisplayFormat() kept returning NULL, which indicates failure. Why was it failing, though?
After asking on IRC and doing research online, I found out why. SDL_DisplayFormat() converts your surface into an optimal format for fast blitting to the screen. Well, until you create a screen, how does it know what that format should be? In my code, SDL_SetVideoMode() gets called in initializeWindow(), which was after the sprites got loaded, so of course SDL_DisplayFormat() would fail. It didn’t know what the optimal format would be because we hadn’t created the format target! Well, that’s an easy fix. I just moved the sprite loading code to its own function, which I called AFTER initializeWindow(). Now SDL_DisplayFormat() returns a valid surface.
Of course, I hadn’t set the colorkey yet, and I wasn’t ready to make the changes to the graphics as it was getting late, so to make sure my game otherwise looked the same, I changed all calls to SDL_DisplayFormat() to SDL_DisplayFormatAlpha(). Now it converts the surface to allow for faster blitting, and it handles alpha transparency correctly. It isn’t the most efficient, but it is definitely an improvement over what I had before. I still intend to convert my transparent images to opaque ones that get rendered properly using colorkeys since there is still a performance gain there.
Hopefully, my efforts helped someone out there, if only by allowing them to play games without needing to spend the money on upgrading hardware.
, in action, you’ll be in awe. 10 days?!
the other day. I love rereading books because there will always be something that you didn’t notice the first few times through. This time, I learned two ways to render sprites much more efficiently than I was currently doing. I had heard about these two techniques, especially from my first readings, but I forgot about them. 