Summer Reading Status

I'm about halfway through Code Complete and have realized three things:

1. Code Complete is an amazing book.
2. Shmup01's code is pretty terrible and much of it will need to be redesigned and rewritten.
3. Like Accelerated C++, I'll probably end up reading some or all of Code Complete.

Thoughts on Accelerated C++

Realizing this is about a month overdue, I'm posting my thoughts on Accelerated C++ while I still remember what it was about.

This book is definitely NOT for beginners, and I wouldn't recommend it to anyone that is just learning how to program. However, if you know a little C++, this book is no bore. If I could summarize it in one sentence (and steal a line used regularly in Code Complete), I would say that Accelerated C++ does a good job of teaching you how to program in the language rather than into it. The focus is on teaching through examples so, instead of getting an overview of all data structures available in STL in one big chapter, individual data structures are introduced as needed by the examples. Manipulating the structures through iterators and built-in algorithms is treated the same way - they are presented as the sample problems in the book grow to require their functionality.

Generic programming, effective use of inheritance, and some specific concepts such as handle classes are all presented extremely well in this book. Some relatively basic concepts are explored in a greater level of detail than you might read in other "how to program" books (explicitly establishing an invariant in while loops comes to mind), but by no means is this book a comprehensive guide to programming or to the language, something the authors agree with in the introduction.

That being said, I feel like I might need to give this one another read down the road. Some of the concepts presented later in the book, such as providing conversion capabilities to your classes and, again, the handle class, were pretty new concepts to me and I'm not sure I could leverage this knowledge without giving it another read and setting up some sample programs to get the hang of it. At this point, I feel like I've been given handed a rocket launcher with no instructions. I could try to use it but the odds are that the results will be catastrophic.

Pause IRL

I'm taking a break from coding. The size of the project has reached a point where I'm now officially navigating unchartered territory. At this point, the design decisions that I'm making will affect future iterations of the project and I want to make sure I don't build an entire house before realizing I need to move a few walls around on the first floor. In coding terms, I'm trying to decide how enemy patterns, weapons, bullets, and bullet patterns should all interact. My usual approach would be to start very simple, such as enemies that spawn based on a fixed pattern, shoot a few straight-lined bullets, and then die when they get shot. But I need to make sure that building something this way is flexible enough that if I want to have enemies move in linear patterns, and then curved patterns, and then a sequence of linear and curved patterns (etc...), that I don't have to rewrite large blocks of code every time I improve functionality.

I have a few designs in mind, and I'm getting a lot done on paper. But before I actually put anything into place, I want to step back and do a little summer reading and see if I can't draw upon the wisdom of some experienced programmers before embarking on this journey.

Summer reading list:

• Accelerated C++
• Code Complete 2nd ed.
• Effective C++

Extra credit:

• The Pragmatic Programmer
• Effective STL
• A book about design patterns

I finished Accelerated C++ this week and just started reading Code Complete. The next few blog posts will probably be book reviews and design discussions instead of project status. Hopefully the time I invest now will yield faster, better programming down the line.

Much Ado About Nothing

So I thought that changing my game coordinate system from 'int' to 'float' would wreak havok and... I was wrong. Changing everything took less than an hour, cleaning up some warnings took 15 minutes, and the game now plays 10 times better.

This story has 2 morals:

1. Carefully crafting modular software on the front end will save you from huge headaches when you (inevitably) end up changing something fundamental later.
2. For bullet hell shmups, floats >>>> ints.

Float it is

The forum gurus weighed in and convinced me to change everything to float. I'm starting tonight... this'll probably take a couple days.

New Blog: MatrisGames

I need a blog dedicated to games that aren't mine, so here it is.

One step forward, one (massive) step back

Thanks to Darkness for shedding a little light on the memory leak courtesy of TTF_RenderText_Solid. Shmup02 specs are still in the works, but I might try to write up a game design doc based on the Shmup01 engine first. Of course, this would require a couple more modifications to the engine (such as storing level data).

In the meantime, one big dilemma I've been facing is whether I should be using float or int for all of my coordinates. More details can be found on my gamdev.net forum post. Ultimately, it sounds like float is the way to go, which means I'll need to do some serious reworking of the engine to eliminate all traces of int from the code. It's going to be a pain, but I think the long term benefits will be worth it.

In the meantime, stay tuned for updates on my Shmup01-based game!