One unit a week will get me there but I'm shooting to do two a week as long as I can to allow a safety margin.
Here's a closer look at the now finished unit featured in the last post.
Saturday, March 28, 2020
Today's Troop Review
My initial goal was six units per side, one per month since last May but although behind schedule by the time February arrived, my goal is now eight units or more per side by the end of April.
British and Emigre Forces: 1 Gun, 2 Infantry units. (plus a Brunswick infantry unit in old fashioned hats standing by if needed)
Republican French: General, 1 gun, 1 Light Cavalry, 1 Sharpshooter, 2 Infantry.
The Year In Review, Just The Leisure Time
Last January I did a review of how I spent my leisure time the previous year, and I set down a few expectations for the coming year, now past. It's time to look back and see how my actual activities stacked up to my expectations, and maybe learn something for the fresh year to come in 2020. I had big ambitions between reading, blogging, and playing, and not all of them were achieved. But, that's okay because it makes it easier to figure out what I want to do this year—some of what I didn't finish last year, and some new ideas and desires. How I spend my leisure time is very important to me. It should be at the same time relaxing and reinvigorating, enjoyable and enriching, soothing and stimulating. If one thing is obvious, it's that I still love to read because it hits all of those notes, and that is likely to continue in the year(s) to come.
Blog Posts
I'll start out again with what I've done on my blog, and I very nearly did everything I set out to do. I wrote 17 posts (not counting this one) instead of the predicted 18 because of how the 3-week intervals fell. They were almost all Tech Book Face Offs, except for the last two that were a general review of books I will read again and programming practice sites that I've enjoyed, and a random Physics Book Face Off that I threw in there in April to mix things up.
The most popular post by far was the review of books that I'll read again, which racked up over twice as many hits as the next most popular post, and it was pretty fun to write as well. This was not your normal list of best books because I'm tired of reading best-programming-book lists that put up the same old safe books like CLRS or Knuth's The Art of Computer Programming. This post had a little of that just because some of those books are great to reread, but these were all genuinely books that I want to read again, not just because they're instructive, but because they're enjoyable reads. They make my brain tingle. They get me excited about programming and learning (or relearning) new things.
Of the Tech Book Face Off posts, the top three most visited ones were Python For Data Analysis Vs. Python Data Science Handbook, How To Design Programs Vs. Structure and Interpretation of Computer Programs, and Seven Concurrency Models in Seven Weeks Vs. CUDA by Example. These were all good, but the one that was most fun for me was easily Game Engine Black Book [Wolfenstien 3D Vs. Doom]. Reading these books was a blast, and writing down my thoughts about them was just as fun and satisfying. I'm surprised it didn't gain more traction, but I'm pretty much done trying to figure out which posts are going to take off and which ones will fly under the radar of the Internet.
For the coming year, I'm planning on keeping up the same cadence, which means 18 more posts. That's really 18 posts, too. I checked. I didn't get to that exciting blog series I alluded to last year because the schedule was filled up with reviews, but I'm intending to start in on it right away this year. The book review posts will be much reduced as well. I've only got about a dozen programming books on my list that I'd still like to read, and I'll probably hold off on them while I work on this other project.
Technical Books
I really dug into the technical books this past year, even more than the previous year, and I just met my goal of 22 books (plus 2 pop physics books) while working through most of my tech book backlog. As I had hoped, most of these books were quite good. A fair number of them even made it onto my read-again list. There were only a few duds and one stinker. Here's a run-down of them, roughly ranked in order of preference and linked to the longer Tech Book Face Off reviews.
The Good
- Game Engine Black Book: Wolfenstein 3D - Between the high level of nostalgia and the fascinating topic, there was no way this book wasn't going to top this list. It's an incredibly well-done guide to how Wolfenstein 3D was made.
- Game Engine Black Book: Doom - Arguably, this book is even better than the Wolf3D one, but you should really read that one first so this one comes second. I highly recommend them both for anyone curious about how these legendary games were done on such feeble hardware.
- Rails AntiPatterns - I loved the tactic this book took of showing bad Rails code, explaining why it's bad, and then showing how to fix it. Some books do this sporadically without telling you in advance, but this worked so much better, knowing that each example was intentionally bad from the start so there was no confusion about what was the right way to do things.
- Data Smart - This was the most fun I've had reading a book on Excel spreadsheets. Not that I read many books on spreadsheets, but if I did this would definitely be the best. It's about implementing data science algorithms in Excel with humor, and it's so much better than it sounds.
- Don't Make Me Think Revisited - I enjoyed the first book, and the revised edition is just as good. Learn all about how to design user interfaces that make sense, and have a great time doing it.
- Structure and Interpretation of Computer Programs - A classic that still holds up today for teaching the fundamentals of programming and much more, this book has a steep learning curve, but the rewards match the effort it takes to get through it.
- The Hidden Reality - This was a super fun and mind-expanding read, taking us through the numerous types of multiverse concepts that have been thought up by cosmologists. Brian Greene continues his excellent, approachable writing style with this enjoyable book.
- Parallel Worlds - Michio Kaku does his own tour of the different types of multiverses we can conceive of, with a few more fantastical stories thrown in for good measure. This is another great book to read to get the high-level overview of this topic.
- Facts and Fallacies of Software Engineering - You don't have to agree with everything in a book for it to be excellent, and that's the case here with Robert L. Glass' thought-provoking arguments about the software engineering industry. Still relevant after 17 years.
- Professional CUDA C Programming - If you're interested in GPU programming and want to play around with your nVidia graphics card, this book has all the information you need to get started in a nicely written, diagrammed, and organized guide.
- Python Machine Learning - It's a solid introductory text on the fundamental machine learning algorithms, both in how they work mathematically, how they're implemented in Python, and how to use them in scikit-learn and TensorFlow.
- Data Science From Scratch - Fundamentals are so important to learning a topic well, and this book does a great job of teaching the fundamentals of data science by implementing the algorithms from scratch in Python.
- Seven Concurrency Models in Seven Weeks - I've loved every 7-in-7 Weeks book that I've read, and this one is no exception. It's an entertaining read through seven different ways to do concurrent programming with today's technology.
- The Non-Designer's Design Book - Learn how to design boldly in text and graphics with a few simple rules and clear, straightforward guidelines. Anyone and everyone who works around websites should give this quick read a look.
- Getting Clojure - If you're looking for a fun read and a tour of the Clojure programming language, this is the book to pick up.
- Effective Python - Every programming language has its beyond-the-beginner-level book on how to write programs in that language well, and this is the one to read for Python.
- Programming Elixir ≥ 1.6 - An excellent book for learning the ins and outs of this highly concurrent, fault-tolerant language, and it's well worth a read if you're operating in that domain.
- Metaprogramming Elixir - This book fills in the few gaps in Programming Elixir ≥ 1.6, and it's a great companion to that book.
- Programming Pearls 2 - This is a fairly decent algorithms book that's worth a read as a casual second or third book on programming algorithms.
The Not-So-Good
- CUDA by Example - This book is clearly written, but not especially well-written. Still, it's a good introduction to CUDA programming that covers the basics. Just don't feel compelled to read it all the way through, as the later chapters are fairly useless.
- Learn Functional Programming With Elixir - Neither thorough on Elixir nor especially focused on teaching the unique aspects of functional programming, this book left a lot to be desired. It's fine, but not great in any respect.
- Programming Massively Parallel Processors - For a subject that is inherently interesting to me, this book managed to be tedious, verbose, and opaque in its explanations, and way, way, way too long. The necessary information is in there, but it's not worth the effort when there are better options available.
- The Rails 5 Way - This book was so much longer than it had to be. It was light on discussion and super heavy on documentation, as if it was simply a transcription of the online documentation into a book.
The Suck
- How to Design Programs - Nearly 750 pages of the most tedious, drawn-out, agonizing explanations about learning to program, I disagree with the title given to this book. Nowhere in it does the reader learn how to design programs, maybe design of functions at best.
This showing is much better than last year, with a half-dozen more good books, and less bad books. It was actually quite hard to rank the good section beyond the first few because they were all well-written and engaging. I don't know if I was better at selecting good books to read, or if I just got lucky, but I was pleased with the high level of quality in this year's book list.
Novels
As planned, I read even more technical books this year than last, but I still managed to read some great novels in the past year. Partly, this is because of listening to audiobooks in the car, and I have a 30 minute commute to fill. The number of books I got through was still less, but some of them were much longer than what I read the previous year. Again, they're roughly ranked.
- The Way of Kings, Words of Radiance, Oathbringer - Wow. Just WOW. I could not believe how wonderful these books are. The characters are all flawed and broken and so human, the story drags you along as you watch in amazement at how everything develops, and the world that Brandon Sanderson built in this Stormlight Archive series is simply incredible. It has weight. It has life. It has history. I can't wait for the next book to come out.
- The Fifth Season, The Obelisk Gate, The Stone Sky - This trilogy is just as awesome as the Stormlight Archive series, and I was constantly amazed at how clearly written the world of the Stillness is. The fantastical powers that the orogenes and Guardians have could be confusing, but N. K. Jemisin writes so simply and beautifully that everything was crystal clear in my mind as I read it. The story is at the same time one of the most engrossing tales I've ever read and a powerful allegory about the struggles of racism in society. It's enlightening and revealing without being accusatory. Beautifully done.
- The Golden Compass, The Subtle Knife, The Amber Spyglass - Throughout this trilogy I was continually surprised by the incredible imagination of Philip Pullman. Each book brings entirely unique new elements into an already rich and diverse world, or rather many-worlds. Even with all of these new elements being introduced, the world always felt cohesive and real. Everything made sense within the context of the story. This is a hard thing to do right, and Pullman did it masterfully.
- The Eye of the World - I'm just getting started in this long Wheel of Time series, and I'm already hooked. The first book is essentially one long, thrilling chase through a world of mystery and magic. The reality of the world is revealed slowly, and the suspense of wondering when you'll find out that next tidbit of knowledge about the world was gripping. By the end I have more questions than answers, and I'm ready to learn more about the Wheel of Time.
- Snow Crash - This book was ridiculously fun, plain and simple. The setup makes no sense at all and the story doesn't care one whit about anything, but it doesn't matter. You're a pizza delivery boy in the future who also happens to be the world's best samurai swordsman and an elite haxxor. You get mixed up in some crazy shit and lots of weird stuff happens. It's a wild ride, and you're just going to have to read the book to see how it all works out.
- Jurassic Park - It's a book about man recreating dinosaurs in the modern age. What could go wrong? And what's not to like? This book is basically a classic at this point, and great fun to read.
- Ringworld - While the premise of this book was interesting—humans and aliens go visit an enormous world built in a ring around the aliens' host star—I just couldn't get into this book by Larry Niven. The story was only tangentially about the ringworld, and the main focus was actually about whether people could be bred for luck. It seemed like Niven wanted to write about building a ringworld, but couldn't figure out how to write a compelling story around that so he had to also write about this other thing to justify it. Also, his writing was too disjointed for my tastes. Scenes changed so abruptly and dialog and narration was so terse that I had trouble understanding what was going on most of the time. That was a huge disappointment, especially considering the other books on this list.
- The Color of Magic - This book was another disappointment, but for a different reason than Ringworld. The writing was fine, even funny sometimes, but the discworld made no sense at all. Completely random and nonsensical things would happen to the main characters at every turn, and I never could figure out what the plot was about. It didn't take long to lose interest in the characters altogether, since whatever happened to them wouldn't make any sense whatsoever and they were probably going to end up fine anyway. There were a lot of similarities in style to The Hitchhiker's Guide to the Galaxy, and while similar elements somehow worked there, they fell totally flat in The Color of Magic. That leaves me with no reason to read the other 40 books in the series, lucky me.
One of my goals here was to branch out and read new authors, and I mostly held to that goal. There's no Stephen King, Neil Gaiman, or Dragonlance books on the list, but I did read another book by Neal Stephenson after Seveneves and was not disappointed. The first eleven books were extremely hard to rank. They're all basically equivalent levels of awesome in my mind, and you absolutely should go read them if you haven't already. The stories are incredible, and the worlds these authors imagined and built are even more incredible.
I also reread Jurassic Park, from my youth, by way of introducing it to my daughter, who absolutely loves dinosaurs. It was well received. For this year, I already know I'll be rereading The Lost World with her. I'll also be continuing The Wheel of Time saga, and starting another new author for me, Ursula K. Le Guin, with A Wizard of Earthsea. Other than that, I'm thinking of finishing up the Foundation series by Isaac Asimov and reading a few more new authors. All I know is there are a lot more worlds to explore.
Video Games & Movies
I actually have not watched many movies this year. It didn't seem like there were too many worth watching. I did see Avengers: Endgame, of course, and it was probably one of the best movies I've ever seen, considering the vast context and buildup of the rest of the MCU. I also finally saw Captain Marvel (I wait until I can get movies from the library), and that was pretty good, too.
One of the more unique movies that I did end up watching was Annihilation. I happened to get it when I was by myself in the house one night, and I popped it in the PS4, turned off the lights, and turned the sound way up. That was an intense, wonderfully creepy experience. Do you know how great the sound effects are in that movie? And that freaking bear, holy crap. I'm surprised I got any sleep that night.
I also rewatched The Lord of the Rings with my wife. Those movies hold up really well. If the movie drought continues, I've got a growing list of other (not-so) old movies to watch again, like Jurassic Park.
As for video games, I'm still enjoying the LEGO videogames with the kids. We finished up Jurassic Park (are you seeing a theme here?), The Hobbit (much better than the movies), and most of Marvel Super Heroes. We're still working on The LEGO Movie, Batman 3: Beyond Gotham, and LEGO City: Undercover (this game is ginormous). Then we've started Marvel Super Heroes 2, Marvel's Avengers, and we just got another batch of LEGO games for Christmas. I don't know why, but I don't ever seem to get tired of these games. It's gotta be the character development. (I'm kidding; it's the graphics.)
For myself, I ended up playing Lightning Returns: Final Fantasy XIII and God of War III. These are two very different games, and yes, they're both older than dirt. I said last year my backlog was deep. I know Final Fantasy XIII got a lot of criticism, but I still enjoyed the whole trilogy. I especially liked Lightning Returns for the new battle system. Gone are the menus and inventory lists, and instead you link four different actions to each of three different outfits to set up your available commands for a battle. You have a few other special actions that you can do, and then you're choosing actions in real time during battles. It's a much more dynamic, exciting battle mechanic than selecting actions from menus, and like most Final Fantasy mechanics, surprisingly deep. It really made the game for me. Lord knows the plot didn't.
God of War III was another installment of hack-n-slash, vengeance-upon-the-gods action game that was pure entertainment. I was reminded of how perfectly responsive the controls are in these games, and I think the most fun to be had was beating the crap out of Hercules.
The Year Ahead
I have more than enough games to play this year as I play through my backlog. I actually got more new games than I finished, so that backlog is just getting deeper. If only there was more time. I won't be reading as many technical books, so there's that, but I'll probably fill a lot of that time with more novels and the next blog project. Still, maybe I can squeeze in a couple more games, and I haven't picked up the guitar again, yet.
Tech Book Face Off: Game Engine Black Book [Wolfenstein 3D Vs. Doom]
After all of the heavier reading I've been doing lately—machine learning, CUDA programming, fundamental Lisp programming, etc.—I wanted to kick back and read something a bit more relaxing and entertaining. Luckily, at just the right time a friend lent me a couple of books that promised to fit the bill perfectly: the Game Engine Black Books for Wolfenstein 3D and Doom, both by Fabien Sanglard. I grew up with these games, with them being my first and second PC FPS games. I played countless hours of these and other id Software games and other games that used id Software engines like Rise of the Triad, Heretic, and Hexen. I couldn't wait to dig into these books and see what was underneath the games that pleasantly wasted away the night hours of my youth.
This Black Book starts out with forwards by John Carmack, Tom Hall, and John Romero, and then there's a short introduction that gives an overview of the game market, the PC market, and the state of video games in that era. This was the time of Super Nintendo and Sega Genesis, and the i386 processors had been out for a few years by the time Wolfenstein 3D was released. The i386DX-33 was over four times more powerful than the Super Nintendo processor, and even more powerful i486 processors were coming to the market from mid-1989 to 1992. The video game consoles were primarily sprite-based hardware designs, so they weren't set up for running a 3-D game like Wolfenstein well at all. The PC was definitely the hardware of choice for this game, power-wise, but as Sanglard goes on to explain, it had its own downsides for game development.
The next chapter went into the state of the hardware that was targeted for Wolfenstein 3D in detail. The game was designed to run okay even on an i286 CPU, but even on the i386 processors, the compromises that were made in the design were astonishing. I had forgotten how bad things were back then with no hardware floating point units, only a handful of registers, and an utter mess of a memory hierarchy with real mode and segmented addressing. The state of video cards was not much better with no direct double-buffering in hardware, an essential feature for running smooth animation in a 3-D game. These VGA video cards were not set up to run games in the least, so double-buffering needed to be hacked and kludged together. Thankfully, that was possible to do. Sound was just reaching a tolerable level of performance at the time with AdLib and Sound Blaster cards, if you sprang for the add-in card and were able to get it working. Sound cards were rarely included in PC builds at the time, and I remember many a night fiddling with vaguely understandable IRQ and DMA settings before plug-n-play. Funny, now I actually know what those things mean, and what they're used for, but it's all handled automatically by the chipset and the OS.
That chapter was definitely a fun trip down memory lane. The next chapter switched gears and was all about the decidedly small team that made the game, especially by today's standards, and they completed the game in four months! There were four full-time people that founded id Software a year before starting Wolfenstein 3D. John Carmack and John Romero were the programmers, Adrian Carmack was the artist, and Tom Hall was the creative director. Another four people contributed, but did not work on the game full-time from start to finish. These were Jay Wilbur in business, Kevin Cloud as a computer artist, Robert Prince as the composer, and Jason Blochowiak as another programmer. The development studio was none other than the first floor of John Carmack's two floor apartment. Wild. The rest of the chapter went through the development tools they used and built to make the code, level maps, artwork, and sound assets of the game.
Chapter 4 gets into the real meat of the game architecture, and it's the longest chapter of the book. It was fascinating to learn about the ingenious performance hacks and algorithms they (mostly John Carmack) implemented to achieve playable frame rates with the hardware they had to work with. The game is restricted in numerous ways so that the code doesn't have to spend much time calculating things like clipping or player perspective. The floor and ceiling were solid colors, and all walls were orthogonal. The player couldn't look up or down, jump, or crouch, so walls were always perfectly vertical and the (obscured) horizon was always dead-center on the screen. The only polygons in the game were the walls, which were rectangles. Everything else was a sprite. The maximum view port was smaller than full-screen at 304x152 pixels, and it could be adjusted down from there if needed for a faster frame rate on slower hardware. These along with plenty of other restrictions made the game playable on the i286, although the best experience was still on an i386DX or better CPU.
The other common optimization was to code critical loops and code sequences in x86 assembly. Quite a few code listings in the book are just lines of assembly code, mostly of moving values around in various registers. Dropping down to assembly was necessary because compilers at the time weren't the best at outputting even remotely optimized code, and a smart developer could arrange assembly code much better than any compiler could. This deficiency in the compiler shouldn't all be blamed on it, for x86 assembly was truly horrendous. I am at the same time in awe of John Carmack for doing what he did with the code and eternally thankful that I never had to do x86 assembly programming like that myself. Even today it's something to be avoided because the complexity is now nearly unmanageable and compilers have made huge strides besides, but oh my gawd, that assembly programming must have been the most awful, tedious exercise in memorizing and recalling useless instruction set trivia.
This whole chapter was pure gold, covering everything from the renderer in detail to the enemy AI to the audio programming and sound effects. The writing wasn't always the greatest, but explanations were at least insightful, and I could always parse out what Sanglard meant, even with numerous typos and grammatical errors. Normally these kinds of mistakes would be obnoxious, but the book was so full of great pictures, diagrams, and information that was completely engrossing to me that I was willing to overlook that shortcoming.
The last few short chapters were also quite interesting, and a nice way to wrap up the book. Chapter 5 described the sequel to Wolfenstein 3D, Spear of Destiny. Chapter 6 covered a number of ports to other systems, including Super Nintendo (heavily compromised), Jaguar, iPhone, and VR ports. Chapter 7 concluded with a little information about the successors to Wolfenstein 3D and where each of the designers and developers are now. The whole book was an excellent tour of a classic game that changed the video game industry forever, and if you're at all interested in the details of one of the games that started the FPS genre, you have to read this book.
 | VS. |  |
