next »

[Juskelis]

Hey all, Modern Man Championship is a game I've been sitting on since last August.

-DEMO-

The premise is simple: kill the other person before they kill you. Specifically, kill them seven times before they kill you seven times. You're both samurai-ninja-sword-jumpy types who have a craving for everyone else to be dead. The story is coming. You each have a sword you can swing and block with. If you're particularly saucy you can even throw it, but we don't recommend that. You have to go pick it up and brush the dirt off of it. That takes time, time that can kill you. Most of all, the player can dash, seemingly through magic, or something. We don't really know. Point is, you can propel yourself in any direction whenever. That's pretty nice, and can definitely kill someone if you aim it at their head. It'd kill me, that's for sure. Then again, all of this would kill me. I'm not athletic.

Here are some various art assets, in no particular order.

Here are some artistic inspirations for the art.

These guys are thematic inspiration for the game: a sort of modern samurai thing, like a championship. I don't know. Mid-new tech and old tech; blackberry bushido, or flip phones and swords, stuff like that.

These are the actual aesthetic inspiration for the game: washed out wooden colors for non-important elements, and neon for the important stuff. Like a hazard vest, being bright and obnoxious makes you noticeable.

You might be thinking that this art looks great, and my art does not. I noticed this problem too, and I'm trying to remedy the situation, but sadly my brain resides firmly in "bad at art" land, and all my relationships with people in "good at art" land haven't worked out. My dad always warned me about long distance relationships.

Modern Man Championship has come quite a way, and honestly I should've been posting about it the whole time. But that's water under the bridge now, so here's what I've been doing.

Modern Man Championship started as a dinky little game called Ugh. It was started as a practice for really good movement, quickly followed by Argh. Both Ugh and Argh were basic "hard" (bad) platformers, meant as a playground for a movement system. At the same time I was watching Samurai Champloo, and saw this:





I needed to make that into a game, somehow. I'm not good enough to make a 3D experience that could live up to that, but maybe I could do 2D? Thus, the first phase of MMC was born: Champloo.

Made in GameMaker: Studio, Champloo was a space to prototype out all of my ideas, and eventually blossomed into a nice demo. The movement system is about as ironed out as it will ever be, while the combat mechanics are able to stand up for a half hour. One of the big things that I wanted to do was create a depth of combat without mechanical difficulty. One of the ways I did that was by having the aiming of attacks tied to the movement stick. I'll go more in depth on the design decisions as we go, but ultimately that's not enough depth.

All throughout the process I was getting design help from a friend who is heavily invested in the fighting game community. He started feeding me ideas of higher complexity and deeper designs and I bit the hook. Sometimes I regret this, but ultimately it was for the best. Eventually I decided that we needed more than just two identical players duking it out with the same swords. It gets pretty boring after a couple rounds, so the pregame meta should help combat that. After sitting on that for a while, I came across stories of other couch game devs having trouble getting their titles off the ground, because only a fourth of their audience would actually buy the game. Well, I couldn't have that! I want to see what I can get away with, so online multiplayer is a thing, I guess.

GameMaker can handle hierarchies of players with wildly different mechanics, kinda. GameMaker can handle UI, kinda. Not really, but lets pretend. GameMaker can pretend to handle networking, but I know better. All three at once? Well, let's reconsider this whole relationship, GameMaker. I really don't think you can grow in the way I want you to, and I'm at a pivotal point in my life where I need to make sure I do things right and I can't worry about getting you to cooperate with what I want. I'm sorry, it just isn't going to work.

So I'm seeing someone else now: Unity. It's nice, but there's some late night texts to GameMaker still going on. You know, the usual "I miss how you handle input" and "I love how you treat scripts like these nebulous methods that I can just insert anywhere" and "your surface system was so nice in the moonlight." I've been moving on to Unity though, and thus bigger and better things. I have hierarchies, UI systems, animation systems, networking, and so much more. I've never been happier.

This is Modern Man Championship, and I'll be updating this place as things happen, or as I find old forgotten gems regrets.

Hope everyone likes it!

edited to compensate for the Preview button's lies about sizing

[tankorsmash]

Good luck with this man. Do you have any gifs of your exe in action?

[Juskelis]

I could make up excuses for why I forgot GIFs for a very action packed game, but I simply forgot.

I put some in the first post!

[Juskelis]

