XII

XII

Intro

"XII" (roman numeral twelve) revolves around the massive, tantalizing clocktower built in Yera, a land known by some as the "Land of Engineers." According to historical lore, the clocktower is home to massive stores of precious ore upon which Yera's technological foundation is forged and upon which the clocktower itself runs. To preserve this resource for future generations, the clocktower was granted a very peculiar defense mechanism against thieves and other undesirables:

When its doors open, any may enter and take as they wish of the ore scattered about the tower. But they must watch, for the clocktower remains open only until the midnight hour. Once the twelfth sound of the bell is heard, the doors close... and any still that remain inside are never seen again.

And so it remains to this day. Many Yera natives brave this tower still, titled as "Scout Engineers," and return home with the substance as their livelihood and as the continued lifeblood of Yera, for this ultimately was what the tower's founders had always intended.

You are one of those "Scout Engineers." Your objective is to acquire as much ore as you can in your tower runs. The greater your skill and strategy, the greater the reward may stand to be. But know your limits, or else your name may simply fade into the lore of mystery that surrounds the tower and its curious ways...

Game Overview

"XII" is a platformer that nods to the creativity of the "Endless Attack" mode in Mega Man 9/10. That being said, though the general concept is there, "XII" is meant to be quite different in many ways. I'm quite excited about this idea and I've managed to get a little momentum by actually using a little something known as PLANNING. I tell you, it makes quite a difference when you've committed to paper a more concrete idea of where you are going instead of throwing stuff against a wall and hoping it sticks.

"XII" works like this: you enter the tower, you collect goods, and then you GET OUTTA THERE. Its a game where planning and finesse are meant to take a bit more precedence over brute force, as this platformer doesn't necessarily behave like your traditional platformer. The game revolves around the looming time limit, and game mechanics are going to be built with an eye on that. Its not so much about surviving the clocktower as it is about escaping it. Those who take risks may find themselves reaping the rewards... or never being heard from again.

Features

So some tentative facets of the game:

• Players advance through a randomized series of chambers, much like advancing through screens on MM9/10's mode, by utilizing elevators. Different elevators can advance you a different number of chambers, which is important because the more rewarding (and challenging) chambers lie higher. As well, every 8th floor (or whatever number I end up finalizing it as) will also have an exit elevator that takes you back to the first floor. Plan accordingly and don't put yourself in a corner while short on time.
• The elements of the clocktower aren't necessarily about being impenetrable but about being time-consuming. Slip-ups may not cost you a boatload of health (more on that later) but may set you back fifteen to twenty seconds. In situations where you're pressing higher and higher, keep your cool and don't succumb to the pressure of the clock. Stay calm... one hasty mistake may not bring insta-death but may rather serve as the wary precursor to an impending demise.
  
• One of the key features of this game is the lack of a traditional health system. Your health, technically speaking, is infinite. Rather, your player has something of an endurance gauge. Sustaining "damage" is what lowers this gauge. As long as it is full, your player can perform actions normally. But if the player is subjected to repeated punishment from the elements he may incur temporary penalties, such as limping instead of running. Although the gauge recharges over time, failing to make the most of every second due to injury may not always be an option.

* * * * *

Well, there's a short preview of what I've got planned. Hopefully this gives you an idea of the sense of urgency I'm trying to foster with this game. The end-product is still a ways out, but I want to put this idea out here so I can start to generate interest and share some of the game-making quest with fellow devs.

Just remember:

Don't survive--Escape.

Well, Photon. Simple said:

Make. This. Happen. Please!

I LOVE the story.

Well, Photon. Simple said:

Make. This. Happen. Please!

I LOVE the story.

Thanks! Its going to be one of those things where the story kind of tells itself, a la loose arcade style storytelling. You have a minimal introduction of sorts to set things up, and then you're kind of left to empathize with the player character through interaction with the gameplay. I'm going to try and utilize some small but meaningful atmospheric touches as a result.

