Becoming a game developer in the most roundabout way possible
A new player sprite has been introduced, as well as an older friend: the explosion animation from the original Alcheminer. Things are looking up.
Soon will be proper inventory, rune-based construction/block placement, but sooner comes the implementation of this laser sprite. Ksshunnuuun. Hiiiiiiisoooooohhhh.
One long night of work got us to the point where we were using the old textures produced by Ms. Ramsay to visualize the map generation, as well as test the Krypton lighting engine and realize it wasn’t for us. Instead, we’re using the lighting implementation programmed by Fun Hazard (http://www.funhazard.com/xna-resources.html), whose own implementation originated from the work of Catalin Zima (http://www.catalinzima.com/samples/other-samples/shader-based-dynamic-2d-smooth-shadows/).
There are still many kinks to work out, such as the pixelation. However, we’re just happy that this worked out. The adaption can be attributed to Dusty. I’d link to him if I could.
At the moment, I’m working on an experimental dynamic soundtrack and effects system that I hope to use to build tension, induce fear, and reward exploration. Possible situations could include wind and dripping in large caverns, distant seismic activity, and other environmental effects.
Also, Youtube gave me this warning. Screw you, Youtube, it’s a work in progress.
Rightman is strenuous. The future is uncertain. Therefore, Dusty and I are moving back to Alcheminer.
Alcheminer’s original version made heavy use of the Farseer physics engine, thereby limiting the ability to create large, potentially even infinite, worlds. The CPU strain would simply be too much. Besides this, Farseer isn’t multithreaded, leaving little opportunity for scaling along with the current direction of hardware development.
For this alternate recreation, we’re removing the physics engine, and instead using http://libnoisedotnet.codeplex.com/. In lieu of novel but ultimately insubstantial physics-heavy gameplay, we hope to create infinite worlds, both horizontally and vertically. This presents some interesting concepts.
In the case of Minecraft, exploration of the world presents many interesting discoveries. Mountains, valleys, lakes, rivers, oceans, caverns, ravines, ruins, et cetera. However, in a 2D world, such aspects do not inspire such awe and wonder. The world is less grounded in reality. How do you create a sense of exploration and discovery?
Sound is a big one. Unique environmental songs, depending on their rarity, can inspire a definite sense of wonder. Unfortunately, many players of mining/exploration games turn off the soundtrack in favor of their own music, myself included. My apologies to C418, but the music is simply too sparse. Maybe by constantly offering new soundtrack elements, the player will be more tempted to listen to the music and sound more closely?
Creating structures in the background could be fun. A massive underground temple in a parallax plane could have a portal that leads to a sort of a subdomain inside of it. Cables, tubes and wires would offer a definite change of pace from stone and ore. Perhaps an abandoned 1940s nuclear-family household hundreds of meters under the surface of the planet?
For the time being, this is where we stand.
The Rightman AI is beginning to be scraped together. At the moment, the bots assemble themselves a map of all the corners of the tops of blocks, and their jumping logic is decided by their proximity to said corners. Their movement is strictly directly towards the player.
There are still some serious kinks to work out.
Fortunately, I have no idea what I am doing when it comes to AI programming, meaning this should be a vast learning experience.
I decided, early this afternoon, to do a little experiment. I was discussing game development with cool people on the internet, and we came to the conclusion that the right set of simple rules can create a complex and interesting game. Thus, I created a tiny dynamic gravity simulation. It’s horrendously broken, but that isn’t the point. The point is the nature of the brokenness. Observe the simulation in it’s natural state:
Now, after enabling Continuous Collision Detection:
They behave distinctly, though not in any logical way. The question I am posed with: why does CCD have an effect like this?
In a furious whirlwind of learning, I magically taught myself, via numerous forum discussions and in-depth blog posts, the basics of HLSL. The acronym stands for High Level Shader Language, and is used in conjunction with XNA to produce cool shader effects.
There were two points that were excruciatingly difficult to figure out:
The variable to be set is determined in the square brackets via a string, and the actual value passed in is the input of SetValue(). SetValue has 18 different overloads, 10 of which are bools, floats, ints, matrixes, quaternions, strings, textures, vector2s, vector3s and vector4s. The other 8 are matrixes of everything except strings and textures.
My current plan is to, with the help of Dusty (my co-dev), draw the actual image of the screen as a Vector2, and send that to the shader after everything else. That way, the goons, bullets, and other effects can be distorted in a similar manner.
After quite a bit of control tuning , I’ve recorded my first RIGHTMAN video.
If you look closely, on some of the points at which I run into the wall, I drift a bit away from it. This is due to the fact that the air control is still active for the frame that I’m colliding with the wall, causing me to move far enough away from the wall to not be able to wall jump. It only happens when I’m holding the movement direction opposite my own. You can see several successful wall jumps, but those happen because I’m either holding the same direction that I’m moving, or holding no controls at all.
I haven’t managed to come close to a solution yet. I suspect it’s some sort of issue with Farseer.
Update: Fixed! When the player is close to a wall, it applies a slight force to keep them attached to it. This resolves the issue entirely.
Two cool things: I’ve implemented a new bomb type, and there’s a (horizontally) directional Touhou-style hit sound. Unfortunately, it’s inaudible in the recording, but it’ll be subtly present in any actual release.
The best way to hear the sound is to use the new Fever bomb, which fires 666 bullets at surrounding goons. Unfortunately, there’s some sort of malfunction in the aiming of the bullets, so as you use it more, the bullets become less and less accurate.
The hit sound is actually the very first sound from the song “button a button b” by Livetune (under the pseudonym RE:NDZ), but with most of the highs cut out and the whole thing dropped a couple octaves. I’m pretty pleased with the sound.
The three components of a Bullet Hell Shooter have been assembled. The last piece was Hell.
Now that bullet patterns are interesting, I can start working on balance (I may have eaten a few bullets in the video, but I assure you instadeath purists that it’s purely for testing purposes).
The bots used to only produce good patterns in the first few thousand ticks after spawning. Now that some move constantly, the pattern never ceases to behave in an interesting and dynamic manner. The first bullet of the spreading shots is based on which X-half the bot is located, for maximum pattern attractiveness.
The plan is to include a score bonus for making it through a stage without firing a shot. Maximum masochism!
After much time without Kelvin, my laptop, it has returned to me, and as such my code as well. It is backed up properly now, at a remote location. In fact, it’s set up at a Git repository that sits in my friend and co-dev’s house.
Uninteresting, however, compared to the progress!
The greatest feature, I would say, is actual hit detection. Simple, I am aware, but I was incredibly reluctant to implement it after my experiences with non-Farseer collision detection in the past. This time, it was not a problem.
Pausing is in, being as simple as ceasing to call the Update method in Level1′s class and drawing a transparent overlay.
Also, you might also notice the bar on the left. That will inevitably be an experience bar, hopefully with a better graphic.
Next up is the pause menu and upgrades, and I may well write a text file parser that will spawn enemies based on the contents of the text file. It’s good to be back.