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.