Alright, time for some more technical stuff.

GameMaker and I had a falling out, but I miss some of GameMaker's sweet nothings, like the surfaces system. So instead of forming a healthy relationship around acceptance, I instead decided to force Unity to change into what I wanted. Particularly, I wanted blood to paint the walls when I killed someone, in spectacular fashion.

Eventually, I got to this with Unity:



The way I did this I can only explain as buffoonery. The first step was to get blood flowing, which was just giving the corpse a dinky little particle system of squares. Like I said, I wanted to emulate the GameMaker version, and looks are everything. Next up was finding some way to draw over a texture repeatedly.

My first thought was to do it the same way as I did before: directly drawing to a texture when colliding with a particular object. However, this was slow in Unity. The GameMaker surface system is set up to do quick access/modification by making some assumptions. Unity didn't want to assume anything, probably because it heard that ass out of you nonsense in middle school. Don't be dense, Timmy; assumptions are the backbone of civilization.

I needed to find something else. I knew from previous shenanigans that cameras can achieve the same effect if you just don't clear the screen, like this:



Now, if you're thinking that gee, that looks glitchy, why would anyone use that, then you'd be more aware than I was at this point. Stupid past me continued on, oblivious of this problem. I decided to take the camera output and render it to a texture, as a test of whether or not this would work at all.

This test would break me.

I started trying to render it to a texture, and I found not even the above, but this:



Unity, if told not to clear the camera, and render the output to a texture, will do one of two things:

• allocate the texture, clear it out, and render the first frame
• allocate the texture, and render the first frame

The difference is minor in code, but produces very different results. Since Unity chose the second option, the texture has a bunch of garbage memory in it, so Unity will just pretend that its right, like a dog sitting next to a chewed up shoe like nothing happened. It knows what it did. It understands. Don't give me that bullshit.

Eventually I figured this out, and that I need to manually clear the render texture myself. I did that, and got something that actually looked perfect:



At this point you might realize that this keeps going, so something must be wrong. Oh yes, something IS wrong. At this stage, I was pretending that I could do all of this with one single camera, and one massive texture. It would be static, and I had already set up the shaders so that it would only draw on ground. The problem though is that I want moving platforms.

Moving platforms would not look right with the "one camera for all" solution. As the platform moved, it would move through the texture, and the blood on the platform would shift around and look terrible. So, there's only one option:



more cameras.


Yes, I gave each platform a whole setup. I set each render texture to be the same aspect ratio as the object it represents. Since each camera copies the ratio of the render texture, each camera only renders blood splats when they are overlapping their platform. My shader was useless. Oh well.

Yes, I could have used one camera for the static objects, but honestly this is a more memory efficient approach. In the "one for all" solution, spacious levels would have a lot of wasted space, and thus wasted memory. Here, each texture only allocates what it needs. It isn't pretty, I guess, but it works.

I'll be posting about how I do the game camera soon too. It nice.

[Juskelis]

In order to be a good same-screen multiplayer game, you have to decide how that screen accommodates all of the players. You can set it up so that the screen covers the entire level, like in Towerfall:

The nice thing about this is that I can do some neat tricks with wrapping, as well as allow for crazier/more intricate levels. However, for large levels, this gets out of hand:

One of the first things I discovered with MMC is that its hard for players to locate themselves when the camera is static. I also knew that I wanted to allow myself more creative freedom* with each level. In short, I didn't want to be constrained to a fixed size.

Thankfully, Super Smash Bros has a really nice way of handling all of this with their camera! Their camera includes two rectangles: zoom in and zoom out. The zoom out rectangle is about 80% of the screen size, while the zoom in is closer to 40%. At the end of each frame, the camera quickly lerps to the average position of all the players, and finds how far the furthest player is from that average. If the furthest player is outside of the zoom out box, then the camera zooms out. If the furthest player is inside the zoom in box, then the camera zooms in.

If you play with the box values right, then the camera will only zoom when it needs to zoom, keeping a stable camera while showing all the players the best it can. It looks something like this:

[Juskelis]

Hey ya'll

Not a whole lot visually changed since I last posted about MMC. PAX happened, and then I decided to refactor not one but two systems! I revamped the collision system and implemented ReWired for the input system. So far, both have been working better than I can imagine, even though I'm literally looking at it. Who knows.