Game Engine Black Book: Wolfenstein 3D
I quickly realized what a beautiful book this was going to be with nearly full-page, glossy color pictures of the game and die photos of the Intel 80386-DX processor that ran the game when it first came out on May 5th, 1992. It was incredibly fun to just page through the book and look at the different pictures, and peruse the various explanations surrounding the pictures about the game engine's design. It took a little while to settle down and actually start reading through the book.This Black Book starts out with forwards by John Carmack, Tom Hall, and John Romero, and then there's a short introduction that gives an overview of the game market, the PC market, and the state of video games in that era. This was the time of Super Nintendo and Sega Genesis, and the i386 processors had been out for a few years by the time Wolfenstein 3D was released. The i386DX-33 was over four times more powerful than the Super Nintendo processor, and even more powerful i486 processors were coming to the market from mid-1989 to 1992. The video game consoles were primarily sprite-based hardware designs, so they weren't set up for running a 3-D game like Wolfenstein well at all. The PC was definitely the hardware of choice for this game, power-wise, but as Sanglard goes on to explain, it had its own downsides for game development.
The next chapter went into the state of the hardware that was targeted for Wolfenstein 3D in detail. The game was designed to run okay even on an i286 CPU, but even on the i386 processors, the compromises that were made in the design were astonishing. I had forgotten how bad things were back then with no hardware floating point units, only a handful of registers, and an utter mess of a memory hierarchy with real mode and segmented addressing. The state of video cards was not much better with no direct double-buffering in hardware, an essential feature for running smooth animation in a 3-D game. These VGA video cards were not set up to run games in the least, so double-buffering needed to be hacked and kludged together. Thankfully, that was possible to do. Sound was just reaching a tolerable level of performance at the time with AdLib and Sound Blaster cards, if you sprang for the add-in card and were able to get it working. Sound cards were rarely included in PC builds at the time, and I remember many a night fiddling with vaguely understandable IRQ and DMA settings before plug-n-play. Funny, now I actually know what those things mean, and what they're used for, but it's all handled automatically by the chipset and the OS.
That chapter was definitely a fun trip down memory lane. The next chapter switched gears and was all about the decidedly small team that made the game, especially by today's standards, and they completed the game in four months! There were four full-time people that founded id Software a year before starting Wolfenstein 3D. John Carmack and John Romero were the programmers, Adrian Carmack was the artist, and Tom Hall was the creative director. Another four people contributed, but did not work on the game full-time from start to finish. These were Jay Wilbur in business, Kevin Cloud as a computer artist, Robert Prince as the composer, and Jason Blochowiak as another programmer. The development studio was none other than the first floor of John Carmack's two floor apartment. Wild. The rest of the chapter went through the development tools they used and built to make the code, level maps, artwork, and sound assets of the game.
Chapter 4 gets into the real meat of the game architecture, and it's the longest chapter of the book. It was fascinating to learn about the ingenious performance hacks and algorithms they (mostly John Carmack) implemented to achieve playable frame rates with the hardware they had to work with. The game is restricted in numerous ways so that the code doesn't have to spend much time calculating things like clipping or player perspective. The floor and ceiling were solid colors, and all walls were orthogonal. The player couldn't look up or down, jump, or crouch, so walls were always perfectly vertical and the (obscured) horizon was always dead-center on the screen. The only polygons in the game were the walls, which were rectangles. Everything else was a sprite. The maximum view port was smaller than full-screen at 304x152 pixels, and it could be adjusted down from there if needed for a faster frame rate on slower hardware. These along with plenty of other restrictions made the game playable on the i286, although the best experience was still on an i386DX or better CPU.
The other common optimization was to code critical loops and code sequences in x86 assembly. Quite a few code listings in the book are just lines of assembly code, mostly of moving values around in various registers. Dropping down to assembly was necessary because compilers at the time weren't the best at outputting even remotely optimized code, and a smart developer could arrange assembly code much better than any compiler could. This deficiency in the compiler shouldn't all be blamed on it, for x86 assembly was truly horrendous. I am at the same time in awe of John Carmack for doing what he did with the code and eternally thankful that I never had to do x86 assembly programming like that myself. Even today it's something to be avoided because the complexity is now nearly unmanageable and compilers have made huge strides besides, but oh my gawd, that assembly programming must have been the most awful, tedious exercise in memorizing and recalling useless instruction set trivia.
This whole chapter was pure gold, covering everything from the renderer in detail to the enemy AI to the audio programming and sound effects. The writing wasn't always the greatest, but explanations were at least insightful, and I could always parse out what Sanglard meant, even with numerous typos and grammatical errors. Normally these kinds of mistakes would be obnoxious, but the book was so full of great pictures, diagrams, and information that was completely engrossing to me that I was willing to overlook that shortcoming.
The last few short chapters were also quite interesting, and a nice way to wrap up the book. Chapter 5 described the sequel to Wolfenstein 3D, Spear of Destiny. Chapter 6 covered a number of ports to other systems, including Super Nintendo (heavily compromised), Jaguar, iPhone, and VR ports. Chapter 7 concluded with a little information about the successors to Wolfenstein 3D and where each of the designers and developers are now. The whole book was an excellent tour of a classic game that changed the video game industry forever, and if you're at all interested in the details of one of the games that started the FPS genre, you have to read this book.
Game Engine Black Book: Doom
This Black Book followed a very similar format to the Wolfenstein 3D book with the same result of an incredible experience digging through the game engine of one of the most influential PC games ever made. I went through waves of nostalgia as I paged through pictures of the Doom game world and explanations of how it calculated and rendered the intense game that consumed hours upon hours of my free time growing up. It was fascinating to see how all of it was implemented, and on such meager hardware, too! id Software achieved an incredible amount of performance and features with their idTech 1 engine that they created for Doom.
The book starts off with forwards by John Carmack and Dave Taylor and a short introduction just to wet your appetite. Then it jumps into the hardware that Doom was designed for in chapter 2. Doom was able to run on an i386, but by 1993 when Doom was being developed, the i486 was becoming affordable and was over 2x faster than the equivalent frequency i386, so that was the new target system. Everything else was improving rapidly as well. Video cards took a big step up in performance with the VESA VL-Bus and tighter component integration on the cards. Sound cards became even more fragmented, unfortunately, but sound quality was improving by leaps and bounds. Networking was also becoming possible by this time with multiple ways to connect PCs for multiplayer co-op and deathmatch play. Finally, compilers had improved to the point where it wasn't necessary to do nearly everything in assembly. The Watcom compiler allowed id Software to code Doom almost entirely in C, freeing the developers to think at a higher level and implement more features more rapidly.
Chapter 3 is entirely new because id Software used an entirely different development environment for Doom. Instead of developing everything on unstable DOS PCs, they took the chance on using expensive NeXT workstations. Even a fairly basic NeXTstation cost $4,995 in 1991, and a NeXTcube ran $12,395! It turned out to be worth it, though, because these workstations were rock-solid and allowed John Carmack and the other developers to make incredible progress instead of constantly fighting with crashing machines and a poor development environment. This chapter did a great job going through the architecture and benefits of the NeXT systems, and how id Software used them to full effect.
The next chapter was about the team and tools, like chapter 3 in the Wolfenstein 3D book. Things had changed dramatically, with the team moving to Dallas, TX and growing to fourteen people by the end of development. The tools were evolving, too, with some of the character sprites and animation done using stop motion capture, and the map editor (DoomED) taking on new features to support the multitude of new capabilities in the game engine. Walls in the game no longer needed to be orthogonal, although they still had to be vertical for rendering to be fast enough. Floors and ceilings could change height to create steps, platforms, and other environmental features. Various kinds of traps and ambushes were also possible now. It's quite amazing how many features were added to idTech 1 when compared to the Wolf3D engine. These new features, especially the non-orthogonal walls and varying heights, required a more efficient data structure for the maps, and the BSP (Binary Space Partitioning) node tree was commandeered for the job.
Nearly half of the book is taken up by chapter 5 on the idTech 1 game engine. This chapter is just a monster of awesome information about the engine. It goes through every detail from the game tic design and use of fixed-point arithmetic to sound propagation and enemy AI. The section on the 3D renderer was especially interesting and detailed. There are great explanations on how the environment was drawn with its additional complexity, texture mapping with perspective correction, sprite clipping and animation, and diminished lighting to give the game its intense horror movie feel. This renderer section in particular was so interesting that it made me want to go implement a bunch of the algorithms myself just to be able to recreate them and see them in action. It looks like it would be immensely satisfying.
The last chapter described in fairly good detail how a number of ports of Doom were done on other game consoles. The console ports included the Atari Jaguar, Sega 32X, Super Nintendo, Sony PlayStation, 3DO, and Sega Saturn, and both the system architectures and Doom engine implementations are described. I was in high school during this era of the great console wars, although I never played Doom on any of them, just the excellent experience of the PC. I had forgotten how different these console architectures were, and some of the design decisions that went into those systems were truly remarkable...and strange. The sections on the Super Nintendo and PlayStation ports were my favorites. The Super Nintendo would have never been able to run Doom on its own, but with the extra power of the SuperFX chip that was used in Star Fox and a few other games, it was able to pull it off reasonably well. The PlayStation port was the most faithful of the ports, and even added some cool new features like colored ambient lighting. Of all of these systems, the PlayStation was exceptionally powerful for making great games. Even though other systems might have looked more powerful on paper, they all had disadvantages and unfortunate design decisions that handicapped them while the PlayStation was so easy to develop for that its potential could consistently be achieved in practice.
I enjoyed this book as much, if not more than the Wolf3D Black Book. From the beautiful full-color pictures to the detailed explanations of technical feature implementations to the well-chosen code listings sprinkled throughout the book, this was an incredibly fun guided tour of a legendary game engine. I devoured this book, and through it all, I wanted to do two things: go back and play through Doom again and re-implement some of those rendering algorithms for myself. I can't think of higher praise for a book, so if you've ever played Doom and want to know how it works, you need to go treat yourself to this book and the Wolfenstein 3D Black Book, too.
The book starts off with forwards by John Carmack and Dave Taylor and a short introduction just to wet your appetite. Then it jumps into the hardware that Doom was designed for in chapter 2. Doom was able to run on an i386, but by 1993 when Doom was being developed, the i486 was becoming affordable and was over 2x faster than the equivalent frequency i386, so that was the new target system. Everything else was improving rapidly as well. Video cards took a big step up in performance with the VESA VL-Bus and tighter component integration on the cards. Sound cards became even more fragmented, unfortunately, but sound quality was improving by leaps and bounds. Networking was also becoming possible by this time with multiple ways to connect PCs for multiplayer co-op and deathmatch play. Finally, compilers had improved to the point where it wasn't necessary to do nearly everything in assembly. The Watcom compiler allowed id Software to code Doom almost entirely in C, freeing the developers to think at a higher level and implement more features more rapidly.
Chapter 3 is entirely new because id Software used an entirely different development environment for Doom. Instead of developing everything on unstable DOS PCs, they took the chance on using expensive NeXT workstations. Even a fairly basic NeXTstation cost $4,995 in 1991, and a NeXTcube ran $12,395! It turned out to be worth it, though, because these workstations were rock-solid and allowed John Carmack and the other developers to make incredible progress instead of constantly fighting with crashing machines and a poor development environment. This chapter did a great job going through the architecture and benefits of the NeXT systems, and how id Software used them to full effect.
The next chapter was about the team and tools, like chapter 3 in the Wolfenstein 3D book. Things had changed dramatically, with the team moving to Dallas, TX and growing to fourteen people by the end of development. The tools were evolving, too, with some of the character sprites and animation done using stop motion capture, and the map editor (DoomED) taking on new features to support the multitude of new capabilities in the game engine. Walls in the game no longer needed to be orthogonal, although they still had to be vertical for rendering to be fast enough. Floors and ceilings could change height to create steps, platforms, and other environmental features. Various kinds of traps and ambushes were also possible now. It's quite amazing how many features were added to idTech 1 when compared to the Wolf3D engine. These new features, especially the non-orthogonal walls and varying heights, required a more efficient data structure for the maps, and the BSP (Binary Space Partitioning) node tree was commandeered for the job.
Nearly half of the book is taken up by chapter 5 on the idTech 1 game engine. This chapter is just a monster of awesome information about the engine. It goes through every detail from the game tic design and use of fixed-point arithmetic to sound propagation and enemy AI. The section on the 3D renderer was especially interesting and detailed. There are great explanations on how the environment was drawn with its additional complexity, texture mapping with perspective correction, sprite clipping and animation, and diminished lighting to give the game its intense horror movie feel. This renderer section in particular was so interesting that it made me want to go implement a bunch of the algorithms myself just to be able to recreate them and see them in action. It looks like it would be immensely satisfying.
The last chapter described in fairly good detail how a number of ports of Doom were done on other game consoles. The console ports included the Atari Jaguar, Sega 32X, Super Nintendo, Sony PlayStation, 3DO, and Sega Saturn, and both the system architectures and Doom engine implementations are described. I was in high school during this era of the great console wars, although I never played Doom on any of them, just the excellent experience of the PC. I had forgotten how different these console architectures were, and some of the design decisions that went into those systems were truly remarkable...and strange. The sections on the Super Nintendo and PlayStation ports were my favorites. The Super Nintendo would have never been able to run Doom on its own, but with the extra power of the SuperFX chip that was used in Star Fox and a few other games, it was able to pull it off reasonably well. The PlayStation port was the most faithful of the ports, and even added some cool new features like colored ambient lighting. Of all of these systems, the PlayStation was exceptionally powerful for making great games. Even though other systems might have looked more powerful on paper, they all had disadvantages and unfortunate design decisions that handicapped them while the PlayStation was so easy to develop for that its potential could consistently be achieved in practice.
I enjoyed this book as much, if not more than the Wolf3D Black Book. From the beautiful full-color pictures to the detailed explanations of technical feature implementations to the well-chosen code listings sprinkled throughout the book, this was an incredibly fun guided tour of a legendary game engine. I devoured this book, and through it all, I wanted to do two things: go back and play through Doom again and re-implement some of those rendering algorithms for myself. I can't think of higher praise for a book, so if you've ever played Doom and want to know how it works, you need to go treat yourself to this book and the Wolfenstein 3D Black Book, too.
Monday, March 23, 2020
CX2691, Joust!
Hello there, thanks for waiting for this episode that features Joust by Atari! It's one of my favorite arcade games and is done pretty well on the 2600 (spoilers), probably because it was in the capable hands of GCC. Next up is Star Wars The Arcade game by Parker Brothers, which has an extremely interesting provenance. If you'd like to contribute to that episode, please send your feedback to 2600gamebygame@gmail.com by end of day October 20th, and I'll put it in the show. Thanks so much for listening!
My Extra Life donation page, thank you!
List of Radio Shack in store catalog games for sale by Kevin Gatland
Joust on KLOV
Kevin Osborn's Bald Wisdom blog
Michael Feinstein's Fein Line blog
Patricia Goodson at Atari Women site
Joust on Random Terrain
Joust on Atari Protos
Joust prototype photos on Atari Compendium
Joust prototype recreated by Thomas Jentzsch on Atari Age
Source code used for Joust prototype reconstruction (Wayback Machine)
My Extra Life donation page, thank you!
List of Radio Shack in store catalog games for sale by Kevin Gatland
Joust on KLOV
Kevin Osborn's Bald Wisdom blog
Michael Feinstein's Fein Line blog
Patricia Goodson at Atari Women site
Joust on Random Terrain
Joust on Atari Protos
Joust prototype photos on Atari Compendium
Joust prototype recreated by Thomas Jentzsch on Atari Age
Source code used for Joust prototype reconstruction (Wayback Machine)
Friday, March 20, 2020
Kriegsspiel: Big Trouble In Little Lardas
Two weeks ago, I participated in a week-long online Kriegsspiel run by Nick Skinner and Richard Clarke of Too Fat Lardies fame. With a total of 13 participants, two umpires and one observer, it was quite an undertaking. Set within a fictional "Imaginations" campaign of the "Lard War II," the players commanded either the forces of the Kingdom of Blue or the Red Republic. As Nick explained in the game:
We confirmed that our organization and equipment was vaguely British. That meant I had three battalions of infantry, each with four companies of four platoons plus a support company. I was also assigned an ambulance company. This seemed a bad omen.
Early in the plans process, I chose to land my initial assault gliders directly on the forts. I figured my best chance was to take the enemy completely by surprise and jump right on top, like at Eben Emael. I had limited resources to get my brigade on the ground. It would take three lifts over the course of two days to get my complete brigade into the battle area. Given my resources at hand, on the initial landings, I would have 20 platoons out of 48 on the ground. Not great odds, I thought. But I had to risk it. Who dares, wins, right?
Plans were set, then changed and changed again as the brigade commanders weighed options and made their cases with the CG and COS for why they should get resources. A feature of Discord that we found handy are voice chat rooms where members can talk via VOIP for planning, rock drills, etc. Blue had two conferences and we found them very beneficial. By the time we had our first conference, we had our plan largely in place and were discussing some of the finer points. The final conference was to make sure everybody had their plans finalized and ask final questions.
The day of battle arrived. As time drew closer for us to climb in our imaginary planes and gliders, top level rooms were locked up and player-to-player communications stopped. We sat at our computers waiting for H-Hour. I received a message that I was on the ground at LZ Baker and could see paras taking heavy fire about a kilometer to the northeast. I could also see and here vicious combat in Fort 2, aka OBJ Grumpy. Then the various communication nets started going live in the form of restricted chat rooms in Discord.
My brigade net room was where I spoke with umpires to get reports from my battalions and request info from them. There was an "on the ground" room for commanders that were up on the division net. Finally there was a division HQ room for those who had established comms with the outside world. Receiving information, parsing it, confirming our own assumptions and then assessing it before putting it up in both the "on the ground" room and Division room was a significant challenge. Luckily, the game was set to last only three hours.
During the game, we were mostly interacting with the umpires and relying on them for information. Issuing orders and requests for information from my imaginary subordinates. I then had to process that info and relay it to my in-game superiors. But only once our in-game communication nets were established! One of the para commanders didn't have comms because his radios got shot up on the DZ. He had to "walk" to where I was and then we could talk to each other and the had to use my "radios" to talk to higher.
Fort 1, OBJ Bashful was taken almost immediately with 30% casualties. Fort 2, OBJ Grumpy, fell only after receiving help from a platoon that had landed on Bashful. Fort 3, OBJ Dopey, was a see-saw battle and I tried mustering forces from Bashful and Grumpy to push it over the edge. Fort 4, OBJ Sleepy, only reported in once their ammo was all expended and the last holdouts were cornered in a bunker and calling "God save the King."
Enemy armored infantry and self-propelled guns had been spotted in the vicinity of Sleepy, so I called for air strikes on the fort with machine gun and cannon only, then follow up with bombs and rockets on the enemy vehicles. Imagine my surprise when I received the report that Sleepy had been destroyed from the air.
In the meantime, I was still trying to get enough forces scratched together to make a difference at Dopey to find it had fallen and was being evacuated, my troops being led away by the enemy. When I asked for clarification if it was Sleepy or Dopey, i was told, "No, it's Dopey, dopey!" Thanks, Rich.
Then the game ended. Luckily, our troops were wholly imaginary and our decisions didn't result in any real casualties. It was an exhilarating, exhausting, madcap, sobering, nervous, mind-blowing experience. I'm planning a podcast with Nick, Richard and the two force commanders. Stay tuned.
I will definitely be looking to do one of these for my J3 group and possibly for my fellow OCS instructors in the near future. Stay tuned for that, as well.
Blue has invaded Red and achieved a breakthrough in the central South. Blue's armies are now pushing Northwards towards the crucial line of the NEMUNAS river and the strategically important city of LARDAS that stands at the confluence of two rivers. If they can push on, they will be threatening the capital city of REDBURG. Red forces though are well organised and aware of the danger. What will happen next?
For the participants, the planning portion was the meat and potatoes of the game. We started out by signing into a website and associated app called Discord. Nick set up a server and we joined it. We were immediately assigned to either the Blue or Red force rooms. From there we received our unit assignments and awaited orders.
The Blue forces, of which I was a member, consisted of an airborne division. We had as players the commanding general, chief of staff, two para brigade commanders, a special reconnaissance squadron commander, a divisional artillery battalion commander and me. I was assigned as the commander of a brigade of glider troops.
The Blue forces, of which I was a member, consisted of an airborne division. We had as players the commanding general, chief of staff, two para brigade commanders, a special reconnaissance squadron commander, a divisional artillery battalion commander and me. I was assigned as the commander of a brigade of glider troops.
 |