The game itself is progressing rather smoothly. I had a good chunk of time yesterday where I sat down and hammered out basic shooting and charge shots. More similarities between this game and Mega Man, but the charge shot is going to play a semi-important role in the game... well, because a charge shot has to be charged. And charging takes time. I wasn't kidding when I said I wanted strategy and decision-making to play a strong role in this game, and sometimes its the little things that go the mile.

Anyways, let's share! I know time-based behaviors can be slippery business at times, so I'll give you a look at what I have done to implement it so far; attachment below! Since there are some things like cross-behavior dependencies, I can point out a couple things:

• Bullet speed isn't set by this behavior, which is on purpose. The projectiles do that themselves.
• There is a getter function for the charge progress. This is because the charging animation or image is potentially going to be handled by an outside behavior.
• It may not be explicitly stated, but the bullet is placed by default to the right of the player, and then moved to the left side if that's the direction the player is facing. Why? Because I use the width of the bullet actor for spacing if on the left, which I can't get to using a "width of actor" block during initial creation. I don't need it on the right side though, so that's the default, and then width is available if I do indeed need to switch sides. Clever, no?

Onto damage and effect handling...

* SadiQ pokes in

A quick question about those timers. A do every x seconds block means that it will execute the content of that block while the game is running right? Wouldn't it be better to use a temp attribute that you increase it's value on every frame to replace that timer? That way you avoid timers and there's no un-needed checks in the game.

Edit: Cool...the forum added the poke line in red with my name in there hehehe

Could you clarify what exactly you are asking? Are you asking if the "Do Every X Seconds" runs indefinitely?

(And what do you mean the forum added that red line? )

Could you clarify what exactly you are asking? Are you asking if the "Do Every X Seconds" runs indefinitely?

Yes. Doesn't it run indefinitely? I know in this case there would be no problems if it would, but I just want to know

(And what do you mean the forum added that red line? )

I wrote: / me pokes in without the space between "/" and "me" and the forum turned it as you see it. It's something that was found in IRC channels when I used them, and it's not related to this discussion (just brought back some memories)

(And what do you mean the forum added that red line? )

I wrote: / me pokes in without the space between "/" and "me" and the forum turned it as you see it. It's something that was found in IRC channels when I used them, and it's not related to this discussion (just brought back some memories)

No biggie. I was kind of curious as to what you meant. Didn't realize you could do that! But back on topic...

Could you clarify what exactly you are asking? Are you asking if the "Do Every X Seconds" runs indefinitely?

Yes. Doesn't it run indefinitely? I know in this case there would be no problems if it would, but I just want to know

Nope. That's what the "cancel" blocks are for. When I make a call to the appropriate custom block, it fires up a loop. Once its done "counting down," I use the "cancel" block to stop the loop.

Oh. So the cancel block actually kills the timer. I guess there are always new things that one can learn about Stencyl

Oh. So the cancel block actually kills the timer. I guess there are always new things that one can learn about Stencyl

The cancel block saved my life in my early days of Stencyl. I always compared the do-every and do-after with Threads, but nowadays I learned that's not true

@Photon: Nice one. Thanks for sharing.  Have you already decided about the graphics style? As I completely lack design skills, I am stuck on ready-made retro-pixel-art unless I am ready to invest some serious amount of money into great art. I have colleagues at work who would like to contribute as they like my game designs, but they do their own projects as-well. *sic*

Oh. So the cancel block actually kills the timer. I guess there are always new things that one can learn about Stencyl

The cancel block saved my life in my early days of Stencyl. I always compared the do-every and do-after with Threads, but nowadays I learned that's not true

@Photon: Nice one. Thanks for sharing.  Have you already decided about the graphics style? As I completely lack design skills, I am stuck on ready-made retro-pixel-art unless I am ready to invest some serious amount of money into great art. I have colleagues at work who would like to contribute as they like my game designs, but they do their own projects as-well. *sic*

My plan was to focus on coding first and then art and music. I have some creative flair and I think I could make something work... hopefully. I'm not sure I want to leave ALL the art until the end though... I did that once and I felt low on motivation at that point (although the project in question was one I lost interest in about halfway through to begin with and from awhile ago.) I've kind of wanted to make my game design skills a bit more well-rounded though as I've worked with both art and music before.