Since this world loves GIFs though, I needed something. Thankfully, screenshake isn't too hard to implement and looks pretty sweet:





I'll be back soon with more nonsense! Specifically, I'm going to be spending a lot of time now on getting ONLINE MULTIPLAYER working. We'll see how that goes.

[io3 creations]

I like the idea so far.

However, Modern Man reminds me something more along the lines of: http://www.nytimes.com/2015/10/02/fashion/mens-style/27-ways-to-be-a-modern-man.html

Since the game is primarily about combat, perhaps Modern Warrior Championship or something along those lines would be a better fit.

[Juskelis]

Thanks for the feedback! The title is definitely still in the works; we haven't really found something we're actually happy with yet.

Development has been going decently so far. I got my comeuppance for refactoring so much directly after PAX by getting pretty sick. I spent the time in bed by reading up on Unity's Networking solutions, and I'm at a crossroads: either create two separate solutions for online/offline, or somehow figure out how to combine the two into one system. On the one hand, creating a whole separate set of classes to handle online seems like overkill. On the other hand, I have little to no idea of how to combine them that doesn't involve excessive #if clauses. I might just iron out a little bit of the current version and throw it on here to gauge feedback.

To sum: name pending, and online too.

[Juskelis]

So I had a meeting with my designer friend and my music friend. The first piece of news is that we have a musician!

HimeHime is the musician that will be working on this project with us. If you want to check out his stuff, go here: https://himehime.bandcamp.com/

There's a lot of goodness in there, and it fits very well into our theme. Speaking of which, our theme has shifted slightly from where it once was. Previously, we were aiming for a 90s-2000s tech mixed with ancient japanese weaponry in a neon aesthetic. The visuals were, in short, vaporwave with swords.

Now, neither I or my designer friend were too keen on this, not for any particular reason. It just didn't wake us up in the morning if you know what I mean. Anyway, we wanted something we could be more excited about, so we started talking and ended up canning the concept and going with something simpler: everyone but the playable characters are normal people from the 90s-2000s. The characters, however, are going to be the crazy, out of place weirdos in this world, who can for whatever reason fly.

The reason for this change is twofold: one, we didn't want to try to explain the whole concept of old in new so much, and two, we wanted to shift away from particularly Asian influences. Don't get me wrong, samurai and swords and shit are great, but there are a lot of those games out there. So, we got rid of it.

One of the inspirations for the new character idea was the old Metal Gear games. The characters and events that take place are crazy and absurd, but everyone just kind of accepts it, similar to magic realism. The plan for future characters is to design a central mechanic, similar to old Metal Gear bosses, and then build the character around those. Hopefully, the characters will be interesting to play as, and have a bit more freedom for flavor than otherwise.

Artistically, we still aren't 100% sure what we want the final visuals to look like. Kentucky Route Zero was mentioned, as was lowpoly PS2 games, but we're not sure. Thoughts?

[io3 creations]

Artistically, we still aren't 100% sure what we want the final visuals to look like. Kentucky Route Zero was mentioned, as was lowpoly PS2 games, but we're not sure. Thoughts?

I can imagine your game with many different styles.  I'd say, the more important part is for such an action game is to have fluid and dynamic animations and (likely) lots of relevant visual effects (blood splatter, blade sparks, "speed lines" and/or dust when moving fast) - the over the top action in John Woo movies comes to mind.  You could also have destructible objects in the background: vases on shelves, glasses on tables.  Normally, players wouldn't be able to interact with these, but a sword swung nearby could break those.  Also, the floor could break if a character lands from a high place.

[Juskelis]

I agree, there need to be a lot of visual reads for all of the actions, and to have everything important stand out from the rest of the environment. There are a bunch of visual flair things we could do. I honestly haven't thought a whole lot about the visual polish elements, mainly because I haven't pinned down the visual style yet.

[Juskelis]

I'm back with a very boring post about implementation nonsense!

Just wanted to post an update about what has been happening code wise. First off, I've been spending the past two ish weeks working on getting multiplayer working in Unity. The short answer is that I have peer-to-peer working if you're comfortable with port-forwarding or even can port-forward. The long answer is that Unity's networking solution is really geared towards using their relay servers. Part of this is due to wanting money (duh) but also because a server is pretty much necessary no matter which model you're using.

Thankfully, Unity's solution can still be testing in LAN, so I know that conceptually the system works as intended. Unity even provides their own Lobby solution and framework! Configuring the architecture was surprisingly easy to do.