| Speaking of gliders. This film and the real events it represents may have provided may have provided some inspiration. |
In the background, Nick was briefing the division commanding general and chief of staff with the division mission. A day or so later, after the CG and COS had some time to digest the mission, we received our unit missions. My mission in particular was to neutralize four forts that protect the southern flank of the city and conduct a follow on mission of clearing the two main routes to the city.
 |
| The small circles are my objectives, the forts. The larger circles are the landing zones for the gliders. The red areas? Anti-glider poles. To quote a certain British officer, "I'm thinking of a phrase that rhymes with 'plucking bell'." Umpire Nick Skinner took an actual 1:50,000 map and appended new place names, grid line identifiers and other information. |
Early in the plans process, I chose to land my initial assault gliders directly on the forts. I figured my best chance was to take the enemy completely by surprise and jump right on top, like at Eben Emael. I had limited resources to get my brigade on the ground. It would take three lifts over the course of two days to get my complete brigade into the battle area. Given my resources at hand, on the initial landings, I would have 20 platoons out of 48 on the ground. Not great odds, I thought. But I had to risk it. Who dares, wins, right?
Plans were set, then changed and changed again as the brigade commanders weighed options and made their cases with the CG and COS for why they should get resources. A feature of Discord that we found handy are voice chat rooms where members can talk via VOIP for planning, rock drills, etc. Blue had two conferences and we found them very beneficial. By the time we had our first conference, we had our plan largely in place and were discussing some of the finer points. The final conference was to make sure everybody had their plans finalized and ask final questions.
 |