At any rate, my plan is some sort of pixel art style.

So are you saying these colleagues of yours are looking for some "freelance" work?

So are you saying these colleagues of yours are looking for some "freelance" work?

No, the are professional full-time game designers and artists. But as we are colleagues and my games are different then the ones our company does, they like to contribute on the work of each other.

So are you saying these colleagues of yours are looking for some "freelance" work?

No, the are professional full-time game designers and artists. But as we are colleagues and my games are different then the ones our company does, they like to contribute on the work of each other.

Ah, I see. I wasn't sure if you were trying to drop a hint or something.

I'd planned on doing it all myself anywho. I think the scope I'm going for is moderately refined and within reason.

Boy, after all that positive energy that came from planning, I sure managed to turn around and make a mess of my damage and effect behavior.

I'd made a concise, somewhat vague list of what was effected, but I didn't get nearly into as much detail as I should have. And I probably should have, because there were quite a few details that I might have noticed beforehand had I paid attention. Ha... why didn't I see this coming? Haven't I seen this happen before? Anyway, the result was a disheveled, somewhat fractured behavior that works (?) but is going to be a bear to make further modifications to if I didn't know any better. In fact, I'm leaning towards redoing it. I can see more clearly where I messed up and what I missed initially, and if I go back to the drawing board and organize it a bit more coherently before committing it to the behavior, it'll probably be better off. Better to redo it now than to make more of a mess of it later. Anyway, you can take a look at the behavior for yourself attached below.

I guess the main thrust is this: don't ram the first few pieces of logic together haphazardly and then try to keep adding on the fly. You may quickly realize your unplanned rough draft, though functional in its own right, isn't built to play nicely with the other facets you have in the wings.

All right, a quick update about the previous week:

I got back to my normal-life schedule, but that didn't mean the work stopped. Mostly I was doing some more planning and design stuff. I'd like to have a bit more to share there before I go into too much detail though.

Also, I may be going for vector art instead of pixel art. I tend to find pixel art frustrating if I'm not doing small scale stuff. It may just be a matter of inexperience, but as it stands I'm just not sure I have the time (right now) to really invest in sharpening my skills there. On the other hand, I can sketch with pencil and paper adequately well and the line/shape-based nature of a program like Inkscape has had a certain appeal to me. I finally gave in and downloaded Inkscape and I might see where that goes. Who knows? Its still early!

Today I've got something about the planned stat system.

Using the ore found in the tower, my plan was to have you be able to upgrade your character. I was thinking simple stuff: jump height, dashing speed, hazard defense, etc. I didn't want the changes to be extreme because I wanted to avoid making the player feel nerfed at the beginning of the game or, at the very least, not have to get very far to get up to speed. In short, I want to be careful not to make this look like a silly addition or lame "artificial lengthening" ploy to the game.

And at first, I was thinking about a linear level-up-per-stat system where you could just apply ore and boom, stronger stat. But since the changes were meant to be slight, this limited the number of levels greatly pertaining to a level cap and ultimately this just felt shallow. This idea was part of my attempts at reinforcing the value of ore collection in the game, but after consideration it just didn't seem as strong as I originally thought it could be.

Today, I got hit with an idea: what if the player had to choose one stat over another? Like power versus defense? This seemed to make more sense and played into the strategy aspect of the game that I wanted to bolster as well. But then what about balance? What if you want to strike a happy medium between power and defense?

Which lead me to the current idea I have mocked up below: slide bar stats. At the beginning of the game, you start with a small bar that you can slide around into different positions so long as its still occupying the baseline. It starts small but can be upgraded with ore to cover a larger area. This seems to make a lot of sense. I don't plan on allowing the player to grow it to the entire length of the field, so even when the area size is maxed players will have to think about which stats they want to favor. On the other end, it doesn't rule out dipping into the opposite stat.

Besides, who doesn't like some good 'ol customization thrown in the mix? Hopefully I can balance this and make it work out for the better.