Here we go!
Tomorrow I start my 7 day roguelike game for the 2016 event. Why not today? Well, I had things to do. Plus, a travel cold kicked my *butt* last week, and I’m still recovering. So I want the extra day.
This year, I plan to make a generalized Sci-fi roguelike, set in my own Artemis game universe. It makes sense for several reasons; let’s see if my muse will listen to reason. 🙂
Ever play with legos? It’s totally cool, and completely freeform, and you just reach into your bin, pull out some blocks, and start snapping them together. Cool, right?
The legos manufacturer also sells kits, with detailed instructions. Have you ever built one of those kits? I haven’t, but I get that they can be fun.
But imagine that, EVERY time you want to play with your legos, BEFORE you get to the freeform part, you MUST carefully complete a detailed lego model EXACTLY according to the instructions. Only then may you start building what YOU want to build.
Would you still want to play with your legos? Would others?
This is what modern day game development is like.
I’ve been researching ways to set up a C# game development environment for my nephew. The Visual Studio IDE is still the king, being free and very powerful. But the XNA library, which used to be the Windows code you need to draw art and play sounds for games, has been shut down by Microsoft.
SlimDX and SharpDX have sprung up to replace XNA in this space, with an array of higher-level developer libs on top of them.
Any way I go, I MUST load exactly correct sets of files into the exactly proper places on my dev machine, and hook them up with opaque incantations. Then I must also use exact incantations to get these software tools to setup Windows, so that (finally) my code can actually get to the business of making the game I wanted to make in the first place. Legos it ain’t!
Why do we tolerate this? Well, of course, computers and operating systems and video cards are all very complex under the hood, and under the hood is where we program. But nobody likes to get tripped up in (metaphorical) wire bundles, so we organize and compartmentalize our code. We programmers recognize the utility of keeping things simple and clean.
But I also think that programming can be a priesthood, and having to know and correctly use bizarre incantations is how a priesthood maintains its exclusive status. I’ve seen it many times. “If you can’t handle it, you don’t belong here.” It’s toxic and exclusionary.
But I guess I’m frustrated because I feel like a dinosaur. It’s only been a few years since I explored new dev tools and libs. But there’s so much that’s new, and different ways of doing things (that I don’t like)
Retained-mode, message-passing architectures are just as popular as ever (Windows, Unity, etc), though I find them gross. WYSIWYG dev tools (Game Maker) are just as popular, though I find them limiting. And complex WYSIWYG GUI design tools (Flash, Window Builder, Glade) are very useful in large and distributed teams, but unwanted complexity for my lone-wolf style.
Whatever happened to turn the computer on, and start typing code? Okay, I know that hasn’t happened since the C-64/Apple 2 days. /old man rant
But even the Raspberry Pi, which was billed as a return to those days, requires the same complicated setup as every other modern dev environment.
Microsoft has actually worked hard (for years) to make life as easy as possible, FOR enterprise coders. Game coders are expected to join the priesthood.
I’m sure I can put together a dev environment for my nephew. And I’m sure I can lead him though the minefield of incantations necessary to get him started. I just wish there were a better way.
For some reason, my old blog simply failed a couple months ago. Now that it’s a new year, I set to fixing it.
It was a Geeklog CMS, and I wanted to move to WordPress, for familiarity. And it didn’t even work; I had to export the raw DB of old stories.
And then I was left with an Excel spreadsheet of cells that contained posts I’d made going back to 2007, and no clear way to bulk-add them to my new blog.
So after several false starts, I found
which loaded my data and added it to the story DB of my new blog, AFTER much data massaging.
But that’s done, and the data is (almost all) brought over! Yay!
Here’s a fun, in-depth article that assembles and organizes all of the backstory for Destiny, the FPS game from Bungie.
I played for a few days at the beginning, and stopped when I felt I’d done enough shooting aliens.
But what fascinates me about this is…the varied responses to the article. Some love what gameinformer wrote, some bash Bungie, and some ask Why?
I hate to be contradictory, but nothing is going on with Destiny’s story. There’s a hell of a lot too much going on with Destiny’s BACKstory, but I don’t give a crap about that. I don’t want to learn extensively about backstory unless (1). it’s an integral part of the plot of the current game, (2). it serves a purpose gameplay-wise, or (3). it is part of a larger franchise and harkens back to other entries in said franchise. Destiny’s backstory doesn’t meet any of these. The backstory doesn’t really affect what you are doing or why you are doing it (there are bad guys and you have to kill them), it doesn’t serve any purpose in the gameplay (collecting dead ghosts doesn’t give you glimmer or any other consumables, and the backstory doesn’t give you gameplay/combat tips), and Destiny is the first entry in it’s series. It isn’t part of any larger universe, and to be honest, I’m not invested in the at all in the universe. Maybe two or three entries down the line I will be, but stuffing all this backstory down gamers’ throats at launch – without any meaningful story in the present – just seems pointless. First let me save humanity, discover more on my own about the mysterious Nine, and scan a bunch of computers, and then I might show a little more interest in the pathological psychosis of the Vex and the former majesty of the Fallen. At least, if you’re going to shove all this backstory in my face, at least let me discover and study it in game, instead of off of some Destiny nerd’s blog.
This guy is wrong, in several ways (and he’s got issues about things being shoved in his face/down his throat). But his opinion isn’t unusual, and it’s enlightening.
I’ve talked for a while about the difference between narrative (the story the game tells you, while you cooperate as protagonist), and so-called ludo-narrative (the story you tell through your actions and choices). But these players point out that the narrative itself comes in at least two parts; the "back-story", describing why things exist as they do, and the narrative I just described.
I’m starting to wonder how many meaningful parts there can be to a game story…
Metafilter has a set of links to a subject I’d known something about, but not all. Go read and check out the last video; I’ll wait.
The Bugatti 100p was really just a plane, but it was beautiful, elegant, and ahead of its time. And the man who designed it has a reputation that succeeds him to this day.
So what is the…
videogame version of the Bugatti 100p?
It would be just a videogame, but beautiful, elegant, and ahead of its time. Some would say (very arguably) that Super Metroid (SNES) fits that description. Some would say M.U.L.E. I’m sure there are other candidates out there, too.
And if one makes such a videogame, will that ensure one a reputation that succeeds him?
There is a job in the videogame industry. A very important job, that has been critical to some of the greatest games in videogame history. But it has no name. It gets no repect. People don’t even imagine it exists.
I was listening to…a podcast by Soren Johnson. His guest was Bruce Shelley, a videogame veteran who "is best known for his work on Railroad Tycoon, Civilization, and the Age of Empires series".
In the podcast, Mr. Shelley details his working relationship to Sid Meier, during the time Sid was making Railroad Tycoon, Covert Action, and Civilization. Sid would offer him new builds of game prototypes almost every day; Bruce would play them and provide detailed feedback. Bruce came from a deep background in historical wargaming, but was also a natural, seat-of-the-pants gamer. His idea of a good game was "whatever I enjoy playing".
While listening, I was reminded of another podcast I’d heard a year ago.
The interview was with a member of an indie dev team. The member discussed how he played the various builds of the game obsessively, and how he provided detailed, timely analysis to the other members of the team. At the time, I didn’t understand quite what I was listening to, but I knew I wanted someone like that to work with me.
I am also dimly aware of other dev teams that had such members, and I bet you know of some too.
So I’ve had a revelation.
What Bruce Shelley (and the indie game member) were doing was filling a critical role that is not filled by testers, designers, or producers. The job they did is different, and needs a name.
I will call this job description a "Bruce".
A Bruce’s job is to test and provide feedback in a very tight loop, throughout the dev cycle. While a Bruce will find bugs to fix, her main job is to help the designer find the fun.
A "Bruce" needs a good grounding in games and videogames, an eagerness to educate herself about the subject matter, a willingness to play the HELL out of unfinished games, and the good communication skills to quickly and concisely tell the rest of the team what they think. Like any other team member, a Bruce is a full-time job.
A Bruce needs that near-OCD ability to play and replay a game long past the point that others grow tired of the game and move on. A Bruce WANTS to replay an entire game just to see how a small feature works.
A Bruce is not a programmer, but the designer she supports often is. A Bruce doesn’t need to be paired with a designer/programmer, though. The really critical aspect of a Bruce is iterative design. A Bruce has nothing to do, if you’re not doing iterative game design. If you’ve already got a clear idea of your perfect game, you need an AP, not a Bruce. But good game design IS iterative, so if you want to design a game from scratch, a Bruce is very useful.
Why is a Bruce not just a designer, tester, or producer?
In AAA development, testers aren’t used for design. Hired at the end of the development cycle, paid little, working long hours, they’re told to find bugs, not offer suggestions. After the testing cycle is done, they are usually fired.
In indie development, testers are simply fans. As a group, they can provide lots of feedback, some of it great, but not in a focused or timely way.
Producers are also different from a Bruce. In my time in the AAA industry, I found that producers were responsible for getting the project done on time and on budget. They want the game to be good, but that’s not their first job. Bruce Shelley himself was an Assistant Producer at MicroProse before he became Meier’s "Bruce". He made maps, did research, produced game data, and kept his head down.
Finally, Bruces aren’t designers. I say that because a Bruce’s job is to SUPPORT the designer, but also because I’ve worked with too many designers who didn’t do the job of a "Bruce".
I believe you can find examples of testers , designers, or APs doing the work of a Bruce, which only reinforces my point; the Bruce is a unique job that needs respect and a job description.
I’ve always wanted a Bruce, but didn’t exactly know what it was or how to get one. I envied the game devs who had gathered a small and effective team around them, and recognized that (as a videogame developer) needed art, sound, and bizdev, BUT I also needed the support of a Bruce.
If you have a Bruce on your team, shower them with love and respect, because they deserve it.
I’ve been working on a new game. Here’s a DL link to the Windows version.
Inspired by a certain dinosaur movie, this game…
lets you create a theme park using monsters you capture on an island.
Right now it’s all programmer-art. I CAN make it pretty; I’m negotiating with artists right now for the work. But I’ve been building the functionality, and trying to find the fun.
I THINK I’ve begun to find it, but I could use your help and feedback. PLEASE let me know what you think.http://www.eochu.com/dl…
Problem: How do I move objects around in a maze like Pac-man?
A maze game (like pac-man) uses a maze. This maze looks like a 2D array of open and closed squares (and it is), but a better way to think about it is as a GRAPH. This isn’t a graph like the 2D plot of data:
In pure math terms, a directed graph is “a set of points connected by lines”. That simple. Just some points, and some lines that connect some of them. If you imagine the points in a pac-man maze are in the center of each square, then there are invisible lines connecting the points through the open hallways.
So moving objects around in a maze becomes “traversing the graph”, moving from point to point along a connecting line.
When your objects live in a maze (or other type of GRAPH), they really have two positions; one in “grid-space” and one in “screen-space”. screen-space is in pixels, of course. Grid-space corresponds to the blocks of the maze you have. You’ll have to keep these two coordinate systems straight, in your head and in the code, or you’ll get very confused.
It can help to make two functions, ScreenToGrid() and GridToScreen(), to keep the translations straight. If your game supports scrolling and zooming of the display, these functions become critical.
Each object should have x and y variables for where they are (this should not be a surprise) . But in this case, those variables should be for the POINT the object is moving to. There should also be x and y for the point the object is leaving, and there should be a float value for the percentage of the distance the object has traveled between the two points. Something like:
int nextX, nextY;
int prevX, prevY;
float percentMoved = 0;
Moving between the points is as simple as incrementing the percent variable:
percentMoved = percentMoved + speed;
if (percentMoved >= 1.0)
percentMoved = percentMoved - 1.0;
prevX = nextX;
prevY = nextY;
// make the decision about what point to move to here
// put the results of that decision into nextX and nextY
Now, how do we know exactly WHERE the object is? We can calculate that with:
float drawX, drawY;
drawX = (percentMoved) * nextX + (1-percentMoved) * prevX;
drawX = drawX * PIXELS_PER_GRID_SQUARE;
drawY = (percentMoved) * nextY + (1-percentMoved) * prevY;
drawY = drawY * PIXELS_PER_GRID_SQUARE;
Notice how (in the above pseudo-code) drawX is initially still in “grid-space”. We multiply by PIXELS_PER_GRID_SQUARE in order to translate the variable into screen-space.
If you’re making a game even remotely like pac-man, you should use this algorithm. If you’re making a game with halls and corridors (in 2D or 3D), and you need enemies to move through them, you can make a “pathmap” from points connected by lines. This pathmap would be invisible to the player, but it’s a directed graph, which means objects can move along it using this algorithm.