   Let's make Pac-Man! (using TDD)
  OK, guys, here's the idea: we're gonna develop a Pac-Man game from scratch. I'm gonna do the actual coding, and you guys are gonna help me figure out what to code. I already have some experience coding games, but most of my experience is hacking rather than proper software engineering. So the idea is, we're gonna sit down and learn how to do it the right way -- so I'll learn how to do it, and at the end of it this whole exercise should make for an interesting tutorial. I'm interested in trying out both test-driven development <s>and model-view-controller, so we'll build our system with this in mind. (EDIT: model-view-controller is no longer going to be a focus point of this project. See a few posts below.)By the way, we're going to use The Pac-Man Dossier as the basis for our AI, so that side of things is already figured out; we just need to implement it. (In fact, the existence of this document is the reason I chose Pac-Man.)We're gonna start from the very beginning and slowly work our way up. First we're gonna need a Subversion repository or something so we can easily share the codebase. We also need to work out what compiler to use (my vote is for Visual C++ Express for simplicity), what libraries to use (my vote is for SDL), and what unit testing framework (I'm not sure yet).OK, so, our first step is getting a repository. Should we try SourceForge, or does somebody have a better idea?- Kef[Edited by - FurryKef on May 25, 2009 11:20:51 AM]
  Well, considering the current level of enthusiasm, it seems I need to take some initiative! Perhaps you guys would be more excited if we get all the pre-programming crap out of the way right now and dive right in? :)I found out that Google Code offers free Subversion hosting, so we'll just use that. I settled on the rather lame name "freepac", since my first two choices (SlackMan and HackMan) were, unsurprisingly, already taken by other Pac-Man clones. I figure that if somebody comes up with a better name, we can change it.So, our project's home is now http://code.google.com/p/freepac/.As for the remaining pre-coding decisions:* We'll start with Visual C++ Express 2008. (I'd have chosen 2005, but, alas, the latest prebuilt SDL_image is for 2008.)* Graphics, input, etc. will be pure SDL, but later on we might also make an OpenGL renderer as an exercise. (This won't affect the early stages of development anyhow because we're using test-driven development, and unit tests won't require actual game I/O. Still, it's not too early to think about it.)* We will use UnitTest++ as the testing framework.There. Now we should be ready. :)Current taskFigure out where to begin coding. Remember, we're using test-driven development, so what we have to do is figure out what our first test cases are going to be.Where shall we begin?* Character movement?* Setting up the maze?* Ghost AI? (The most interesting problem, but perhaps starting there would be premature?)* Somewhere else?I'm partial towards setting up the maze first, because most of the rest is affected by the maze (walls impede movement, etc.). But let's see what you guys think. :);Quote:will be pure SDLThis will apparently be in C++ (why? why not flash, Google O3D, Unity, &#106avascript)? Why not use SFML which is C++ equivalent?Quote:This won't affect the early stages of development anyhow because we're using test-driven developmentThis is crucial requirement. What is your target platform? Who is your target audience? YAGNI and all that. Do you need to support abstract graphics' system or not? What if I want to run this on iPhone? What about OpenGL problems on various platforms? What about framerates of non-accelerated OGL? TDD is about getting the job done, not about being generic. If you want generic design, use IOC.Quote:Ghost AI? (The most interesting problem, but perhaps starting there would be premature?)The document completely explains how the logic is hard-wired, so it's by far the simplest thing to code (not really a problem, it's fully specified).Quote:I'm partial towards setting up the maze first, because most of the rest is affected by the mazeMaze is an array (choose either 1D or 2D). And you're done with it. By far the simplest task. YAGNI. Quote:* Character movement?Location of ghosts/pacman is a tuple of (old,new) position, plus animation timer to render in between (fully explained in document IIRC). Done.Quote:* Setting up the maze?It's hard-coded. Set the maze array to predefined values.Remember, TDD is intended for efficiency and to enforce extreme YAGNI. You have complete specification. Use the simplest thing that gets the job done, and nothing more. Arrays are hard-coded, mob counts are hard-coded, movement is hard-coded, everything is hard-coded.And if you wish to deviate from the document (the linked one), then the very first step is to define functional requirements (stories, use cases, ....). Then write a unit test that implements them. Then write the code that makes the test case pass. YAGNI. And you're done.The whole point of TDD is that you don't think. You don't worry about future, about extension or about anything else. It's mindless implementation that delivers exactly, and nothing less and nothing more than what use cases require.   ;NOTE: I've had some discussion on IRC and the point was made that setting out to develop a project with MVC from the outset misses the point of design patterns. In other words, you should develop the pattern to fit the code, not the code to fit the pattern. Furthermore, setting out to use MVC violates YAGNI. Hence, I'm dropping MVC from the premise of the project. However, the underlying motivation -- that the various systems involved should be decoupled as much as practical -- will remain.Quote:Original post by AntheusQuote:will be pure SDLThis will apparently be in C++ (why? why not flash, Google O3D, Unity, &#106avascript)? Why not use SFML which is C++ equivalent?There are a few reasons why I chose C++:* C++ is sort of a game development "lingua franca". My own language of choice is Python, but if I chose it, then people who don't know Python would have a difficult time following along.* I'm working with a team of developers (on another project) who are less experienced than I am, and I'm doing this partly to teach them solid programming principles. Since our company develops games in C++, it makes sense to develop this in C++ as well. * Debating the language choice in this thread wouldn't be productive, because of the vast array of choices and yet it's fairly arbitrary anyhow. If I chose Python, why not C++? Why not Java? Any choice could be met with endless "Why not _____?" and we wouldn't get anywhere. C++ seems to be about as good as any choice (certainly a more clunky language than I'd like, but there are the previous two points to consider).As for SFML, I suppose I should look into it. I don't really want to get too hung up on deciding on an API, though...Quote:This is crucial requirement. What is your target platform? Who is your target audience? YAGNI and all that. Do you need to support abstract graphics' system or not? What if I want to run this on iPhone? What about OpenGL problems on various platforms? What about framerates of non-accelerated OGL? TDD is about getting the job done, not about being generic. If you want generic design, use IOC.Well, the idea here is that game logic is separate from rendering logic, and game logic, if properly decoupled, is independent of any API. It would also seem to make sense to begin unit testing with game logic, hence why I thought decisions in this area aren't immediately necessary.But as for the target platform, I think it should be relatively platform-independent, so I'd say Win/Mac/Linux. We won't worry about OpenGL stuff until we actually make an OpenGL renderer; I'd prefer to use a pure SDL renderer to start with.Quote:Maze is an array (choose either 1D or 2D). And you're done with it. By far the simplest task. YAGNI.You make some good points here (and in the other points of your post). However, my question is aimed at the tests. That is, we should be thinking in terms of the tests, not the data structures; the tests dictate the structures. I see that you're giving your answers with the basic philosophy of TDD (and more specifically DTSTTCPW -- Do The Simplest Thing That Could Possibly Work) in mind, but we haven't yet answered the question of what our first test is going to be.[Edited by - FurryKef on May 25, 2009 12:16:17 PM]