After a nice long hiatus for my successful NaNoWriMo, I'm getting back into the game (ha ha)!
During all of the NaNoWriMo hubbub, one interesting piece of news that I had forgotten was that the Google AI challenge (www.ai-contest.com) was going on, ending November 27th. Unfortunately, I only remembered this on November 25th. I downloaded the C++ starter pack and tinkered around, submitting a pretty simple modification to the default bot that did an admirable job against the example bots included in the package.
Then I got to work on my own. I had some grand plans for my AI. First I was going to loop through the planets and calculate the available ships. For each planet I started with the current number of ships, then I looped through the enemy fleets to see if any targeted the planet. Then I calculated how many ships I would have by the time it reached me, subtracting the number of enemy ships. I kept a running total in case more than one fleet was enroute.
Unfortunately, I was behind on my word count and that was all I completed. I was then going to see if I could save the planets that I would otherwise lose. If I still had ships left, I would go for some neutral or enemy planets, starting with the largest that had the fewest ships (I already had a basic heuristic for calculating the best targets, which I would have tweaked).
Oh, well, there were some really cool entries, so I'm not sure how I would have done. Watch this funny battle in which neither side even attacks the other:
http://ai-contest.com/visualizer.php?game_id=9559045
It looks silly from our point of view, but you can tell what the bots are doing: they are protecting those two large planets from the other one. If either side went to grab another planet, they would have lost the big ones. The loser of that battle actually won the contest.
I had a great deal of fun tinkering with the bot and watching it compete, and I was sad that I didn't get to finish my own bot from scratch. However, I just checked out the latest Full Circle Magazine (for Ubuntu) and there is another AI contest going on right now! I haven't had the opportunity to tinker yet, but I did download the example and I hope to give it a shot!
Friday, December 3, 2010
Friday, September 17, 2010
NaNoWriMo time is upon us!
Of course this is only tangentially related to game development, but one thing you'll find as my blog matures is that I love a game with a good story. However, good storytelling in games is a different beast than good storytelling in books. For one thing, only perfectly linear games have stories that translate reasonable well to books. For another, you don't get to simply act out the battle scenes in books.
Anyway, to get to the point, November is National Novel Writing Month, or NaNoWriMo for short. You might think to yourself, why would anyone want to write a novel in a month? Well, ask the more than 100,000 people that participate every year. I suspect that a large number of game developers -- especially those interested in story-heavy genres -- have thought about it at one point in their lives. Just like the time-limited game development competitions, NaNoWriMo challenges you to get those creative juices flowing. Put your fingers to the keyboard and don't lift them up until you've reached your goal.
That goal is 50,000 words. In 30 days. That's 1,667 words per day every day of the month. A daunting goal to be sure, but over 20,000 people manage it. Sometimes they are established authors, but mostly they are just normal people like yourselves. Whether you start with a detailed outline or a blank file, there is fun to be had.
The perpetrator of this month of debauchery, Chris Baty, provides this guide to success:
No Plot? No Problem!: A Low-Stress, High-Velocity Guide to Writing a Novel in 30 Days
Anyway, to get to the point, November is National Novel Writing Month, or NaNoWriMo for short. You might think to yourself, why would anyone want to write a novel in a month? Well, ask the more than 100,000 people that participate every year. I suspect that a large number of game developers -- especially those interested in story-heavy genres -- have thought about it at one point in their lives. Just like the time-limited game development competitions, NaNoWriMo challenges you to get those creative juices flowing. Put your fingers to the keyboard and don't lift them up until you've reached your goal.
That goal is 50,000 words. In 30 days. That's 1,667 words per day every day of the month. A daunting goal to be sure, but over 20,000 people manage it. Sometimes they are established authors, but mostly they are just normal people like yourselves. Whether you start with a detailed outline or a blank file, there is fun to be had.
The perpetrator of this month of debauchery, Chris Baty, provides this guide to success:
No Plot? No Problem!: A Low-Stress, High-Velocity Guide to Writing a Novel in 30 Days
Friday, September 3, 2010
Vimrc Time!
Uh oh, only four posts in and my allegiances come out!
Since Vim 7.3 came out a couple weeks ago, it's about time for a celebration in the form of a vim post! Over the past couple years I have become a vim user. Although I had wanted to use either vim or emacs for some time, I had a lot of trouble getting into it. Where I work, we had Red Hat Enterprise Linux 3 machines when I first started. A lot of people used NEdit, a few (including my boss) used gvim, and a few used emacs. NEdit was intuitive and had syntax highlighting, so it was good enough for me at first.
Then we upgraded to RHEL5.
Oh NEdit was still there, but it had the really odd but entirely repeatable bug that caused the text on the screen to "get stuck" when scrolling. It was annoying enough that I wanted to switch editors immediately. Many NEdit users switched to Kate, which by all accounts is a fine upgrade from NEdit. But if I was going to make the switch, there was hardly a better time. I grabbed my boss' vimrc and jumped in head first.
It was slow going at first -- I still wanted to use the arrow keys for a while, and even now, two years later, I still find myself using the mouse and the Escape button on occasion when I don't need to do so. But even two years later I'm still learning things that boost my productivity. For example, only last week I started making use of macros, which I knew about for a while but never saw reason to use them.
Anyway, there's an important rite of passage for the vim user: putting together his very own .vimrc. It wasn't long before I had become curious about the options available, and browsing examples around the internet. Unfortunately I couldn't tell you the source of many of these settings, and a quick search shows many of them appear in many different examples. But whether you're already a vim user or you're just looking to get started, hopefully my short but sweet .vimrc shows you something useful.
Bonus: gvim can convert code into HTML, so I don't need to mess with raw HTML or tools like syntaxhighlighter to get (I hope) pretty code samples! This also has the benefit of showing off the awesome color scheme I use: wombat!
1 " set color scheme
2 colors wombat
3
4 " always have syntax highlighting
5 syntax on
6
7 " always number lines
8 set number
9
10 " don't wrap long lines
11 set nowrap
12
13 " change tabs into 4 spaces
14 set shiftwidth=4
15 set expandtab
16 set shiftround
17
18 " autoindent new lines
19 set smartindent
20
21 " be quiet
22 set noerrorbells
23
24 " show matching braces
25 set showmatch
26
27 " highlight located search terms
28 set hlsearch
29
30 " normally don't automatically format 'text' (code) as it is
31 " typed, IE only do this with comments, at 79 characters:
32 set formatoptions-=t
33 set textwidth=79
34
35 " get rid of the default style of C comments, and define a
36 " style with two stars at the start of `middle' rows which
37 " (looks nicer and) avoids asterisks used for bullet lists
38 " being treated like C comments; then define a bullet list
39 " style for single stars (like already is for hyphens):
40 set comments-=s1:/*,mb:*,ex:*/
41 set comments+=s:/*,mb:**,ex:*/
42 set comments+=fb:*
43
44 " enable filetype detection:
45 filetype on
46
47 " let gvim know all of those *.cc* files are C++ files
48 au BufNewFile,BufRead *.cc* :set ft=cpp
49
50 " let gvim know all of those *.m* files are Matlab files
51 au BufNewFile,BufRead *.m* :set ft=matlab
52
53 " for C-like programming, have better automatic indentation
54 " and if starting a newline in the middle of a comment
55 " automatically insert the comment leader characters:
56 autocmd FileType c,cpp set cindent formatoptions+=ro
57
58 " in makefiles, don't expand tabs to spaces, since actual
59 " tab characters are needed, and have indentation at 8
60 " chars to be sure that all indents are tabs:
61 autocmd FileType make set noexpandtab shiftwidth=8
I believe it's well commented so nothing should need explanation. But if you do, or if you're proud of yours, feel free to comment. For more info, here is a highly rated book about vim:
Learning the vi and Vim Editors
Since Vim 7.3 came out a couple weeks ago, it's about time for a celebration in the form of a vim post! Over the past couple years I have become a vim user. Although I had wanted to use either vim or emacs for some time, I had a lot of trouble getting into it. Where I work, we had Red Hat Enterprise Linux 3 machines when I first started. A lot of people used NEdit, a few (including my boss) used gvim, and a few used emacs. NEdit was intuitive and had syntax highlighting, so it was good enough for me at first.
Then we upgraded to RHEL5.
Oh NEdit was still there, but it had the really odd but entirely repeatable bug that caused the text on the screen to "get stuck" when scrolling. It was annoying enough that I wanted to switch editors immediately. Many NEdit users switched to Kate, which by all accounts is a fine upgrade from NEdit. But if I was going to make the switch, there was hardly a better time. I grabbed my boss' vimrc and jumped in head first.
It was slow going at first -- I still wanted to use the arrow keys for a while, and even now, two years later, I still find myself using the mouse and the Escape button on occasion when I don't need to do so. But even two years later I'm still learning things that boost my productivity. For example, only last week I started making use of macros, which I knew about for a while but never saw reason to use them.
Anyway, there's an important rite of passage for the vim user: putting together his very own .vimrc. It wasn't long before I had become curious about the options available, and browsing examples around the internet. Unfortunately I couldn't tell you the source of many of these settings, and a quick search shows many of them appear in many different examples. But whether you're already a vim user or you're just looking to get started, hopefully my short but sweet .vimrc shows you something useful.
Bonus: gvim can convert code into HTML, so I don't need to mess with raw HTML or tools like syntaxhighlighter to get (I hope) pretty code samples! This also has the benefit of showing off the awesome color scheme I use: wombat!
1 " set color scheme
2 colors wombat
3
4 " always have syntax highlighting
5 syntax on
6
7 " always number lines
8 set number
9
10 " don't wrap long lines
11 set nowrap
12
13 " change tabs into 4 spaces
14 set shiftwidth=4
15 set expandtab
16 set shiftround
17
18 " autoindent new lines
19 set smartindent
20
21 " be quiet
22 set noerrorbells
23
24 " show matching braces
25 set showmatch
26
27 " highlight located search terms
28 set hlsearch
29
30 " normally don't automatically format 'text' (code) as it is
31 " typed, IE only do this with comments, at 79 characters:
32 set formatoptions-=t
33 set textwidth=79
34
35 " get rid of the default style of C comments, and define a
36 " style with two stars at the start of `middle' rows which
37 " (looks nicer and) avoids asterisks used for bullet lists
38 " being treated like C comments; then define a bullet list
39 " style for single stars (like already is for hyphens):
40 set comments-=s1:/*,mb:*,ex:*/
41 set comments+=s:/*,mb:**,ex:*/
42 set comments+=fb:*
43
44 " enable filetype detection:
45 filetype on
46
47 " let gvim know all of those *.cc* files are C++ files
48 au BufNewFile,BufRead *.cc* :set ft=cpp
49
50 " let gvim know all of those *.m* files are Matlab files
51 au BufNewFile,BufRead *.m* :set ft=matlab
52
53 " for C-like programming, have better automatic indentation
54 " and if starting a newline in the middle of a comment
55 " automatically insert the comment leader characters:
56 autocmd FileType c,cpp set cindent formatoptions+=ro
57
58 " in makefiles, don't expand tabs to spaces, since actual
59 " tab characters are needed, and have indentation at 8
60 " chars to be sure that all indents are tabs:
61 autocmd FileType make set noexpandtab shiftwidth=8
I believe it's well commented so nothing should need explanation. But if you do, or if you're proud of yours, feel free to comment. For more info, here is a highly rated book about vim:
Learning the vi and Vim Editors
Tuesday, August 31, 2010
Ludum Dare 18 and PyWeek 11
Well, Ludum Dare 18 and PyWeek 11 both went down last week. That's a great deal of speed development! I attempted to participate in Ludum Dare, as it was over the weekend, and I thought maybe I'd try something small for PyWeek despite the fact that the development window is much larger. Of course, things didn't go as planned.
Everything started out reasonably well on Friday night. I saw the theme - Enemies as weapons - and brainstormed. I sat on the floor with my toddler and drew up some prototypes in crayon on his very large drawing pad. Being a huge fan of strategy RPGs, my mind jumped straight to Disgaea
. So my first prototype was simply a strategy RPG where you don't have any weapons, but you can pick up your enemies and smack other enemies with them. The enemies, I thought, could have a rock-paper-scissors-like relationship. But alas, I figured it would take too much time, and I'm not sure how enjoyable it would be.
Brainstorming with the whole family!
My second idea came from the lament of one of my fellow participants. He said the theme dictated the necessity of enemies, severely restricting the type of game that could be made. So I started to think of ways to make a game without enemies in the traditional sense. It occurred to me that enemies don't necessarily have to be biological, or even physical. A claustrophobic person (my first thought since claustrophobia was a finalist theme), for example, would see tight, enclosed spaces as an enemy. From there I figured that I could consider various afflictions as enemies, and think of ways to use them as weapons. Weaknesses and strengths, in effect. So developed my idea: a puzzle game where the player would guide four characters to the goal. One character was red-green colorblind, another was yellow-blue colorblind, one was anorexic, and the last was obese. The first two could pass through obstacles or activate switches corresponding to their colorblindness, while the light character could do things like pass over thin ice, and the heavy character could do things like depress stuck switches.
The idea seems kind of contrived looking back, but I ran with it. I managed to get a few hundred lines of Python and Pygame
code in and a bit of rudimentary art, but alas, it was not to be. Turns out having a toddler and an infant to take care of is pretty time consuming. I think next time I will choose a much simpler game idea just to get something out there. The puzzle game would've taken all my time just to get a playable first level, and I'd have had to wait until afterwards to add more. It certainly didn't help that I was learning Pygame along the way, and I hadn't actually made a game for years. So it was really nice getting some practice in. My PyWeek project never really got off the ground, as my toddler got sick (double ear infection - ugh) and then I got sick. Oh well. I'm not too attached to my Ludum Dare game idea so I won't finish it, but I do look forward to getting back to work on those game ideas that have been kicking around in my head for ages.
Everything started out reasonably well on Friday night. I saw the theme - Enemies as weapons - and brainstormed. I sat on the floor with my toddler and drew up some prototypes in crayon on his very large drawing pad. Being a huge fan of strategy RPGs, my mind jumped straight to Disgaea
. So my first prototype was simply a strategy RPG where you don't have any weapons, but you can pick up your enemies and smack other enemies with them. The enemies, I thought, could have a rock-paper-scissors-like relationship. But alas, I figured it would take too much time, and I'm not sure how enjoyable it would be.
Brainstorming with the whole family!
My second idea came from the lament of one of my fellow participants. He said the theme dictated the necessity of enemies, severely restricting the type of game that could be made. So I started to think of ways to make a game without enemies in the traditional sense. It occurred to me that enemies don't necessarily have to be biological, or even physical. A claustrophobic person (my first thought since claustrophobia was a finalist theme), for example, would see tight, enclosed spaces as an enemy. From there I figured that I could consider various afflictions as enemies, and think of ways to use them as weapons. Weaknesses and strengths, in effect. So developed my idea: a puzzle game where the player would guide four characters to the goal. One character was red-green colorblind, another was yellow-blue colorblind, one was anorexic, and the last was obese. The first two could pass through obstacles or activate switches corresponding to their colorblindness, while the light character could do things like pass over thin ice, and the heavy character could do things like depress stuck switches.
The idea seems kind of contrived looking back, but I ran with it. I managed to get a few hundred lines of Python and Pygame
code in and a bit of rudimentary art, but alas, it was not to be. Turns out having a toddler and an infant to take care of is pretty time consuming. I think next time I will choose a much simpler game idea just to get something out there. The puzzle game would've taken all my time just to get a playable first level, and I'd have had to wait until afterwards to add more. It certainly didn't help that I was learning Pygame along the way, and I hadn't actually made a game for years. So it was really nice getting some practice in. My PyWeek project never really got off the ground, as my toddler got sick (double ear infection - ugh) and then I got sick. Oh well. I'm not too attached to my Ludum Dare game idea so I won't finish it, but I do look forward to getting back to work on those game ideas that have been kicking around in my head for ages.
Friday, August 27, 2010
Getting started with C++ game development
There is considerable debate among indie game developers about whether C++ is ideal for beginner game development. There are quirks to using C++ that make it more difficult for the beginner to learn to program, issues related to compilation, syntax, and style. However, it remains an extremely popular choice due to the amount of libraries and support available.
If you're just starting out in programming and you've chosen to use C++, then you almost certainly need a book, and preferably even a class if you aren't particularly self-disciplined. For an introduction to C++, I'm not sure you can top the most recent book by the man himself, Bjarne Stroustrup, the creator of C++:
Programming: Principles and Practice Using C++
Alternatively, if you already know how to program and want to get acquainted with C++, then the following book is always highly recommended:
Accelerated C++: Practical Programming by Example
You aren't exactly required to be an expert in C++ before you begin developing games, but generally the more you know, the better. Some very useful libraries may be beyond your comprehension, and you'll end up reinventing the wheel several times over -- usually very poorly. Speaking of libraries, let's move on to those. To get started with PC game development, there aren't any better places to start than SDL, the cross-platform library that can handle graphics, sound, networking; if it's useful for game development, SDL (and family) can do it. One developer that goes by the name lazyfoo has developed an extensive set of tutorials on setting up and using SDL. I can't recommend these enough:
Lazyfoo tutorials
He hasn't added any new ones for a long time, but he does keep them up to date. Also be sure to check out his articles for additional info. The alternatives for SDL include SFML and Allegro. SFML is newer, and while it is not as mature, it is gaining popularity among those who heavily prefer object-oriented programming. Allegro, like SDL, is mature and has an active community of users. One point to consider is that its use is largely focused on games, whereas SDL is commonly used for all sorts of applications.
That should be enough to get anyone started with 2D game development. Displaying a bunch of images on screen and getting them to move how you want is quite literally all the technology involved in just about every 2D game there is. Future posts will go more in depth, show off some code, and delve into 3D programming as well. Best of luck to you!
If you're just starting out in programming and you've chosen to use C++, then you almost certainly need a book, and preferably even a class if you aren't particularly self-disciplined. For an introduction to C++, I'm not sure you can top the most recent book by the man himself, Bjarne Stroustrup, the creator of C++:
Programming: Principles and Practice Using C++
Alternatively, if you already know how to program and want to get acquainted with C++, then the following book is always highly recommended:
Accelerated C++: Practical Programming by Example
You aren't exactly required to be an expert in C++ before you begin developing games, but generally the more you know, the better. Some very useful libraries may be beyond your comprehension, and you'll end up reinventing the wheel several times over -- usually very poorly. Speaking of libraries, let's move on to those. To get started with PC game development, there aren't any better places to start than SDL, the cross-platform library that can handle graphics, sound, networking; if it's useful for game development, SDL (and family) can do it. One developer that goes by the name lazyfoo has developed an extensive set of tutorials on setting up and using SDL. I can't recommend these enough:
Lazyfoo tutorials
He hasn't added any new ones for a long time, but he does keep them up to date. Also be sure to check out his articles for additional info. The alternatives for SDL include SFML and Allegro. SFML is newer, and while it is not as mature, it is gaining popularity among those who heavily prefer object-oriented programming. Allegro, like SDL, is mature and has an active community of users. One point to consider is that its use is largely focused on games, whereas SDL is commonly used for all sorts of applications.
That should be enough to get anyone started with 2D game development. Displaying a bunch of images on screen and getting them to move how you want is quite literally all the technology involved in just about every 2D game there is. Future posts will go more in depth, show off some code, and delve into 3D programming as well. Best of luck to you!
Obligatory Welcome Post
Hello fellow hobby game developers!
This is your friendly, neighborhood welcome post on a new blog that will hopefully have some useful content at some point. We shall see about that though. For the record, at my day job I frequently use C++, with the occasional Python and Bash. In my spare time I've written a few PSP games in Lua and less than that in C, and on the PC side a few toy games and applications in C++ and Python. Nothing major so far.
I frequent gamedev.net, and here I hope to post my thoughts, comments, and impressions on various indie game development news, events, and competitions and the indie game scene in general. Wish me luck!
This is your friendly, neighborhood welcome post on a new blog that will hopefully have some useful content at some point. We shall see about that though. For the record, at my day job I frequently use C++, with the occasional Python and Bash. In my spare time I've written a few PSP games in Lua and less than that in C, and on the PC side a few toy games and applications in C++ and Python. Nothing major so far.
I frequent gamedev.net, and here I hope to post my thoughts, comments, and impressions on various indie game development news, events, and competitions and the indie game scene in general. Wish me luck!
Subscribe to:
Posts (Atom)