Small Pixeldust update + Gameplay ideas?

Built a basic particle engine. So far, so good.

Instead of creating each particle individually by reading from a save file, the particle engine has built in methods for creating particle effects. All you need to do is fill parameters for, say, texture, color, gravity, position, rate, etc. I'll still be creating files to store the parameters, but this way, I'll be able to create a simple particle animation easily!

Another thing. Even though this appears on a 3d background, the particles do no depth-reading and are drawn on a 2d plane. Which is just what I want, because otherwise you wouldn't see particles below a target's feet. I had planned to create battle sequences "Paper Mario" style, where everyone is lined up on this single plane (although, even Paper Mario had their fighters spaced out a little). So the way the particles are drawn is no problem anyhow.



I also started thinking about how my gameplay for these battle sequences should be. I'm thinking, "away with all these fancy button presses", and focus on strategy. But how will the player be able to strategize?

When I think about strategizing, I'm reminded of the game "Persona 3". Once, I got into a battle and on the first round, all of my party members are dead, except for me, I have only one HP left. I decided not to run away, since that has a chance of failing. Persona 3 had this mechanic where if you hit the enemy with an element that it is weak against, it is stunned and you get an extra turn. Let's call this the "once more" mechanic. Now all of the enemies were weak against lighting, but I only had an attack that hits one enemy with lightning. Luckily, the "once more" mechanic can be repeated. So my battle went:

Initiate
Everyone dies/ I have 1 HP
Hit enemy 1 with thunder
ONCE MORE
Hit enemy 2 with thunder
ONCE MORE
Hit enemy 3 with thunder
ONCE MORE
My enemies aren't dead yet. Finish with a weaker non-elemental attack that hits all
Battle end.
POINTS!!!

Now, I don't want to make  battle sequences exactly like this for my game. But what I liked about Persona 3's battles was that I was able to get myself out of a sticky situation fast with whatever I had. Another thing I liked about this game was that status effects and buffs (poison, attack up, etc.) actually had a really good effect on battle compared to other games. Did Persona 3 have fancy attack sequences? No. Battles were simple and to the point. I think the fanciest attack sequences got in that game were when all enemies were stunned and your entire party rushed the enemies in an "all-out attack".


So... strategy. How will players win the battles? In how many ways can the player win the battle? If Plan A doesn't work, how easy is it to fall to plan B? Just how useful are the spells? Or the system altogether? Can the player take advantage of certain situations that would normally play against their favor, or turn the tables on the system? Can the system be abused in the player's favor? Can the player be... "creative"... use their imagination and understanding of the system... in how they will achieve victory?