| My set up for the day of battle. The cards have each lift marked on them with the units and target LZ. As the battle progressed, I put the markers on the map as needed. We didn't get past the first lift on Day 1, although we planned for four days. |
The day of battle arrived. As time drew closer for us to climb in our imaginary planes and gliders, top level rooms were locked up and player-to-player communications stopped. We sat at our computers waiting for H-Hour. I received a message that I was on the ground at LZ Baker and could see paras taking heavy fire about a kilometer to the northeast. I could also see and here vicious combat in Fort 2, aka OBJ Grumpy. Then the various communication nets started going live in the form of restricted chat rooms in Discord.
My brigade net room was where I spoke with umpires to get reports from my battalions and request info from them. There was an "on the ground" room for commanders that were up on the division net. Finally there was a division HQ room for those who had established comms with the outside world. Receiving information, parsing it, confirming our own assumptions and then assessing it before putting it up in both the "on the ground" room and Division room was a significant challenge. Luckily, the game was set to last only three hours.
During the game, we were mostly interacting with the umpires and relying on them for information. Issuing orders and requests for information from my imaginary subordinates. I then had to process that info and relay it to my in-game superiors. But only once our in-game communication nets were established! One of the para commanders didn't have comms because his radios got shot up on the DZ. He had to "walk" to where I was and then we could talk to each other and the had to use my "radios" to talk to higher.
Fort 1, OBJ Bashful was taken almost immediately with 30% casualties. Fort 2, OBJ Grumpy, fell only after receiving help from a platoon that had landed on Bashful. Fort 3, OBJ Dopey, was a see-saw battle and I tried mustering forces from Bashful and Grumpy to push it over the edge. Fort 4, OBJ Sleepy, only reported in once their ammo was all expended and the last holdouts were cornered in a bunker and calling "God save the King."
Enemy armored infantry and self-propelled guns had been spotted in the vicinity of Sleepy, so I called for air strikes on the fort with machine gun and cannon only, then follow up with bombs and rockets on the enemy vehicles. Imagine my surprise when I received the report that Sleepy had been destroyed from the air.
In the meantime, I was still trying to get enough forces scratched together to make a difference at Dopey to find it had fallen and was being evacuated, my troops being led away by the enemy. When I asked for clarification if it was Sleepy or Dopey, i was told, "No, it's Dopey, dopey!" Thanks, Rich.
Then the game ended. Luckily, our troops were wholly imaginary and our decisions didn't result in any real casualties. It was an exhilarating, exhausting, madcap, sobering, nervous, mind-blowing experience. I'm planning a podcast with Nick, Richard and the two force commanders. Stay tuned.
I will definitely be looking to do one of these for my J3 group and possibly for my fellow OCS instructors in the near future. Stay tuned for that, as well.
Thursday, March 19, 2020
TOP 10 GAMES OF 2019
So, after my massive movie breakdown a few days ago, we finally get to the games. I actually got to sample a larger number of releases this year compared to previous years, though I can't say I've completed a great many of them. Read on to find out my thoughts.
Read more »
Super AiG Screenshots Of The Year: 2019
I usually do my Screenshots of the Year post on New Years Eve, but I didn't see the point in keeping you waiting a few weeks when I'm already done writing about games this year. I'm taking another break, no more games until the end of January I'm afraid.
Taking all these two months breaks has really helped me out though. For one thing it meant I only had half the amount of posts to look through when I was picking out my favourite screenshots. Plus it meant that my short list turned out to be a lot shorter than usual, so I didn't have to agonise over what screens and GIFs made it into the final post. The moral of the story, doing less work is... good?
(If you see a screenshot from a modern system you can probably click it to see the same image in glorious 720p!)
Read on »
DreamHack 2019!!!
DreamHack is the world's largest computer and gaming lifestyle festival. Many game-related companies, professional esports players and fans gather together every year. There are a few esports world's championships or tournaments going on such as SMITE, Rocket League, Counter-Strike, etc. People from all over the world attended the event to play, to meet game developers, pro-gamers, streamers, and other content creators. Our CGDD program always sends faculty and students to run a booth. We demonstrated student game projects, got feedback from professionals and casual players, participated in live interviews. We also gave out marketing materials to promote our program as well as the CCSE. It was an exciting event and everybody was having fun!
Monday, March 16, 2020
Sunday, March 15, 2020
Thursday, March 5, 2020
Storium Theory: Don't Count Yourself Out
Today, I'd like to spend a bit of time on something that I've seen here and there on Storium - cases where a person perhaps goes a bit too Weak with a Weakness play...and takes themselves out of a scene.
It feels right - it feels better than right, doesn't it? Isn't it a great expression of a Weakness to not just suffer a setback, not just suffer some kind of injury, but actually get knocked out or otherwise removed from play for a bit?
Well...it is, and it isn't.
Let's start off with the good: This is, undoubtedly, an example of a player being very willing to show his character suffering for his Weakness. That's great, and that's an attitude that I hope people learn on Storium.
But actually taking yourself out...getting knocked out, getting poisoned to the extent that you can't move, draining yourself so much of energy that you're too exhausted to go on...there are times these things are appropriate, but they need to be used with restraint.
Otherwise, they can mess with the flow of a story.
I've seen it happen: A battle happens, one part of a longer sequence of events all taking place in a short period of time. One player plays a Weakness card and portrays themselves as exhausted, or poisoned, or just plain knocked out cold. Then the battle ends.
Now a few things can happen:
Now...you can make this work. You can. A good narrator who is used to letting the players have heavy story control, especially, can make this work out great. Maybe the group has to stop to allow the player character to recover, but in the process, the problem they're trying to address worsens. Or maybe that's the next challenge: Can they find things to help the player quickly enough that the next challenges don't worsen in the meantime?
But the thing is, even though you can make this work...it just oftentimes ends up more trouble than it is worth to put in this strong of a Weakness play. You can get some great, great character moments and a strong feeling of struggle and danger and fading hope from injury or tiredness that still leaves the character able to go on to new fights.
Sometimes, that can be even stronger. If a character is knocked out, the group might stop to deal with that and then go on once he's recovered. If that happens, the knockout doesn't add as much tension to the story. If a character is injured or tired but still goes on, though, we see that in everything they do for the next few scenes - they're in a bad way, one arm too hurt to hold up their shield, or dragging themselves forward in the battle. It's powerful.
Stopping the story's progress can add some tension if managed properly, but continuing despite your wounds always adds tension.
I'm not saying that you should absolutely avoid major consequences as part of Weakness plays, mind! There are times when it is appropriate, entirely appropriate. Particularly late in the story, particularly when the narrator has told you this is the final battle, you might pull out these powerful Weakness plays. Because there - there - it won't make the story pause or lose momentum. It'll emphasize just how bad things are currently, just how much of a struggle it is for the characters...but there's nothing ahead that the players need to address.
Keep yourselves within the bounds of the challenge, but that is when you should be safer using some of these powerful Weakness concepts.
Before that? Before that, earlier in the story, don't go that far! Go lighter with what goes wrong...but use what goes wrong more. Pick up some kind of injury and carry it with you for the next few scenes, showing your character struggling with it. Show the tiredness that you're feeling, even as you struggle to move on.
Or almost encounter one of those points...and leave things open. Let someone else save you from them. Those can be amazing moments in a tale too.
Weakness plays don't have to be about solid, absolute consequences for your character. They can be about the threat of those consequences. They can be about what might happen if the battle isn't turned around. If you knock your character out, he's knocked out. That's certain. It's done. But if you put in the possibility, you're giving someone else the chance to write. And that's what Storium is all about - working with each other to write interesting or fun stories.
So I suggest pulling back from the solid a bit - work with possibilities. Get hurt and need help. Or, need help to avoid getting hurt. Get tired and struggle. Need someone's shoulder to lean on. Need someone to fight by your side. But unless the story really, truly demands it, don't get taken out entirely. That cuts off possibilities - like bluntly leaving in the middle of a conversation.
And if you're going to take yourself out at all, try not to do it while you still have card plays left for the scene! Hopefully narrators are taking my advice to not use up all their points, but still, it's useful if players keep open the option to play all their cards if needed.
Now, one more note here: I've already said that late in the story you might be fine pulling out heavier, solid consequences as part of a Weakness play if that's your thing. There are points earlier in the story where you might do that too. The narrator might even set them up specifically. If he does...go with it, obviously! If the Weak outcome is "you're all knocked out," well, that's what the outcome is, so do the normal thing with a Weak outcome if you get it and write your spin on that outcome! You get knocked out.
The narrator, obviously, will have planned for that possibility since he put it in the outcomes, right?
Similarly, you might find a situation where it feels like the consequences should be higher - where the outcomes suggest this battle or event is more dangerous than normal, or where you're already portraying your character in a bad way and it just feels like they should have something more solid happen to them on your next Weakness play. And that's fine...I just suggest that you consider talking to the narrator first. Remember, you're writing collaboratively: Check, when you're thinking about having something this major happen to your character, and work with the narrator to figure out how it can happen but still keep the story moving (and not exclude you as a player).
This isn't a solid "don't ever do this." I want to be clear on that. What it is is a caution: Be careful of how and when you do this. When a hero is solidly defeated in battle or exhausts herself in the service of a cause, that can be a great story moment. It's just important to make sure that it's the right time - and that it doesn't derail the story's momentum or leave it short of players in the process.
It feels right - it feels better than right, doesn't it? Isn't it a great expression of a Weakness to not just suffer a setback, not just suffer some kind of injury, but actually get knocked out or otherwise removed from play for a bit?
Well...it is, and it isn't.
Let's start off with the good: This is, undoubtedly, an example of a player being very willing to show his character suffering for his Weakness. That's great, and that's an attitude that I hope people learn on Storium.
But actually taking yourself out...getting knocked out, getting poisoned to the extent that you can't move, draining yourself so much of energy that you're too exhausted to go on...there are times these things are appropriate, but they need to be used with restraint.
Otherwise, they can mess with the flow of a story.
I've seen it happen: A battle happens, one part of a longer sequence of events all taking place in a short period of time. One player plays a Weakness card and portrays themselves as exhausted, or poisoned, or just plain knocked out cold. Then the battle ends.
Now a few things can happen:
- Somehow, the player character recovers very quickly, and keeps on going, so the story can keep moving. That's unsatisfying, as it feels like a major moment is just brushed over and somewhat ignored.
- The narrator puts in a point where the group can rest for a while to make it seem more realistic that the player character takes time to recover from his state...but now the story loses momentum.
- The story goes on, and the player character is put someplace safe to recover in the meantime, which means:
- The player misses out on part of the story, or...
- The narrator has to come up with things that happen around wherever the player character was left that they can work with in their current state.
Now...you can make this work. You can. A good narrator who is used to letting the players have heavy story control, especially, can make this work out great. Maybe the group has to stop to allow the player character to recover, but in the process, the problem they're trying to address worsens. Or maybe that's the next challenge: Can they find things to help the player quickly enough that the next challenges don't worsen in the meantime?
But the thing is, even though you can make this work...it just oftentimes ends up more trouble than it is worth to put in this strong of a Weakness play. You can get some great, great character moments and a strong feeling of struggle and danger and fading hope from injury or tiredness that still leaves the character able to go on to new fights.
Sometimes, that can be even stronger. If a character is knocked out, the group might stop to deal with that and then go on once he's recovered. If that happens, the knockout doesn't add as much tension to the story. If a character is injured or tired but still goes on, though, we see that in everything they do for the next few scenes - they're in a bad way, one arm too hurt to hold up their shield, or dragging themselves forward in the battle. It's powerful.
Stopping the story's progress can add some tension if managed properly, but continuing despite your wounds always adds tension.
I'm not saying that you should absolutely avoid major consequences as part of Weakness plays, mind! There are times when it is appropriate, entirely appropriate. Particularly late in the story, particularly when the narrator has told you this is the final battle, you might pull out these powerful Weakness plays. Because there - there - it won't make the story pause or lose momentum. It'll emphasize just how bad things are currently, just how much of a struggle it is for the characters...but there's nothing ahead that the players need to address.
Keep yourselves within the bounds of the challenge, but that is when you should be safer using some of these powerful Weakness concepts.
Before that? Before that, earlier in the story, don't go that far! Go lighter with what goes wrong...but use what goes wrong more. Pick up some kind of injury and carry it with you for the next few scenes, showing your character struggling with it. Show the tiredness that you're feeling, even as you struggle to move on.
Or almost encounter one of those points...and leave things open. Let someone else save you from them. Those can be amazing moments in a tale too.
Weakness plays don't have to be about solid, absolute consequences for your character. They can be about the threat of those consequences. They can be about what might happen if the battle isn't turned around. If you knock your character out, he's knocked out. That's certain. It's done. But if you put in the possibility, you're giving someone else the chance to write. And that's what Storium is all about - working with each other to write interesting or fun stories.
So I suggest pulling back from the solid a bit - work with possibilities. Get hurt and need help. Or, need help to avoid getting hurt. Get tired and struggle. Need someone's shoulder to lean on. Need someone to fight by your side. But unless the story really, truly demands it, don't get taken out entirely. That cuts off possibilities - like bluntly leaving in the middle of a conversation.
And if you're going to take yourself out at all, try not to do it while you still have card plays left for the scene! Hopefully narrators are taking my advice to not use up all their points, but still, it's useful if players keep open the option to play all their cards if needed.
Now, one more note here: I've already said that late in the story you might be fine pulling out heavier, solid consequences as part of a Weakness play if that's your thing. There are points earlier in the story where you might do that too. The narrator might even set them up specifically. If he does...go with it, obviously! If the Weak outcome is "you're all knocked out," well, that's what the outcome is, so do the normal thing with a Weak outcome if you get it and write your spin on that outcome! You get knocked out.
The narrator, obviously, will have planned for that possibility since he put it in the outcomes, right?
Similarly, you might find a situation where it feels like the consequences should be higher - where the outcomes suggest this battle or event is more dangerous than normal, or where you're already portraying your character in a bad way and it just feels like they should have something more solid happen to them on your next Weakness play. And that's fine...I just suggest that you consider talking to the narrator first. Remember, you're writing collaboratively: Check, when you're thinking about having something this major happen to your character, and work with the narrator to figure out how it can happen but still keep the story moving (and not exclude you as a player).
This isn't a solid "don't ever do this." I want to be clear on that. What it is is a caution: Be careful of how and when you do this. When a hero is solidly defeated in battle or exhausts herself in the service of a cause, that can be a great story moment. It's just important to make sure that it's the right time - and that it doesn't derail the story's momentum or leave it short of players in the process.
River City Girls Review (PS4)
Written by Anthony L. Cuaycong
Title: River City Girls
Developer: WayForward
Publisher: WayForward
Genre: Adventure, Arcade, Fighting, Multiplayer
Price: $29.99
Also Available On: Switch, Steam, XB1
When Nekketsu koha Kunio-kun (roughly translated as "Hot Blood Tough Guy Kunio") made its way to arcades in 1986, not even its biggest fans thought it would have legs. Even as developer Technos Japan had high hopes for it (going so far as to name its principal protagonist after company president Kunio Taki), it seemed to carry a one-off vibe. After all, it was a side-scrolling beat-em-'up that, for the first time, employed four-direction movement and required multiple hits to dispatch enemies. It turned out to be a commercial smash, prompting the release of a port to the Nintendo Family Computer the next year and serving as the kickoff point of an immensely popular franchise.
That the Kunio-kun series is still alive and kicking three decades and three years later despite one industry challenge after another speaks volumes of both the loyalty it has engendered and the quality for which it stands. Now owned by Arc System Works, titles in the intellectual property – which has branched out into seemingly disparate genres, including a variety of sports – boast of outstanding technical and artistic polish, uniquely quirky plots and premises, and engrossing gameplay designed to generate high replay value.
River City Girls is no exception. Featuring a lush color palette and rock music consistent with its retro sensibilities, it turns the hero narrative upside down by having familiar high-school characters Misako and Kyoko do the heavy lifting vice usual leads Kunio and Riki. After learning of their boyfriends' kidnapping, they're spurred to action — from detention, no less, in an obvious nod to their kickass predilections — out of Nekketsu High School, and deep within River City. The result is a rollicking ride that never feels fabricated or forced. To this end cutscenes and interactions laced with humor propel the narrative and help the presentation forge ahead.
Combat mechanics are excellent, in no small measure complemented by easy-to-master and lag-free controls. Difficulty ramps up over time, but never unfairly, and with an eye towards encouraging gamers to collect experience points and currency (earned from encounters) for use by Misako and Kyoko in raising stats, learning new moves, and purchasing battle-purpose gear and equipment. And while River City Girls has a clear end (Save Kunio and Riki!), it's far from linear; side-quests abound, and the attainment of their objectives yields accessories that provide percentage boosts to abilities and skills. It even has collectibles by way of Sabu statues and cats; finding all will net more bonuses, not to mention unlock the real final boss fight.
For all the open-world options, River City Girls isn't overly long. In single-player mode, it should be good for around 10 hours or so. That said, it earns its keep in cooperative mode. As with every other classic beat-em-'up title, it finds itself reaching new heights when enjoyed by two gamers who band together in beating up all the bad guys on screen. The shared experience can likewise smoothen any rough edges produced by grinding, and by the occasionally uneven pace. In any case, it proves well worth its $29.99 price tag. Highly recommended.
THE GOOD:
THE BAD:
When Nekketsu koha Kunio-kun (roughly translated as "Hot Blood Tough Guy Kunio") made its way to arcades in 1986, not even its biggest fans thought it would have legs. Even as developer Technos Japan had high hopes for it (going so far as to name its principal protagonist after company president Kunio Taki), it seemed to carry a one-off vibe. After all, it was a side-scrolling beat-em-'up that, for the first time, employed four-direction movement and required multiple hits to dispatch enemies. It turned out to be a commercial smash, prompting the release of a port to the Nintendo Family Computer the next year and serving as the kickoff point of an immensely popular franchise.
That the Kunio-kun series is still alive and kicking three decades and three years later despite one industry challenge after another speaks volumes of both the loyalty it has engendered and the quality for which it stands. Now owned by Arc System Works, titles in the intellectual property – which has branched out into seemingly disparate genres, including a variety of sports – boast of outstanding technical and artistic polish, uniquely quirky plots and premises, and engrossing gameplay designed to generate high replay value.
River City Girls is no exception. Featuring a lush color palette and rock music consistent with its retro sensibilities, it turns the hero narrative upside down by having familiar high-school characters Misako and Kyoko do the heavy lifting vice usual leads Kunio and Riki. After learning of their boyfriends' kidnapping, they're spurred to action — from detention, no less, in an obvious nod to their kickass predilections — out of Nekketsu High School, and deep within River City. The result is a rollicking ride that never feels fabricated or forced. To this end cutscenes and interactions laced with humor propel the narrative and help the presentation forge ahead.
Combat mechanics are excellent, in no small measure complemented by easy-to-master and lag-free controls. Difficulty ramps up over time, but never unfairly, and with an eye towards encouraging gamers to collect experience points and currency (earned from encounters) for use by Misako and Kyoko in raising stats, learning new moves, and purchasing battle-purpose gear and equipment. And while River City Girls has a clear end (Save Kunio and Riki!), it's far from linear; side-quests abound, and the attainment of their objectives yields accessories that provide percentage boosts to abilities and skills. It even has collectibles by way of Sabu statues and cats; finding all will net more bonuses, not to mention unlock the real final boss fight.
For all the open-world options, River City Girls isn't overly long. In single-player mode, it should be good for around 10 hours or so. That said, it earns its keep in cooperative mode. As with every other classic beat-em-'up title, it finds itself reaching new heights when enjoyed by two gamers who band together in beating up all the bad guys on screen. The shared experience can likewise smoothen any rough edges produced by grinding, and by the occasionally uneven pace. In any case, it proves well worth its $29.99 price tag. Highly recommended.
THE GOOD:
- Outstanding audio-visual presentation reminiscent of classic beat-'em-ups
- Deep and engrossing non-linear gameplay
- Superb cooperative mode
- Solid addition to the Kunio-kun franchise
THE BAD:
- Uneven pace
- Grinding required
- Side-quests can lead to time-consuming backtracking
RATING: 8.5/10
The Final Form Of My Home Made Magnetic Army Transport
I wanted to put out an update to my last post on building a magnetic model transport system for my Convergence.
Just before Captain Con my wife was kind enough to finish making the bag to carry all of the magnetic bins I built. It's frankly huge, but it carries absolutely everything without any issue.
It's huge! Total size is 16" deep, 24" wide, and about 15" tall. In the above picture it's carrying my dice tray, dice, all of my Convergence and a Blacksmiths Guild Ball team, and my sheet pan/tournament tray (sprayed silver).
The bag is semi-rigid, using some foam internally between the fabric to give some stability and padding. My wife did an outstanding job on it.
I got some flak from my Guild Ball friends for how much room I was taking up in the trunk on the drive up, but its awesome. It fits neatly in my own car's trunk and will be used for all my local travel from now on. This is significantly easier than when I had to use an old PC carrying strap to bind all my cases together to carry the CoC around locally.
In case you didn't see the last post, here are what the cases look like populated with my stuff:
Conclusions
If you compare this to an actual product of equivalent size, it's about what you'd get in a Magna Rack 1520 from Battle Foam. The racks plus bag for that is $365 plus shipping. If you add up total materials for my system, I'm likely looking at about $100 max. Of course, I didn't have to pay for any labor in this creation.
On the flip side, I mentioned to my wife that she could probably pull $100 to $150 for a bag like that for other gamers if she tried to make one and she said in no uncertain terms that it flat out isn't worth it for her labor to charge that little. Apparently the bag was a bit of a pain in the ass for her to make. She was happy to make it for me, but no one else has my charm to convince her it's worth making another.
If I wasn't married to an extremely talented quilter (and all around amazing woman) I'd probably would have to had been more careful when picking out my bins to make sure I could arrange them to fit in a piece of luggage I could buy rather than having the bag being fabricated to meet the specs of what bins I purchased.
I'm very happy to have done this, and I intend on magnetizing my other armies to use this system going forward, though I already have a bunch of foam so I'm not as motivated to go ahead with that. Plus I plan on just using Convergence for a while anyway.
Just before Captain Con my wife was kind enough to finish making the bag to carry all of the magnetic bins I built. It's frankly huge, but it carries absolutely everything without any issue.
It's huge! Total size is 16" deep, 24" wide, and about 15" tall. In the above picture it's carrying my dice tray, dice, all of my Convergence and a Blacksmiths Guild Ball team, and my sheet pan/tournament tray (sprayed silver).
The bag is semi-rigid, using some foam internally between the fabric to give some stability and padding. My wife did an outstanding job on it.
I got some flak from my Guild Ball friends for how much room I was taking up in the trunk on the drive up, but its awesome. It fits neatly in my own car's trunk and will be used for all my local travel from now on. This is significantly easier than when I had to use an old PC carrying strap to bind all my cases together to carry the CoC around locally.
In case you didn't see the last post, here are what the cases look like populated with my stuff:
Conclusions
If you compare this to an actual product of equivalent size, it's about what you'd get in a Magna Rack 1520 from Battle Foam. The racks plus bag for that is $365 plus shipping. If you add up total materials for my system, I'm likely looking at about $100 max. Of course, I didn't have to pay for any labor in this creation.
On the flip side, I mentioned to my wife that she could probably pull $100 to $150 for a bag like that for other gamers if she tried to make one and she said in no uncertain terms that it flat out isn't worth it for her labor to charge that little. Apparently the bag was a bit of a pain in the ass for her to make. She was happy to make it for me, but no one else has my charm to convince her it's worth making another.
If I wasn't married to an extremely talented quilter (and all around amazing woman) I'd probably would have to had been more careful when picking out my bins to make sure I could arrange them to fit in a piece of luggage I could buy rather than having the bag being fabricated to meet the specs of what bins I purchased.
I'm very happy to have done this, and I intend on magnetizing my other armies to use this system going forward, though I already have a bunch of foam so I'm not as motivated to go ahead with that. Plus I plan on just using Convergence for a while anyway.
Wednesday, March 4, 2020
Kanto Underground
Just south of Cerulean City lived a kind old man in a secluded homestead offering a Pokémon Daycare service. This kind of small business is a lot more widespread nowadays, but back then it was a bit of a novelty. He allowed any trainer registered within the Indigo League of Kanto to leave one Pokémon in his care for a nominal fee. I had never heard of anything like this at the time, but after our brief conversation, I used Bill's transfer system to bring Charlie out of storage and into the old man's care. At the daycare, he would get lots of exercise and activity and be allowed to play and train with other Pokémon instead of just waiting in storage. It seemed like a really good way to get him some extra training in case anything unspeakable ever happened to Kiwi. The old man assured me that he'd been doing this for a long time now and Charlie was in good hands.
I was attacked by some wild Pidgey on Route 5, but I decided to save my Pokéballs for better options since I had Kiwi and Charlie as members of Team Fox. It didn't seem prudent to waste the resources on a third fighting Pidgey. It was during this time between Cerulean and Vermilion that I was starting to think about the future battles. I had to be careful with upcoming Gym Leaders and at the Indigo Plateau and I had to plan accordingly. After passing on acquiring a new Pidgey on Route 5, I made an effort to avoid more wild encounters in the future unless I was ready to add a potential candidate to my team. The way I was training my Pokémon meant that every new capture had to be strategic going forward. An army of Pidgey weren't going to win me the rest of my battles.
I was pretty oblivious to this at the time, but the region of Kanto was in a bit of upheaval the first time I was there. As I mentioned, I wasn't really aware of Team Rocket much before my unfortunate encounter with them at Mount Moon. I didn't realize what a hold they had on the region. I also didn't realize that things were changing rapidly since their operation at Mount Moon crumbled. For a long time the organization moved in the shadows, acquiring Pokémon and using them for illegal activities without drawing much attention to themselves, but things were now changing since two local trainers had them riled up. I mention it now because typically moving south from Cerulean, you would end up in Saffron City before heading to Vermilion City, but Saffron was under a bit of a lock-down thanks to Team Rocket activities. Police sentries were posted on all sides of the city and were not allowing anyone in or out of the city. They tried to explain the situation to me the best they could, but I really didn't understand the gravity of it and they got impatient trying to explain to me why I needed to get to Vermilion another way.
This other way was an underground passage originally intended to be developed into a subway system to and from Saffron City. It's development had been abandoned due to escalating economic tension between the local government and Team Rocket. It now served as a convenient, although shady, underpass between Cerulean and Vermilion, as well as Lavender Town and Celadon City. You could bypass Saffron City entirely this way. The path was reasonably lit and maintained by local volunteers. Pokémon battles were prohibited and efforts were made to repel Pokémon from infiltrating the path as long as it was needed. Apparently Saffron had been cut off from the world for some time in order for this to have been as well established as it was, but again I was ignorant of the state of affairs in Kanto at that time. I merely enjoyed an uninterupted stroll underground, picking up various shiny objects I happened upon.
I arrived in Vermilion City sometime in the evening. I managed to secure a place to sleep for a few nights and then set out to learn what I could about the local Pokémon scene. I could see the S.S. Anne to the south all lit up like an angry Electrode. Tomorrow I would have to find a way to get into the tournament aboard and hopefully earn my access to that Hidden Machine, but I did have a few other concerns. The gym leader in Vermilion was not a push-over and he favored electric attacks above all else. It earned him his nickname as Lt. Surge. As it stood, my team consisted mostly of flying Pokémon who would easily be burst out of the sky by a well placed thunderbolt. Kiwi, Lucky, Vesper and Shakespear were all going to be huge liabilities in the Vermilion Gym. Arnold had recently evolved on his way south through Route 5 and 6, but I wasn't sure that my powerful Gloom could stand up to the kind of voltage Lt. Surge was known to put out. It seemed clear that Arnold and Rascal Jr. Simply weren't going to be enough to ensure a victory here in Vermilion. If I were going to get a new Pokémon, then the battles aboard the S.S. Anne would be a great training ground for them, so I set out that evening to add one more friend to my roster.
Vermilion City is the busiest port in the Kanto region and naturally surrounded mostly by water. Water-based Pokémon weren't going to stand a chance against Lt. Surge when I went to face him, so I had to look somewhere else. I had overheard that just beyond the city limits was a small rock tunnel the locals called Diglett's Cave, because it had been dug out by a large colony of Diglett and Dugtrio. Though it was a bit unsettling to crawl into their nest, I knew a Diglett or a Dugtrio would be the perfect addition to the team and the perfect counter to Lt. Surge. Their ground affinity would make them immune to any electric attacks Lt. Surge could throw at them. So despite my apprehension and the apparent dangers of crawling into a Diglett tunnel at night, I felt I had no choice.
Current Team:
Attacks in Blue are recently learned.
Bill's Storage: Shakespear (Spearow)
Old Man Daycare: Charlie (Pidgey)
Subscribe to:
Posts (Atom)