The VG Resource
MFGG TKO DevLog - TSG Left - Printable Version

+- The VG Resource (https://www.vg-resource.com)
+-- Forum: Archive (https://www.vg-resource.com/forum-65.html)
+--- Forum: July 2014 Archive (https://www.vg-resource.com/forum-139.html)
+---- Forum: Creative Zone (https://www.vg-resource.com/forum-86.html)
+----- Forum: Games Development (https://www.vg-resource.com/forum-22.html)
+----- Thread: MFGG TKO DevLog - TSG Left (/thread-24417.html)

Pages: 1 2

MFGG TKO DevLog - TSG Left - TheShyGuy - 01-10-2014

Devlog #End

Welp, I apologize, but I no longer want to continue programming for this game. I'm going to relax a bit, learn and most likely move onto Unity. Goodluck guys, and again, sorry for leaving.



Okay so this is my first time making a dev log. I didn't want to start this off with a meh post but I needed to at least start the dev log...so a meh post it is! Blank

-----

I'm Mit's programmer for a game called Mfgg TKO. It's a 2D brawler platformer based around the members of MFGG. I'll try to post about progress whenever I feel I need some feedback, have done anything log worthy, or to just keep you guys in the loop.

Instead of writing of everything I've done so far in single post, I'll try to spread it out over a few days so it's not too overwhelming. For now, I'll just make a general post about what I've done so far.

Here are a few gifs of the game so far. The levels aren't apart of the final game, they're just for testing purposes. (which some have seen in the WIP thread)

GIFS
[+]Spoiler
Here is the animation tool I made which took a few months and still isn't finished. I just gave it out to mit and the others for use.

GIFS
[+]Spoiler
The tool supports palettes, skeletal animation, and normal frame-based animation. You can also animate tinting, rotation, scaling, translating, skewing visibility, and palette fading/changing/animating among other things. I also added subanimations which I had fun implementing. You can basically use and animate multiple subanimations within an animation. However, you can only animate the subanimation from a higher level. You can indirectly affect it's timeline so you can play it at arbitrary times or even speed it up or slow it down. It was originally made for Ridge Troopa's and Phaze's game which unfortunately went on hiatus before I could get any good progress done on the tool. I've made a few animation tools, and this one along with the sprite engine is my favorite so far, thanks Ridge.
The game itself is still in very early development. I'm still just laying down the core engine stuff.

------------------------

Videos:

AI pathfinding (very early WIP)


Random Pics (old)

GIFS
[+]Spoiler
In the engine, attacks have "scripts"(subactions) attached. The script is called once per animation frame. I love this system which I based off of how PSA's are done over at kc-mm. I can create offensive collisions, graphics effects, play sounds, whatever, etc within the script in order to create the move. -I gotta move the code out of C# later and into Lua so Mit and the others can code their own moves without needing to rebuild the game or directly need me. An idea we have is to have online multiplayer where your friend's custom characters will be loaded and can be selected by eachother. That should be fun to code when we get there.

--------------------------

Team Members:
-Leader: Mit
-Spriter: Mit, ~CaMtEnDo~
-Programmer: TheShyGuy,
-General/Other(unsure, sorry): Shadow Kami, Genogenesis7, StrikeForcer

--------------------------

If you're interested, then please feel free to ask, suggest, comment, or otherwise contribute.

Thanks for your time.

RE: Mfgg TKO DevLog - Neweegee - 01-10-2014

Wow it looks really cool so far; I already like the smooth game-play.
Is there going to be multiplayer?

RE: Mfgg TKO DevLog - TheShyGuy - 01-10-2014

Yeah of course. Since movesets are going to be done in lua, they're easily editable. By then, there should be support for custom movesets. When you play with a friend online, you can download/use each other's custom characters. That's the idea so far. 0% of progress done on that part networking side though. The moveset "engine" is pretty much done (the actual fighting isn't), we just need to make content for it.

RE: Mfgg TKO DevLog - Dazz - 01-11-2014

Came in not expecting much (not intended as being offensive) but I'm pretty blown away; this looks really impressive. I could see this being used for something substantial.

I'd love to see a game like this be worked into a Metroidvania style RPG - I would love to get involved in such a project. It looks supremely awesome. Very smooth, really interesting. Do you have any sort of super basic demo? Does the whole thing allow for a larger scale? It's relatively low-res right now, which is absolutely fine, but it'd be interesting to see a more extended view, or for other projects using the same engine, larger graphics.

RE: Mfgg TKO DevLog - Kosheh - 01-11-2014

(01-10-2014, 07:10 PM)TheShyGuy Wrote: An idea we have is to have online multiplayer where your friend's custom characters will be loaded and can be selected by eachother. That should be fun to code when we get there.
I'd be careful with this and try to place ingame engine limits. This idea won't be fun when That Guy makes a character with a kick that fills the whole screen and OHKOs you ):

If possible (and I'm not a programming sort) I'd try to hardcode maximums for each usable stat and probably hardcode a maximum sprite-size too (though it would suck having to fight that guy with a 2px hitbox) so you dont have The Most L33T Characters Alive

RE: Mfgg TKO DevLog - TheShyGuy - 01-11-2014

(01-11-2014, 10:43 AM)Dazz Wrote: Came in not expecting much (not intended as being offensive)
None taken, that's a bit understandable.

Quote: Do you have any sort of super basic demo? Does the whole thing allow for a larger scale? It's relatively low-res right now, which is absolutely fine, but it'd be interesting to see a more extended view, or for other projects using the same engine, larger graphics.

Right now, there isn't a public demo out, sorry.

The moveset engine is pretty simple and subactions/attacks should be pretty cheap since they run throughout the animation, once per animation frame. I'm unsure about the animation system though. Right now the animations for mit are very simple since it's just frame-based. But theres support to make it a lot more interesting. I designed the animation system to be a bit generic (not literally) which allows flexibility at the cost of a bit of performance. Previous and Fluttershy over at the chat helped me out when I had questions or issues with making it generic - thanks guys. With my zero experience of big projects, I can only hope it scales fine.

cross post from Mit over at MFGG about the graphics. (answer at the bottom)
[+]Spoiler
Kosheh Wrote:This idea won't be fun when That Guy makes a character with a kick that fills the whole screen and OHKOs you ):

The idea hasn't been fully though out yet. In my mind, I figured it be more of a peer to peer/ friend to friend type of deal. If your friend decides to piss you off by making a cheap character then beat his ass in real life...or y'kno -rage quit. If it does become a big issue, then I'll try to look into ways to put limitations in.

------

thanks for the support guys

RE: Mfgg TKO DevLog - Phaze - 01-12-2014

You could always have set maximums for individual things and have a maximum overall that each different type of thing consumes weighted amounts from the budget. This would be very complex and difficult to balance effectively, though. It's up to you!

RE: Mfgg TKO DevLog - TheShyGuy - 01-13-2014

@Phaze and Kosheh:
The game is really only going to be released here and on mfgg. If someone makes a cheap character, then don't play with them. I think that's a easier solution than putting in fake limits. It just doesn't feel right and would probably be more trouble to tweak than it's worth.

Devlog #1

I spent the day moving the character Mit's subaction data over to lua. Everything works fine which is awesome. Moving the movesets out to lua allows so much more ease especially since lua has coroutines. Which basically means I can run a function over time instead of doing it all in one go. It's easier to do in lua than c#. In c#, I just used a behavior tree which basically does something similar. It's also bit uglier when trying to use general variables between 'events'/functions within even the same subaction which wasn't even possible the way I had it set up at first. A few months ago, I even went as far making a cache and wrappers of primitive types for custom variable use. It worked...but it was so ugly..... Anyways, lua allows people to create and use custom variables to do whatever they want and share them between other subactions and throughout the subaction itself without any weird code or ugliness (run on?? heh). I still gotta move all the events out to lua to which is easy, but annoying.

Heres what the first punch looks like in c#:

[+]Spoiler
I also fixed a rendering issue I had with layering a while ago and I also added support for camera shake yesteryday.

GIFS
[+]Spoiler
-Mit's subactions are all in lua in the above gifs

Lua shouldn't be too hard to learn. Really, if you don't plan on doing anything fancy, all you'd have to know in order to make a custom moveset is the list of events that I coded.

---------------------------------------------------

I also made a very simple string file format a few days ago since I needed a quick and easy format to export data from blender to (has nothing to do with this) It's very easy to read in and write out. For those who need a simple save file format, here it is:

Code:
Description
         * each block begins with "{", "}" (on a lone line)
         * a block's properties follow (without quotes, separate line) : "PropName=PropVal"
         * note* the properties just have to be in the same '{','}' block,
         *         they don't have to be in any order
         *
         * block interpretation:
         *
         * each block has atleast "BlockTag" property to easily ID it
         * nested blocks are children of the parent block
Code:
Example:
{
     BlockTag = Player
     Name = TheShyGuy
     Level = -1
      {
            BlockTag = Stat
            Name = Health
            Value = 10
      }
      {
            BlockTag = Stat
            Name = Defence
            Value = 5
      }    
}

Reading the file into an intermediate structure:

Code:
/// <summary>
        /// Reads a block along with it's nested children.
        /// The file format's properties do not have to be in order.
        /// </summary>
        /// <param name="reader"></param>
        /// <returns></returns>
        private static Block ReadBlock(StreamReader reader)
        {
            Block result = new Block();

            string line = reader.ReadLine();

            //keep reading until I hit the closing bracket
            while (!line.Equals("}"))
            {
                //If I hit an opening bracket, then the following lines
                //are of a new nested child block
                if (line.Equals("{"))
                    result.ChildBlocks.Add(ReadBlock(reader));
                else if(!string.IsNullOrWhiteSpace(line))
                {
                    //or else the following line is a property.
                    string[] split = line.Split('=');
                    string key = split[0];
                    string val = split[1];

                    result.Properties.Add(key, val);
                }

                line = reader.ReadLine();
            }

            return result;
        }
        private class Block
        {
            private const string BLOCKTAG = "BlockTag";

            public string this[string key]
            {
                get
                {
                    return Properties[key];
                }
            }

            public Dictionary<string,string> Properties;
            public List<Block> ChildBlocks;

            public Block()
            {
                this.Properties = new Dictionary<string, string>();
                this.ChildBlocks = new List<Block>();
            }

            public string GetTag() { return Properties[BLOCKTAG]; }
            public bool IsType(string tagType) { return GetTag() == tagType ; }
        }

Aaand finally converting the intermediate format, the blocks, into the game data:

Code:
public Player LoadPlayerFile(...)
{
     StreamReader reader = ...
     Block rootBlock = ReadBlock(reader);

     if(rootBlock.IsType("Player"))
         return ParsePlayer(rootBlock)
     else
          //throw exeception since the file wasn't a player file
}

private Player ParsePlayer(Block block)
{
     Player player = new Player();
     player.Name = block["Name"] // player.Name = block.Properties["Name"] = "TheShyGuy"
     player.Level = int.Parse(block["Level"]) //don't forget to convert the string to int
    
     foreach(Block childNode in block.ChildBlocks)
     {
          if(childNode.IsType("Stat"))
               player.Stats.Add(ParseStat(childNode)) //Adds health and defence stats
          else
               ThrowNotSupportedBlock(block.GetTag(),childNode.GetTag())
     }
}
private Stat ParseStat(Block block)
{
     Stat stat = new Stat()
     stat.Name = block["Name"]
     stat.Value = int.Parse(block["Value"])
    
     return result;
}
private static void ThrowNotSupportedBlock(string blockTag, string childTag)
{
      throw new Exception(string.Format("{0} block does not support blocks of type {1}",blockTag,childTag));
}

And there we go. The format is simple to write to and read from especially since it's recursive. The block intermediate format allows you to easily parse the properties into your game object properties. People can use this if they want, no credit needed but it would be appreciated if you notify me that you used it.

RE: Mfgg TKO DevLog - TheShyGuy - 01-15-2014

Devlog #2

tl;dr ... All I did was whine.

I finished moving all events over to lua. I also moved mit's actions and subactions over too. He's no longer hardcoded into the game and is now easily editable. There wasn't much that happened in the last few days other than that.

However, today, I realized that one somewhat important moveset feature doesn't actually work.... I'll explain how actions and subactions work really quick. Actions decide and set the current subaction. Actions get called every game step. They do not call or execute subactions. Subactions are coupled with an animation and gets executed once per animation frame. When an action changes the subaction, the new subaction will get executed from start to finish over the animation's time. Subactions can also change the current subaction to whatever they want which will also be executed from start to finish. This is how i did the punch combo. But... what if I have a subaction that needs to be "passFramed". PassFraming basically means to skip to an arbitrary frame in the next subaction. Visually, the animation and it's timeline is skipped correctly. But the code/script/subaction won't. I just realized now that the feature doesn't work =( ... I have ideas about how to go about doing it right, but I've found issues with all of them... I don't know how to "pass frame" correctly. Now, this isn't that big of a deal if I never have to passframe of course... But in this case, I do.

Here is the attack's animation that requires pass framing:

GIFS
[+]Spoiler
*they all play at the same framerate. All animations have the same frame lengths. Ignore the fact that they're not synced.

Mit is shooting while walking. Each gif is a separate subaction.

....*deleted paragraph of explanation of issue*...

I don't even know how to explain the issue with lua code without things getting too confusing. I'm just having trouble explaining this. Basically, this group of subactions all have to be pass framed to. As you can see, each subaction shoots a projectile at a specific frame. It is important then to use pass frame in order to skip to the correct location within the subaction script so that any event before hand doesn't get called. If i pass frame past the shooting frame, then I shouldn't shoot at all. The issue is that every event prior to the wanted pass frame will execute.... Meaning that if I played the 4 subactions above, passframing from one to the other, then it would shoot 4 times instead of once...............

...*another deleted paragraph of brainstormed solutions*....

I don't know how to fix this issue. I can go around it by covering blocks of events within conditions like

Code:
Asynchronous(#)
if((passFrame && frame == #) || !passFrame)
{
     //create offensive collision
     //do whatever
     Synchronous(5)
}

if((passFrame && frame == # + 5) || !passFrame)
     //do whatever
... but that's seriously ugly. I can do that, but I wouldn't expect anyone else to do it....

Again, this isn't a feature that's required to make a moveset. Although, it would be nice to have the feature supported in a nice way. I'll stop whining now, thanks for reading. If anyone has any ideas, please share.

*Note: that there is an idle animation of the same shooting. So I couldn't go from the idle shot to walking shot without passframe. I also couldn't do the reverse of walking while shooting then going idle.

-----------------------------------------------------


Edit:

I've been thinking of creating a queue-like system for subactions. Events are added to the queue and then processed as they're added to the queue. The queue will have a "Queue Frame". The only way to change the queue frame is by Asynchronous and Synchronous timers. As events are processed, they are timestamped with the queue frame. Their timestamp/framestamp will be compared with the passframe value. If it fails, then the event isn't executed. If it succeeds, then the event is executed. This means no more lua for subactions. Actions don't execute with an animation, so they're fine. People can still make their own custom movesets, but the programming might become inconsistent for you guys. I'd have to make a small tool similar to PSA. This might be overkill, especially for a single feature. In the long run, I feel this is necessary. If I ever move to a 3D brawler like smash bros, then pass framing might become really important for unique moves or transitions. In smash bros brawl, if you do land on the ground while doing an air attack, then the subaction passframes to another subaction. This is so there isn't an abrupt change from the aerial attack to standing idle when you land. If I try to do the above in 3D, then I'd probably try to split animations and subactions based on body part. The legs would run the walk subaction and animation while the upper body runs the shooting subaction and animation. That would be overkill in a 2D game - and in a 3D smashbros-like game where fighting happens on a 2d plane.... This is all just brainstorming and I like this idea so far. What do you guys think?

*strike-outs* hmmm. Atm, events are "direct". When they're called, they directly affect the game and or character. If I decide to wrap every event into a "Queue item", then it might work fine as is - no need for a tool. Events will be wrapped at a lower level, so you guys won't have to worry about it. Loops and conditions would all work the same in lua. However, the way variables are used might have to change or be explicitly wrapped into a queue item somehow. If anyone makes new events, they'd have to manually wrap them. This feels like an improved idea since there's no need to make a custom tool and you can still use lua which keeps coding actions and subactions constistent. Thoughts?

RE: MFGG TKO DevLog - TheShyGuy - 01-17-2014

Devlog #3

I found a nice solution to the above. I kinda went with the queue...but at the same time the "if( (passFrame && frame == #) || !passframe)"...? Basically, I just made an EventQueue which events "respect" (?). The queue basically gives them permission about whether they're allowed to execute, are suspended and thus should skip a frame, or should be ignored and not do what they wanted to do. I made a small wrapper function in lua which referenced the queue and passframing works as it should now =p. I only wrapped functions that made a change to the game or character. I didn't wrap conditional events or events that returned information. Lua can be used like lua so there was very little loss and headache over supporting passframing which surprised me a bit (and at the same time didn't?)

If you have a subaction that you would like to pass frame to, then there is a little bit you have to do to ensure it passframe right. However, it's no big deal and very minor. In the end, I'm happy with the solution.

Just so I have a few gifs showing the 2 moves I've began working on:

GIFS
[+]Spoiler
This one is just to show passframing visually.

GIFS
[+]Spoiler
I'm a bit tired of working on the moveset system, so I'm going to focus a little bit on the HUD over the next few days.


PS. By the way, heres what I use to make the gifs: http://www.cockos.com/licecap/

RE: MFGG TKO DevLog - Mit - 01-20-2014

here's a not-devlog, featuring some spiffy new sprites!
[Image: BC8h3mP.gif]
[Image: RQC2NvS.gif]
[Image: wBx4WXN.gif]

I've got another one but it's not coming out as a gif right, so here're the frames-
[Image: 6svVB.png]

RE: MFGG TKO DevLog - TheShyGuy - 01-24-2014

Lookin nice Mit and Happy Birthday!

Devlog #4

It's been a week hm? What have I done....

It took me a few days to go through all my code and clean it up. Someone wanted to help out on the coding side. I hope the code is easier for him to get into now. -I have not heard of him since.....Sorry lol.

My animation tool has been giving me headaches with bugs too. Lots of bugfixes there, I won't go into detail.

The HUD?
(brute force coding just to get a feel for it)
GIFS
[+]Spoiler
I also had to work on a new collision system to replace the Farseer Physics Engine. Farseer is great and all, but it's very much overkill. I find it a bit difficult to do nonrealistic physics.....with the realistic physics engine hehe.

GIFS
[+]Spoiler
For those interested, the collision test is the Separating Axis Theorem (SAT). I also use a broadphase called Persistent Sweep and Prune (SAP). It was pretty fun and rewarding to learn. I went from only being able to do about 200 polygons brute force (every polygon against every other polygon so about 40,000 test per frame) to about 1500 polygons with persistent SAP until the framerate starts to die.

Also note that the above collision resolution isn't some seriously complicated physics thinger majiggly thing...ger... All it's doing is pushing the shapes out of intersection by changing the velocity instead of position. In the game, I'll probably just change the position directly instead since all that "extra" stuff is unnecessary.

RE: MFGG TKO DevLog - TheShyGuy - 01-27-2014

Devlog #5

Finally finished ripping Farseer out and Frankensteining the above collision system into the game. The results?
GIFS
[+]Spoiler
The green circles are the defensive collision circles. The red circles are the offensive collision circles. The fighting system collisions are separate from the level collisions so def/off collisions don't interact at all with the level collisions. The two are separate collision system instances.

I had this debug level done when I still had Farseer, but it ran pretty slow when I started to destroy blocks. It's nice to know that my own collision system is a step up in this case.

I'm still fixing bugs and whatever from the integration. One big thing that I'm having trouble with is rotating based on the ground slope =/. Hopefully I can fix it soon[Fixed]

RE: MFGG TKO DevLog - TheShyGuy - 02-01-2014

Devlog 6

The particle system now supports a BaseAlpha (starting Alpha), scale and offset "simulation?". Just like how position is affected by velocity which is affected by acceleration, scale and offset (and rotation) also have their own velocity and acceleration. In the gif below, you should now be able to see the brick pieces shrink as they fade. The smoke puff now offsets as it rotates which creates a subtle swirl effect.

GIFS
[+]Spoiler
I edited the camera shake so that it no longer lerps from the "shake" values. Imo it looks better.

Subactions now support multiple event Lists =O. It means nothing to you guys right now though heh. Basically, it just allows me to create parallel ... event lists ... for a subaction.

Code of the attack gif below in spoiler
[+]Spoiler
Which produces:

GIFS
[+]Spoiler
I also spent a good day or two doing some memory optimizing. Not much to say here. I just used a good ol profiler and looked for memory leaks and garbage and got rid of most of em. Animation datas are preloaded once, cached, and then deep copied (animations are shallow copied) when asked for. That means that I'll no longer load the same 900+ block animation datas for that block debug level somewhere above but instead just create copies for it which means faster loading and less garbage....

I also got the slope rotation stuff fixed... Not much to say.

Cam wanted scan lines so:
GIFS
[+]Spoiler
--------------------------------

Edit: Mit wanted to be able to do the hammer spin in air + a small boost:
GIFS
[+]Spoiler
-----------------------------

PS. -Everything- is placeholder. I'm still doing the core coding stuff. Once that's done, we should be able to actually 'start' the game and it should pick up speed a bit.

Comments are welcome. If you have any questions about how some things work on the coding side, I'd be happy to explain.

RE: MFGG TKO DevLog - TheShyGuy - 02-17-2014

Bugs are waves of fun.
GIFS
[+]Spoiler