The VG Resource

Full Version: TFR: Scratch Edition [Program]
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5
Ah, I see. Sure, go ahead if you want. I was never really interested in the PM stuff, so thanks. However, it'll probably be a while before the game is ready for alternate modes. Though, I guess all you really need access to is customization.
To start off the new year and the first monthly build, check out the first post!
I'm still working on the fighting collision system. I've been trying to get everything to work at the same time but things are just getting really confusing. There are grab, offensive, defensive, and hurt collisions. In a single step, there can be many collisions interacting (many attackers influencing a victim). I have to filter out which ones actually connect along with the effects and stuffs... I'm getting a little overwhelmed, really.

I'ma step back and just code in offensive vs hurt collisions for now and work my way up from there, like I should've been. Haha, I thought I could handle all of "rules" in one go, guess not.

__

Made a poll to to see what happens...Don't know how to delete it.
I tried launching the build, but it doesn't start up. I'm running under Windows 7 64bit.
Did you have the XNA redistributable installed?
http://www.microsoft.com/en-us/download/...x?id=20914
It does now I've installed it. Thanks!
Robo's special move looks great, btw!
No problem. Here's the current progress on hits.

http://i.imgur.com/XMLndvO.gif

Atm, I've only got Offensive Vs Hurt collisions. Currently, there's hit gfx and sfx, hitstun and knockback.

Oh yeah, I also added an event to check "SpecificCollision". Will any character actually use it? I dunno, but it was easy to add so why not. An Example use would be Link's boomerang where he regrabs it. Basically, you're able to subscribe for checking specific objects for collisions and can use that info however you like.

___

Edit:

I'm also researching about networking subjects. Currently, it seems that it's possible to only need to send player inputs to eachother without desyncing. However, that requires the game to be deterministic across computers. I've been led to something called fixed point math, where you use integers to represent fractional numbers. It still comes off a bit complicated and confusing, but I think I'm getting there.

If fixed point is what I need, then I'll also have to research a bit about matrix math since I currently use matrices to store position and also do hierarchy stuff. I'm not sure how long that'll take.

If it goes well, a deterministic game allows recording gameplay too, at least, that's what people generally say. It also allows for "exact"? or high control over mechanics.., for example, movement.

I'm just in the research phase, and online isn't even a high priority, I'm just curious.
It looks very impressive from what  I can see, but I can't run the .exe. I don't know If I should install the XNA thing because 1) I'm using Linux & 2) The OS this PC was originally meant for was Windows XP. Should I try anyway?
According to the XNA 4 refresh system requirements:

Quote:Supported Operating System

Windows 7, Windows XP

To run XNA Framework games on a computer running a Windows operating system, you need a graphics card that supports, at minimum, Shader Model 1.1 and DirectX 9.0c. We recommend using a graphics card that supports Shader Model 2.0, which is required by some samples and starter kits.

You should be fine? I don't know how Linux affects anything. ~I don't know much about Linux.

__

Edit:

School's starts back up this Monday. I'm unsure how much it'll affect progress, but I just wanted people to know.
Quick update

http://i.imgur.com/P0rnaRj.gif

Very tired. It's not done.
The Xero Stage (Icicle's Stage) was designed to be a scrolling one. The blade-like buildings are... buildings that you fly by. You're fighting on top of a dragon by the way. Sorry for not mentioning this sooner.
That's fine, it's not that big of an edit.

___

Progress looks like it's going to be slowed down. The classes I'm taking this semester seem very challenging and I have a lot of catching up to do.
Quick Up-to-date post:

I don't think height based attack will work in this game due to the scale of characters. At least, it wouldn't visually make much sense to differentiate standing and crouching attack priorities.

It would be great if people made a "Grabbed" animation or frame. It's not necessary to make a "Grabbed Hurt" action, but you can if you'd like.

By the end of this month, or at least during the next month, I'm going to be working on the collision placement tool. It seems very simple, so I don't expect it to take long. But, I got school too so~

I haven't added defensive collision bubbles, not even for testing purposes. Every time I try to work out its details, I just confuse myself terribly..lol. I'd go into more detail, but I'm trying to make a quick post. Maybe I'll edit this tomorrow, if I get the chance.

I'm still in the process of working out the grabbing system. Uh not much info, I guess.

Oh yea, just so people know, there are (and I can further support, if needed) on contact GFX or SFX when a collision, for example a specific offensive collision bubble, connects. That's the way the hitting GIF in the previous post works. The GFX id to show is defined within the same call to creating the attack bubble.

Uhm..hmmm. What else.

Online stuff. I need to learn about fixed point math to further ensure the game is deterministic. I'll also have to learn about matrix math since I use them often in the game. Although, I can probably get away with just positions...eh I'll figure it when I get there.

Menu backgrounds. They can have animations, frame by frame and/or skeletal.

~
This was going to be an edit, but the post is a decent size, so~
--

I finally figured out the rules/system for defensive collision masks after I realized that they should be easily understandable by the player.  Before, I went in circles imagining complicated (unrealistic) cases.  Now, the rule is as simple as defending is successful if done in the same direction as attacker origin.....Yeah... Sometimes it's easy to forget that you're just making a game, not a masterpiece, nor a potential future game.

By design, along with the defensive mask, you can define the move to change to if it connects.  For consistency, normal blocking should use the block move.  That means, while moving backwards, the mask is should be active(created).  It also means that, while moving forward, I can support parrying in the same exact way just by changing the move to set.  

There are on contact GFX and SFX for defensive masks, too. If it's successful, they will be activated instead of the attack mask FXs.

That's coded, I just have to do testing.  I'm also adding in the code for Attack vs Attack masks.  There are 3 strength levels, 0, 1 and 2.  Attacks with strengths of 0 and 1 can be overpowered by the higher level, or both cancelled if equal.  A level of 2 means that it cannot be overpowered, nor cancelled.  

In hindsight, after taking things in slower bits, the collision response system turned out easier than expected.  Most of it is done, I think.  Though, I still have to get to the grabbing system.  But I consider that a separate system than the direct collision response system.
I don't think I'll have another build uploaded this weekend. Maybe, I can try to get one in next weekend. I haven't had much time to work on the code, but I have been able to at least plan out what I'm going to do.

I haven't had a chance to test all, or any, collision-vs-collision types, but they are implemented. I've been planning a very basic in-game tool that allows you to edit, save, and load character data. For the next build, I'm working to get a basic collision mask authoring tool. It allows you to create the attack/def/hurt/grab collision masks on a per move basis. You will be able to pause the game, select a loaded character in battle, select the action + subaction (an attack/move) to edit, and then place collision masks. There will also be controls to manually select the collision mask and make edits.

The in game editor is more of a hybrid between a normal windows form/app/program/..window and an in-game editor overlay.. thing. The ingame overlay will be mostly for visual feedback of the current collision mask that is being created, along with the existing masks. The side editor will be a basic windows form that has controls to allow for hand editing of specific properties.

__

Maybe I'll also add in the ability to mark when to play sfx and gfx during a move. That's a lot easier to do in-game than editing a script. You guys don't have the tools to add in your own gfx, but you can easily add in sfx. I'll explain more later if I do so.
Pages: 1 2 3 4 5