I'd rather focus on creating a system that the player can work and strategize with, instead of creating a system that tests the player's reflexes and just looks pretty. This decision renders having to make a "Super cinematic attack sequence alpha" editor program pointless, in my opinion. The fanciest I should make my attacks are probably when the player "summons" a being to attack. (I'm thinking every player character will have their own unique 'summon', which levels up alongside them and gains more attacks as the player progresses. How useful a summon can be at any given time depends on player participation in battle [giving/recieving hits, healing and defending allies, etc.])

So this PixelDust program will be THE special effects program for all attacks. After this, I could go straight to making the player/enemy editing programs, and then the actual battle engine much faster.

PixelDust

Started working on PixelDust, particle animation program:

I'm thinking of what kinds of rules I can set for myself for making particles:

• There will be "x" amount of particles at any given time. X is a static value that represents how many particles for animations can be shown in a single frame. I don't plan to use very many particles, so I can keep this at about 100-200. The reason I want to keep this static is because of garbage collection. I'm afraid making too many new objects (allocating more memory) a frame will kill my game, so I think it'd be better if I declared this beforehand. As for preventing "unfilled" particles from being drawn? I'll probably just have those particles turned around so the vertice order is clockwise, cull those, and only draw vertices that are set counter-clockwise.
• All particle animations will run off the same texture file. That's because I'd like to batch all of the particles into a single draw call. I'm told Xbox360 doesn't really like so many draw calls (my scenery is drawing a lot already anyways), so I'll keep this simple. It's no big deal for me anyways, since I'd prefer for my game to have low-res point-sampled graphics.
• No fancy shader programs. All particles should be rendered with XNA's built-in effects. Anything a Windows Phone can do, an XBox360 and a PC *should* be able to do. So I'll be setting the texture co-ordinates, positions, etc of each particle vertex in CPU.
• Each particle animation will have it's own sound effects and target effects. If the animation is directed towards a specific target (as in the preview screen), target effects will be played.
• Although it is previewed in 3D space, particles will really only move along the XY plane. They also won't do any depth reading, so any particles below that target that sinks into the ground will still be visible. Which brings up the question of the layering of particles. Particles will either be sorted before drawing or drawn additively (which is done with most particles anyhow)

Voxelcraft is now complete

I've set up the control system and the save/loading, so Voxelcraft is good to go as of today :)

It's about time, too.

I came up with an idea of some video game I wanted to make a long while ago, but I was still trying to figure out the big things like, how am I going to make the worlds? Collision? How will it be played? I had put together a scene that would depict what the game would look like:

I wanted to make an RPG in the style of an 8-bit era game, sort of like Half Minute Hero and the Bit.Trip series. It's bit of a step up from the last game I made, which was a mindless shoot-em-up where you shot down tons of Michael Jacksons using your Rubber Ducks. For that game, I developed a basic shooter engine and built levels as I wanted, but now I'm going to have to plan. RPGs focus on chains events where doing one thing in one place will let you do another thing in another place. Not completely sure how I'll do this, but I'll figure it out along the way.


I don't remember when I decided to use "3D" for my game. It felt more natural for an 8-bit game to be in 2D. Maybe I thought it'd be a nice experiment. I tried figuring out what type of 3D would be best for my game, and how complex it would be. I didn't feel like using a 3D modeling system like Blender or 3Ds Max. I wanted all geometry to be calculated in-game during loads. In the end, I decided to use cubes and only cubes for the worlds I make.

I think it's been about six months ago when I started working on Voxelcraft. And once I was able to place the first cubes, it looked something like this:

You might see a problem in this picture where there are these lines across corners. I was whining so much about this, and I tried to find out how to fix this. Eventually I found out what my problem was!

I'm stupid.

I can't have a cube with 8 vertices that share normals for lighting values. If I wanted each face to be lighted correctly, they'd need their own vertices. So now cubes have 24 vertices.

For the rest of the development of the program, it went slowly. I was learning how XNA works, and was doing other things at the time (such as schooling. Damn you school).

But I'm glad I finally have this program done. This means I can finally move on to other programs! I have so many more I have to make, but none of them will be as hard to make as Voxelcraft was. Voxelcraft is about as far as graphics for my game goes, except for particles and sprites.

Which is the next program I'll be developing. Dust. It will make all the particle animations for battles. It'll be very similar to my previous Particle program I built in Visual Basic, Pixelcraft...

I want my game to not only run on PC and XBox, but also on the new Windows Phone, with shadows and some other effects turned off (XNA on Windows Phone can't have custom shaders). Particles usually have custom shaders, but they can be drawn with XNA's built-in BasicEffect, so particles will be simple.

Another program I'm looking forward to making is one that will create "cinematic" attacks. For many games where your character has some special attack, it stops playing like a game and looks like an interactive movie for a minute. Squaresoft is rather fond of this, but don't worry, I won't make attacks sequences that drag out over a minute :-P I'm thinking that instead of having the player watch some movie, I'll have them interact with the attacks to change the outcome of it (this way, I can have bosses that have attacks that kill everyone in one hit, but can be avoided and possibly countered) I'm thinking about how the player will interact. Will it be through button presses?... as with EVERY game!?

It'll be figured out soon.

I knew I was forgetting some kind of light!

I model Voxelcraft off of all the old-school 8-bit games. 8-bit games come from the 80's, and when I think of think of 80's I think of neon bowling for some reason. How could I NOT resist a glow effect?

To produce the glow effect, I re-render the entire scene into it's own buffer, only instead of using the normal texture atlas I use a texture file containing glow information. It's a very simple render, I don't apply any sort of lighting. Then I apply a Gaussian blur to the buffer, and blend it additively into the final image. Easy as one, two, three!

Another effect I have is fog. For most of the scene, I am taking every vertex and giving it a "fog density" value based on fog data, and how close the camera is to the vertex. I couldn't do this with the water though, since all the water vertices are far away and will give them the same tint, so I'm doing fog in the pixel shader of my water effect instead.

Yeah, I'm such a liar for saying I only had channels and saving to do. But I did do the channels bit of Voxelcraft!

I did have a bit of trouble with rotation, though. Say, for example, I wanted to make a windmill at a 45 degree angle. Then I would make a separate channel for the fan of the windmill, place it on the windmill, and spin in along it's z - axis. It wouldn't work because it's not spinning on it's own z - axis, it's spinning on the world's z-axis! But solving this problem was so easy. I was using Matrix.CreateRotation methods for the rotation. I just replaced this with Matrix.CreateFromYawPitchRoll and all is well.


Also, some other pictures of Voxelcraft, since I haven't updated on that much lately... these pictures show off more of the mini-cube, which takes a pixel from the texture atlas and maps it onto a miniature "pixel" cube.

Also, addition to spotlights.

Voxelcraft almost finished

I am almost finished with Voxelcraft. I have most of the vasic functions finished, such as texture, mini-cube, and lighting, and now all that's left to do is channels and saving, as well as a few adjustments to make the program more user friendly.
Channels will be easy. I will separate each channel into different vertex buffers and draw those separately. Each channel also contains data for rotation, translation, and scale. Cubes can be placed into those channels. This will give effects such as objects floating around, gears turning, and basically gives cubes movement. So if I wanted to make a scene where you are on top of a moving train, I'd put the train cubes and the scenery cubes on different channels. This could also allow me to easily adjust parts of the map inside game code (like if a player goes up to a door and opens it). Also, for scrolling, I'll have to copy the channel the other direction to complete the scrolling effect.
Saving is pretty self-explanatory. It will make the Voxelcraft files to be used with other programs and ultimately the game. It will save vertex data and world matrices for each channel, as well as light data.
I'm glad I got this far in development, but I am a bit disappointed in ending it here, though. It feels like there should be more things to do. Like depth blur and HDR. But that may make the project too complex. (I want to keep everything simple) Voxelcraft was meant to create simple cube worlds, not very realistic models! But I might still put such effects in later, when I work on a later development tool.
I've been working on it for so long, too. I just want to end it so I can move on. I've started it maybe six months ago (?), and stopped after I got basic colored cubes down because I couldn't figure out normals (I had no 3d experience before this) After working on another program (a 2d skeletal animation program), I decided I wanted to go back to Voxelcraft. Now I'm finally finished, and I'm quite content with it for the most part.

But I need to be working on other areas such as gameplay. Before I work on gameplay, though, there's another graphics program I need to make. It will be a 2d particle system called Dust. It will make all the attack animations and special effects used in battle for the game. I say 2D because the camera in battle will probably not be as free, it will move around but not rotate (created a 2.5D effect). Since I'm doing this, I can get away with 2D effects. Don't worry, though, camera can still rotate when it needs to, and there will be 3D particles, it just probably won't be used in battle.

Texture select added

I can't believe it took me this long to finally decide to implement the more important parts of Voxelcraft. But now I can use multiple textures with Voxelcraft.

The pictures you see on the bottom left show which textures for each face are being used for the current cube. All of the textures are packed into a single file called the "texture atlas". The user can use the QWERTY keys to change the textures for each face. When one of those keys are pressed, a picture of the entire texture atlas appears, and the user presses the arrow keys to choose the texture.

• Q - Front
• W - Back
• E - Left
• R - Right
• T - Up
• Y - Down

Also, the user can press the U key to assign one texture to all sides of the cube. Very handy.

One of the problems I've run into was that the Wrap address mode for texture sampling didn't work as I thought. I thought I could wrap a portion of a texture (I'm such a noob at this :-P). So I couldn't wrap tiles anymore. Sucks. I had to think of an alternative. And I've come up with several:

I  could probably get away with using multiple vertices to emulate wrapping. But this would be very expensive if I wanted to, say, draw a 100x100 plane. That'd be 10,000 vertices (20000 primitives)! That's a lot more compared to 4 vertices (2 primitives), which I used to get before I found out wrapping wouldn't work.

So I thought I could separate the textures into different texture files. And then for each texture, I would draw each cube face that corresponds to that. And I'd switch to the next texture for the next draw call. But this'll amount to too many draw calls. I'd like to keep the number of draw calls low.

Eventually, I settled with what I thought was a really crappy method of wrapping. But it works. Originally, I had a texture atlas sized 64x64, each texture being 8x8. I decided since my textures are so simple, I could expand my texture atlas to 512x512, and have each texture that's supposed to wrap repeat itself 8 times both ways! And when I resize my cube, it'll refer to the next 8x8 tile over it, emulating a tiling effect.

This is loosely based off my "many vertices" idea, except not as many vertices. Because each wrapped texture repeats 8 times, I'll have to make more cubes to expand the wrapping effect. Going back to my 100x100 plane scenario, that'd be about 13 smaller planes both ways, and because the smaller planes aren't really connected to each other and are using it's own vertices, that would be 676 vertices (338 primitives), but it's SO MUCH better than the previous 10,000 vertices solution.

I also ran into the problem of flickering lines at the edges of each cube that has another cube adjacent to it. I'm pretty sure even professionals run into this problem a lot, but I have the problem worse because Voxelcraft is based on cubes. Not even POINT sampling will save me, which I was using in the first place.

If I couldn't solve the problem, I decided I'd hide it. I made a 256x256 image of repeating cubes.

Each cube represents a "pixel". The effect I'm getting from applying this to my textures is that each "pixel"  in the texture atlas kind of sticks out. It's similar to 3D Dot Game Hero's style of art. I was trying to avoid this so I could have a cleaner sort of look, but it looks this is the only way to solve this problem. 

I noticed that there were some strange artifacts at certain distances where this texture overlay would form strange shapes of it's own (if you can see it in the picture up top). "Duh!" I thought. "I haven't made use of mip-mapping!" Honestly, I thought mip-mapping didn't make much of a difference in graphics. But I was SO wrong. Mip-mapping cleans up a lot of aliasing, and it can make scenes render faster, since it refers to a smaller texture within the texture's mip-map "chain".

I should probably use mip-mapping for my actual texture atlas, but I hear it's impossible to do without merging pixels from neighboring textures, but I could probably just add a border instead.

War of the 300 Errors

Tonight, I dine in hell.

Today, I decided I wanted to get with the times and upgrade to the new XNA 4.0. For these reasons:

• It's so much easier to use. I hate having to write so much code for the simplest of things.
• I noticed while I was implementing the moon that the glow was fading to black around the edges, even though it was white when I made it. It's because alpha wasn't pre-multiplied, apparently (or something to that extent), and XNA 4.0 does the alpha correctly. I could've written a custom importer to help me with this while using XNA 3.1, but I'd rather not get into very complicated code right now.
• XNA Creators Club won't accept 3.1 games after a while. They will only accept 4.0.
• Reach/HiDef profiles. One's used for low-end systems (Reach), and the other for high end systems (HiDef). I can use Reach if I want to develop a game using a "limited API", which will make it easy for me to develop for older, less powerful computers. Or, I can use HiDef for the full API, and make higher quality games for XBox 360 or a powerful PC. I plan on using both, if possible.
• I can develop for Windows Phone 7. Don't know how that would work out, but it'll be a neat experiment, at the very least.

So I got all the new stuff now, and converted Voxelcraft to use the XNA 4.0, and I started the program... only to be faced with 300 errors. As it turns out, the XNA crew did a lot of changes to the new framework. Some of these changes are very convenient, I like the new replacements for RenderState, and now I'm just able to set vertices and indices and draw them, and I don't have to deal with VertexDeclaration. They also took out a couple of things, though, most of which are no big deal (as far as I'm concerned), and since they've made so many changes to how stuff works in XNA now, that brought up those 300 errors. Their errors have blocked out the sun...

Then I shall code in the shade. Just me against the Microsoft Empire. THIS.... IS....

...not as bad as I thought. I've already gotten rid of the errors, most were pretty simple. I ended up having to take out normal maps (for cubes, not ocean) and I never use those normal maps anyways. It wasn't getting the tangent for vertices for some reason, but it always worked for XNA 3.1. But I'm glad the new XNA picked up on this error, because it's possible if someone tried to use this program on another computer, it would crash. 

Most things are working, except for water. They took out ClipPlane, which I needed for reflection/refraction. This should be easy to fix, though. I could probably use the clip() intrinsic in the HLSL code to replace it.