Idea: game about running a pyramid scheme.
Bedroom game development.
Idea: game about running a pyramid scheme.
“The Halloween Spirit”
You play as a magical pumpkin.
You land on innocent bystander’s head to take control of their body, so you can infiltrate a halloween party.Everyone at the party is wearing a monster mask, and has a different preferences regarding body types.
Depending on the body you have, you get different hints. Like, if you’re using the nerd’s body, the fox-mask lady will tell you she’d rather go with a beefy guy.
So you come back with the beefy guy, the chicken-mask dude will tell you that he prefers slender bros. Etc, etc~The goal is to have sex with as many people as possible at the party before midnight.
“The Halloween Spirit”.
Anonymous: Hey there! Your blog is awesome, and it's really interesting for a novice pixel artist to see some of the techniques involved in both animated and still work. I don't suppose you could look at Earthbound/Mother 3 at some point? Both games have funky background work in battles, and the sprite work for both games is phenomenal, I feel.
Oh boy, someone asked me about the Mother series!
Firstly, thanks for your interest in the blog! Regarding the backgrounds in the Mother series, what would you like to know about them specifically? I can probably cover this in more depth down the line, but for now, I’ll try and do a brief explanation. Battle backgrounds are comprised of two layers, each containing either a static or animated image. A lot of the time, both layers use the same image (below is the image from the final battle that’s displayed on layer BG2 and BG3).
Using fairly basic programming, those images are stretched and skewed at raster lines. That programmed bending can also be done in a variety of different ways to create a heaping pile of effects! Even though a lot of battles use the same two images for their backgrounds, the bending is done differently on each layer to create those psychedelic patterns.
Overkill and I actually tested that same effect on the Game Boy hardware, granted we only had one layer and no fancy alpha effects to work with, I think it turned out pretty well given the system!
Finally, regarding the sprite work, I’ve already covered overworld stuff on Pixel Digest here, likewise, the monster art has been posted across the web many times. Even I ripped the Mother 3 enemies at one point years ago. Thanks for the question! What was your favourite section in the Mother series?
NOTE: This was originally posted by Greg Costikyan over at Gamesutra. It was taken down for excessive profanity. All I haveto say is “fuck that.” This needs to be read.
Gamersgate: STFU by Greg Costikyan
“As a male voice in the game industry,” writes my daughter Vicky, “you should speak out…
Valkyrie Profile
Game artwork and Concept art of the Valkyries
Artist: Yoh Yoshinari
(via rpgdan)
Slowly but surely, I’ve made significant progress on the phone navigation prototype for Let’s Suicide!. Tablets should be largely the same, but I will have to take the larger screen into account. All I have left is to add in the player character and finish the tap navigation I have planned. I’m trying not to get too detailed here.
I hacked together a quick test map using tiles from Open Game Art. Specifically, these. Which I severely butchered.
Now, the point of this whole waste of time is to…
The actual game will be written in C++11 using the Cocos2D engine since, despite my love for Apple, I want to target more than just iOS/OS X. Still, I will probably continue to prototype ideas in Swift and Sprite Kit. It was so much fun to make this.
Now I have to continue researching suicide cults and brainwashing and new religious movements and indoctrination, etc. At some point, I should probably explain to everyone what the game is about…
I finally played The Last of Us as the “remastered” PS4 edition. Here are some random thoughts…
Music by Gustavo Santaolalla, fuck yes! I highly recommend you download the soundtrack.
I’ve decided that if you can call your game cinematic, you’ve probably failed as a game designer. Maybe the fact that “cinematic game” is an oxymoron should be a clue that something’s wrong with trying to make a game more like a movie. Maybe there’s a difference between making a cinematic game and making a game feel cinematic? That’s a possible subtlety worth exploring.
I don’t know why this was considered the greatest game of 2013. I would have cast my ballot for Papers, Please. One can argue this isn’t a bad game per se, it’s just not as good as everyone said it was.
2013 will go down as the year all the men in the game industry began realizing that women were people and not just objects. Probably this has something to do with their newborn daughters. Probably. I have yet to decide which of these three tropes Sarah falls into, if any.
It was nice to have characters who were people of color. (Marlene, the leader of the Fireflies, is a black woman!) Too bad they all end up dead… The character Bill, however, is gay and managed to survive. He’s also white, though. Oh wait, his lover died. One step forward, several steps back?
I loved seeing a post-apocalyptic game that wasn’t mud brown and boring grey. Everywhere you go, you see nature reclaiming the world. It’s like you’re walking around Pripyat. The game world is a beautiful ruin.
I didn’t realize it, but I’ve read online that player health does, in fact, regenerate if you wait long enough. The health bar is segmented, so only the current segment will regenerate, which is better than regenerating the whole thing. Honestly, I don’t think regenerating health was needed at all. The pace of combat means that you can’t wait long enough for it to regenerate anyway. Furthermore, I believe the regenerating health mechanic is symptomatic of broken gameplay, an idea I’ll expound on someday.
I like that the game doesn’t stop to craft or use supplies, or change weapons. This helps add pressure on the player during combat segments, helps build tension. I first saw this in Dead Space but I haven’t played enough mainstream games to see if it’s been adopted at large (not that it needs to be).
Without spoiling the story for others, the end of the winter segment is perhaps the highlight of the game. During that final battle, it took me a while to realize: he’s hunting me. (Ha! And it takes place in a steakhouse!) That was probably the one point in the game where story and gameplay intertwine the most intimately. Is it any coincidence it’s also the best part of the game and most people’s favorite part?
Although I felt tension in combat, I never felt any danger. I knew if I died, I’d just go and start again. When the player feels dying is an inconvenience, perhaps it’s time to revisit your design and make some changes.
This is perhaps my problem with the game as a whole. Shoot-y bits sandwiched between story bits and never the two shall meet. And there’s nothing new here. No new ideas, no new actions. I’ve done stealth, I’ve done third person shooters, I’ve done “survival horror”… Can we get something different? Maybe something not involving weapons at all?
My overall reaction is perhaps slightly to the positive side of neutral.
A Grim Fandango poster that I worked to death (no pun intended…okay, it was kinda intended, whatever). Had to abandon this one because no matter what I did it just never worked how I wanted it to. I think the initial comp had promise but it all just fell flat after that. C’est la vie.
Maybe one day I’ll revisit this idea. The “sprouted” skulls are pretty cool at least. That’s something.
(Source: idrawnintendo)
Roam The Pixelated Forests Of The Deer God, Now On Kickstarter
Been thinking about Skull Kid and Majora’s Mask. The more I think about it, the more I realize what a wonderful game it really is in context of the series. It’s a game about alienation, loneliness and the importance of friendship, and in its own strange way it just may be the saddest and most personal Zelda game.
(Source: idrawnintendo)
More prototyping…
I’ve got the basic tool UI nearly complete. Now I have to start on actual battle logic. Which means designing the mechanics… :)
Work in progress…
I’ve decided to set a long term goal for myself and write the engine I described in my last post. It’s more or less going to be a personal project to teach myself. I’d like to open source it at some point, but I won’t be ready to do that for some while…
So I began writing the platform abstraction layer. The goal is that it should shield the engine from any dependencies on the target platform by exposing a platform-agnostic set of interfaces. I chose to write in C for compatibility with whatever language I decide to implement the engine in (I’m leaning toward D, if you’re wondering).
Already this required going out of my way a bit…
It’s been ages since I’ve done anything in plain ol’ C and I’ve forgotten how austerely minimal the language is. There’s a zen to C, but you have to make sure not to hurt yourself while using it, just like a woodworker using a table saw.
Using the standard library, I’ve decided to roll my own strings, assertions, and logging.
The assertions and logging are nothing to write home about; they’re just there to make the output pretty.
My strings are an abstract data type with a built-in length. They’re allocated for you via constructor functions. You never get to touch the char * directly, to avoid doing anything funny with memory. I should note that I don’t want to implement a complete string type, I just want to ensure sanity for whatever uses them.
Currently, I’m wondering how to handle errors. I’d prefer to handle them internally as much as possible, but I’m relying on system interfaces where something can go wrong. I don’t yet have much to say on this subject. I’m hoping it will reveal itself to me in time.
I’m also trying to decide on a coding style. I’ve largely nailed the naming convention, but I’m still trying to decide how to signal success/failure and pass along output from a function. I should just fall in line with standard library functions.
I’ve been thinking about my ideal game engine recently. In an attempt to define it, I’ve come up with some notes for what I think it should be.
It’s Basically Just a Framework
The engine contains no gameplay logic. It mainly wraps general engine components together in a modular API.
Games are written via scripts executed in the script subsystem, or in a language like C by using the API directly.
It Eliminates Duplicate Effort
If you write a piece of code once, it should work across all platforms. If you create an art asset, it should be scaled to the target platform, as appropriate, for you. The engine itself should provide common functionality “for free”, to avoid both writing boilerplate code and reinventing the wheel on each project.
It Deploys to Many Platforms
My ideal game engine will target all major consoles, desktops/laptops, phones/tablets, and browsers. It should contain a platform abstraction layer that would enable to you target any platform without changing the codebase.
Support for new platforms can be added by writing an appropriate extension to the abstraction layer.
Deploying to browsers deserves a special mention. Ideally, I’d prefer to not require a custom browser plug-in as Unity does. That would require cross-compiling the original code to JavaScript using Emscripten.
The Same Assets Can Be Used across All Platforms
The tools included with the engine will enable you to build scalable assets that degrade gracefully depending on the performance of the target platform. This is all done transparently at build time, “baking” a copy of the assets at the appropriate optimization level for each specific platform target.
Note that this wouldn’t be limited to routine things such as changing the resolution of textures. Via the editor, you can change how content will degrade based on the performance of the system the game is running on – for example, reducing enemies to ease the AI requirements on a slower processor.
It’s Not Written in C++
I can’t say I hate C++, but it is baroque as fuck. Interfaces would be coded in C regardless of the language, but I’d consider implementing internals in C, Objective-C, C#, or even D, as opposed to C++.
It’s Fast
This goes without saying, but the engine API should be heavily optimized for performance.
Some might say this conflicts with the no C++ rule above. Truth is, I’m willing to trade some performance for developer productivity. But I wouldn’t make such a judgement without measuring the performance of each implementation to begin with.
It’s Energy Efficient
This might seem like pulling in opposite directions, but thoughtful, empathetic software needs to cater to the user’s needs. This means respecting the battery life of players playing your game on their phones, tables, and laptops.
It’s Massively Concurrent and Parallel
The engine should allow for massive concurrency to take advantage of multicore processors – and even GPGPU technology for parallelization. It goes without saying that the engine needs to be designed in such a way as to minimize synchronization between threads, otherwise this point is rendered moot.
Most Code Will Be Written in a High Level Language
Ruby, Perl, Python, Lua, JavaScript, C#, Lisp, C/C++/Objective-C, D, etc. The engine toolchain includes LLVM which can compile code JIT during development (see further below) and compile to a target’s machine code during deployment (see further above).
It Uses Native Platform APIs
I hate apps that use some sort of third-party abstraction layer that doesn’t integrate well with the target platforms (Qt, Java Swing, etc.). They never feel or behave quite right, which is something users do notice.
As part of the platform abstraction layer, the engine will use native platform APIs.
It Supports Both 2D and 3D Games
2D would be treated as a specialized application of 3D. You can even mix the two freely.
Development Can Take Place on OS X and Linux
Self-explanatory. Development on Windows is supported, but it’s not the only way – no platform is treated as a second-class citizen.
Changes to Assets Are Reflected Immediately
During development, any change you make to an asset (code, model, texture, sound, etc.) should be immediately reflected in the running project. The goal here is to reduce turnaround time when experimenting with changes.
The Engine Includes a Complete Toolchain
LLVM is included to compile scripting languages, and to compile the engine itself when targeting browsers (see far above). A custom level editor is included that supports both 2D and 3D. There is a tool for producing 2D animated content, whether pixel-based or node-based. The engine can read common asset file formats. Finally, exporters are included for different 3D content creation packages.
The engine is split into three layers…
In an attempt to increase modularity, each component should expose a well-defined interface via a protocol so that individual components can be swapped out at will.
Furthermore, each component in the engine adheres to the MVC design pattern, and the engine provides prebuilt models, views, and controllers out of the box. The engine simultaneously adheres to the entity-component design pattern, allowing you to attach different controllers to an entity to customize behavior.
As an example, imagine loading a 3D model of a player character in a hypothetical mesh model. Attach this to an entity model, then attach a custom input controller component to respond to player input, an animation controller component to animate the mesh, a physics controller component to handle collision, and a render view to display it on screen.
The entity model, mesh model, physics controller, animation controller, and render view are part of the engine; they are prewritten components that you can use as is. The only thing you need to write is the input controller, and even that would be a mere subclass of something the engine provides.