However, getting a true internet solution with Unity's Multiplayer is going to cost a little over too much money, so I'm trying (and failing) to find a free alternative. My current prospects are NAT Traversal or throwing in the towel. At the moment, I'm taking a break from networking to think it over and pursue the actual gameplay.

Speaking of which!

I have my resident lizard man working on getting a more flexible player movement system into place. When I implemented the current solution, I baked the movement special into the design as just dashing. However, we want to be able to add our own options too. Since the system already uses an FSM based approach where each state handles the actual movement logic, the refactorings should allow us to have wildly different ways of traversing the levels. At the moment we're planning on keeping the basics set in stone (ground, air, wall, etc) but allowing the special to be whatever we want.

[freank]

A good start !

[Juskelis]

Thank you!

It's been a minute since I've posted, mainly because I started working for the man and man is it exhausting. Anywho, the lizard king has made quite some progress on the movement system! Really excited for what it can bring to the table. As for me, I've mostly been a corporate zombie, and haven't gotten much of anything done.

The current tasks on the table are to fix some movement bugs, add the ability for players to customize their characters, and to figure out what to do at the end of the game. The local solution gave the players the option to restart the level or quit back to the main level. However, I'm not sure how to handle this in the networked solution. Granted, I haven't looked into it at all yet, but it is a non-trivial change, since the previous implementation didn't work.

[TomHunt]

Looks cool!

[Juskelis]

Thanks!

I updated the demo link to go to the more reputable itch.io page. Figured it was time to stop using the equivalent of alley trench coat distributor

[Juskelis]

Alright ya'll, I'm back after a long time.

Some stuff has happened, yeah? Lotta stuff has happened. A nice one is that we have an artist! Hot dog! Here's an early concept of the main character:



In other good news, my part-reptilian ally has been mustering his energy to fix weird collision bugs in the main game as well as tweak numbers so that things feel right again. So far the game has improved by a few tactical, precision tweaks to speed and timing. None of this can really be conveyed through pictures so I'm going to forego the process of creating those GIFs. Visually, the game has yet to change in the core loop.

What has changed visually though is that we've added a lobby system of sorts. Here's what the first pass at player selection looked like:



Since this game is largely controller only, each player presses start to join in, and then selects their character.

And now for the not so good news: making this game online-ready so far has been a failure. Technically you can play this game over two machines, but in practice there are a zillion and five things that didn't come together right. From the almost instant desync issues to the need to port-forward, networking is going to remain a hidden feature for the time being. There are a lot of reasons that this didn't pan out, but I think the most important one was that I underestimated the task. Since I did that, I didn't plan out the transition properly, nor did I research as thoroughly as I should have. Lack of planning and research led me to take the easiest solution, which turned out to be the absolute worst decision in this case, which I didn't realize until well into the process. Ultimately, much of the past few months have been spent retconning various poor decisions and slapping band aids over literally everything.

Thankfully I made it a point at the very beginning to allow the net code to work locally as well, so none of my work is "lost". However, a lot of it isn't really being used fully. At the moment, a lot of the game is running as a "mock" networked experience, which is a little weird.

So whats the plan from here?

I'm pivoting back to the core loop, fixing everything so that it works cleanly in local multiplayer. One thing I will continue to do networking wise is testing the game on two separate executables, just to make sure that when we do try this again, we don't have to rehash old code again. After we're satisfied with the core loop, I'm going to do my research all proper like and implement the networking all proper like. Right now I'm planning on using NAT traversal so that players don't have to deal with relay server lag.

Oh, and I'm planning to post more here too. I miss you guys.

[Juskelis]

Now that I'm not doing networking nonsense, I'm going to try to post every saturday. We'll see if that pans out.

This time around, we did a lot of minor improvements which aren't well screenshotted. Stuff like correcting the wiring for stuff, fixing weird bugs, revamping code, etc. However, we also upgraded to Unity 5.5!

One of the main things that 5.5 gave us is nicer particle systems, so I figured I'd add some nice effects to everything.

Started off with foot dust:


Figured we could do with some weather effects too.

Rain:


Snow:


We've also started work on adding sound, which I can't screenshot either...

[Pineapple]

Is the art of hammer plus the art of the modern man's manhood?

[Juskelis]

yes definitely