If you read the posts about the previous updates, you’ll know there’s been some problems. The first one had some issues because of EFS, and the second one was a victim of a library upgrade. Now this is is an actual playable release, yet it doesn’t have more features than the EFS one.
UPDATE: major bugs have been found. previous demo is still the most valid. The new update is still there in case it helps someone help me.
Some reported filesystem exceptions with the previous release. Now, I’m using the latest (last) PAlib and NitroFS. EFS is gone for good. Maybe it works now.
You may test it. Works on NO$GBA for sure, though.
Other than that, it’s the same thing as before.
Of course I did. Because I finally came up with a z-sorting function for the sprites. Seriously, that was complicated, and probably the current one needs adjustments.
This release is less focused of the 2.5D engine (I learned that name the other day!), so you might want to check the engine peek 5 if you haven’t, because it’s awesome to understand the 2.5D engine I’ve implemented.
Since I removed the intro script where I explained the controls, let’s do it quickly:
While moving:
pad to move, A to jump (or double jump), B to interact (this is new. stand in the purple square and you will be explained), X to switch to tofu frog, Y to switch back to Pol. L to use the favorite item (if any). Start to pause and set the control to the GUI. In GUI, left or right to select a menu. Up or A to select it. You can also touch them for more quickness. anyway, only inventory works.
While on inventory:
A to use, X to toss, Select to change an item’s position, and L to favorite an item. You can also use the touchpad, touching the corresponding tabs. Some items don’t allow certain actions. Just so you know, the actions for Y and B aren’t implemented yet.
To begin with, it has the logo at the beginning which is cute.
And then, well, objects can now be cuboids – previously, they all were cylinders.
You can transform into tofu frog, a character that will be in the game. it walks by hopping and can also jump high
GUI. You have an inventory – currently full of apples.
Events: signposts, floor events and NPCs. Walk into the purple block and read instructions.
And more that you can check by downloading and playing.
Of course it is. So here’s the download link again. Please comment with suggestions, bugs, etc. You know the drill.
ALSO, I ONLY TESTED IT ON no$gba AND IT WORKS ON IT
Because it’s been a month since I touched Tanuki Tail. Today I took a look of what I was working on and maybe I’ll release a demo when I fix something that is quite wrong and has me a bit puzzled, which is the Z-sorting of sprites. It’s quite more complicated than one may thing at first sight.
Once I do that, the next step in the game is challenging. PAlib seems to be dying, EFS sucks… time to quit PAlib and port everything to pure libNDS and probably NitroFS. THEN I’ll work on game features. Like VIOLENCE. It’s a pending subject but very necessary.
Because I said I was going to do stuff and I haven’t done them. Other than that I’m a very honest man. Honestly.
Lately I was thinking about making another game, alongside to Tanuki Tail, maybe a turn-based RPG (with a simple map engine, based on block-to-block movements like in pokemon). And got some ideas watching this video.
Maybe you know, maybe you don’t (probably the latter), the texts in Tanuki Tail, so far, are sprites. (for example, in scripts). These sprites are created and deleted dynamically, and every time a character is created, the 16 pallete is applied, id est, the sprite is built in the time it’s created, from a base sprite, and then added 16*palnumber to each nonzero byte, to get a different “row” on the 256 color palette. These are the most flexible texts and they’re used in scripts. They work good on it because there’s a delay between each character creation.
The problem with these is that they’re slow. Without delay, you’d be creating about 60 sprites in a row, which doesn’t sound like a good idea. That’s why, in the inventory, I use a variation of those fonts: a fixed number of characters are created and put away from screen (this also implied changing a bit my sprite system, because otherwise that would mean to delete the sprite), with the palette applied beforehand (the sprite source is copied and modified before creating sprites with it). Since the Font class manages two arrays of characters, this second approach applies two palettes, one for each row. I use these to show the item name and description, so the item name goes in one color and the description in another. Classy. Anyway, these fonts aren’t as flexible as the first ones. They are to be used when I want to print a single text that won’t change color.
But then I wanted to show pop up boxes, to ask the player to confirm the use of an item, or to ask how many items are to be tossed. And since the inventory GUI is quite complete, I have about 110 sprites on the bottom screen. (I had about 120, but modified the function that shows how many items of some kind you have to build the sprite out of three digit, instead of creating three sprites of one digit each). So if I wanted to make boxes with text, I had these options:
-Make a background, and then a text background to show the ugly tiled fonts. yuk.
-Make a background, and then an 8 bit background to put text on it. Seems expensive
-Make it all in a single background BECAUSE THAT’S WHAT A TRUE MAN DOES
So I got the third option because of my astonishing manliness. From the same font sprite file and width data as before (in fact, the first step is creating a common [1st approach] Font class object), and a 10 tiles tileset (blank, inside, top left corner, top side, top right corner, left side, right side, bottom left corner, bottom side, bottom right corner), I create a tileset containing my desired text. I print each string over copies of the “inside” tile, and attach them to the original tileset (a copy of it), and then build the tilemap depending on the amount of text and its length. Then there’s only the need of one sprite, to be used as the selector, and do the selection logic (also stylus support). In the case of numeric questions, the number of digits is a parameter, and sprites for them are created, through a quick font [2nd approach]. The maximum possible width of the numbers is taken into account for the size, and so is the width of the current number shown, to center it. Here’s the result (with a placeholder tileset, that is):
The only catch is that the tileset must use the font palette, but this isn’t an inconvenient, since the palette is quite complete in colors, and there’s a lot of unused color slots (for example, the first color in each 16 color row, because that’s supposed to mean transparent to fonts.
The current implementation allows up to 9 options, with the only restrain of fitting into screen. The box is centered and since it’s built in runtime, it can be of any size.
There will be a new release soon, probably, or probably not, so you can play with the inventory GUI, interact with stuff on the map, and some stupid things like jumping like a frog. EXCITING ISN’T IT?
If you’ve studied computer science or something related, at some (early) point you should have learned about data structures, specifically lists, queues and stacks. If you haven’t, you’d only have to learn that a list is a list, a queue is a queue (first in first out) and a stack is a stack (first in last out), that contain elements ordered somehow.
In Tanuki Tail, I’ve implemented the three things as linked lists with no header, that hold 4 byte data. This is conceived this way so you can use that space to store a pointer to anything. These lists implement insertions and deletions in the top and the bottom, as well as searches (with a comparison function parameter) and deletions in the middle, making the lists being able to work as stacks and queues. In fact, they started as stacks (for scripts), but found out that at some point I needed to ‘peek’ inside the stack.
But, this is barely exciting. What I actually wanted to talk about is todolists, which is a type that I’ve surprisingly implemented with a list. TO-DO lists. They behave like a queue, and their purpose is to add simultaneity to graphical events.
The point of this is to create graphical events atomically. So, instead of:
void slide(Bar* foo, int to, int step)
which slides it to to with a step step, you’d have
int slide(Bar* foo, int to, int step)
which approaches it to to with a step step, and returns whether it is in to or not.
And whenever you want to slide foo to to, add the task (slide,foo,to,step) to a given todolist, and before the VBL, call function todolist_run on that todolist.
The todolist tasks are stored in structs that contain a task identifier (enumerated) and an array of int parameters (up to 5, which should be enough to hold most tasks (and if it’s not, there’s always the possibility of storing the parameters in an array and make the associated function work with that array). When adding the tasks, I generally cast the type todotask over an array of casted ints, for example:
todo_addTask(&todo2, (todoTask) {DRAGSPRITEV, {(u32)actionButtons[5].sprobj, 152, 5}});
(actionButtons[5].sprobj is a pointer)
And then the todolist running function does this:
case DRAGSPRITEV:
if (DragSpriteV((SpriteObj*)task->parameter[0], task->parameter[1], task->parameter[2]))
todo_addTask(todo,(todoTask){DRAGSPRITEV,{task->parameter[0], task->parameter[1], task->parameter[2]}});
break;
In other words, makes a sprite approach a spot, and if it’s not done, enqueues the task for the next time you run the list. Actually, the way it’s designed it’d be possible to call any sort of function and use any kind of criteria on whether or not add a new task, and what kind of task to add (for example, I could have done todo_addTask(todo,(todoTask){DRAGSPRITEV,{task->parameter[0], task->parameter[1], task->parameter[2]}+1}); and make it slide faster and faster with time.)
So, how does it work?
Whenever the running function is called, a task with type ENDOP is added. Then, the elements are read in order, and a switch statement is in charge of doing the logic for each task type case. If they generate new tasks, they are placed after the ENDOP task. Finally, as you may have guessed, the ENDOP task in the end operation task which ends the task operations. Its purpose is to place mark that separates old tasks from new tasks.
There’s a global todolist, but it’s possible to create new ones. since lists are defined as pointers to the first element, doing todolist newlist = Empty_List32; is enough to create a new one with a correct initialization, and no data is allocated (so there’s no worry about freeing it). I’m using this, for example, in the inventory menu, to control some buttons independiently from the general todolist, so I can check if all tasks are done by checking if the list equals Empty_List32 (== NULL). I’ve also put a task that runs a given todolist, which may bome in helpful in places that only use the general task and you want it to run more than one list.
I’ve also added the possibility of erasing all tasks of a certain kind, or all tasks of a certain kind with same first parameter (for example, erase all tasks that move a certain sprite). This is very needed when doing opposite effects (for example: gradually setting screen brightness, first darker, and then cleaner. Every cycle, they negate each other and no effect will be seen. Also, if you’re waiting for them to finish, you get an infinite loop (true story)).
If you’re a fan of simultaneity, you totally should implement something like this. It’s easy and once it’s done, it’s quick to add new tasks. This could have other uses. In short, it’s “a queue of self-filling parametrized actions”. Sky is the limit.
In the released demo, you can see the todolist effects, for example, when you run the script right in the beginning, and the health and stamina is charging while the script is being run.
WinterAce asked so I answered and here’s how the logo looks so far. The background of the logo is and will still be white.
And the animation is somewhat this, although the timing and frame length is not exactly the same.
In case you’re going to imitate it: it’s /baro/
I’ve just made a movement type that moves by jumping. A frog, to put it easy. I could make a frogger level in the game. Heck, I WILL put a frogger level in the game.
In the programming part of the game, I haven’t been done nothing relevant lately. Fixing things here and there and rewriting the map creating function only to be rewritten when I do the map creation tool.
I’ve been doing some sprites. Front views of some characters, specially the demons. This is useful because it helps me realize what I should implement.
For example, check he big one. He’s 52×58, so its sprite will be 64×64, which is the maximum size allowed. All the animations will be limited to that square. Not too hard, but, is this the bigger an enemy can get? Answer is no. Bosses will be bigger. Probably other critters can be bigger. It’s easy as pie to associate each character with two different sprites, but I’m debating whether it could be a better idea, at least in some cases, to make enemies that are formed by various enemies. This is common in bosses in most games out there. Then I remembered that first designs of that big demon include a comically big hammer. So I could make an enemy that “carries” another enemy which is his weapon, and doesn’t collide with him (or with anything at all and just “harms”). I could go talking all day but well, the point is that design is going along and each aspect of the design helps in the design of the rest.
I’ve been writing the “script” of the game. nothing much to comment here, I’ll drop one of the scenes from the introduction, which will also work as a “tutorial of the basics
-> PLAYER JUMPS THE BOXES AND REACHES THE INNER SIDE OF THE GATE
>>The gate is a double door. Between them there’s a gadget that opens it.-A lizard follows Pol. Pol looks at it. The lizard stops and then flees
POL: “And now… I am a Trojan Horse”
BARO: “Interact with things by pressing B. Try that gadget on the wall.”->PLAYER DOES
POL: “Hello there! It’s me! Open Up!”
JULIE: “Pol… come on, don’t act so cool. It was me who wrote the code that is opening the door.”
USUI: “And I built the AkiPad you’ve plugged in the lock.”
BEAR: “You just plugged it in the wall, bro…”
POL: “Come on, guys, Let me enjoy this!”
COMPUTER: “SYSTEM EXCEPTION : UNIDENTIFIED SCRIPT”
POL: “Ouch, I think it broke.”
BEAR: “Y’know what I’d do, matey?”
POL: “Punch it?”
BEAR: “I would sooo punch it!”
USUI: “Nooo! Don’t!”
-pause
USUI: “The poor thing!”
-music stops. longer pause. music resumes
POL: “I love my job!”
BARO: “Pol’s specialty is not punching, but you can give it a try by pressing X”
->PLAYER PUNCHES THE COMPUTER LOCK
- Doors open
Yep.
I call those engine peeks because not much of the actual game is there, so I can’t dare call it a demo. It’s a show on how things are going. Usually when I posted those in PAlib forums I had to give some explanation on the controls, so the fact that this is my first release able to explain itself makes me very optimistic on the progress of the game.
There are no known bugs or glitches, so if you catch anything suspicious, plox let me know. Just in case, the only menu that opens a window is the items (cap) one, and yes, it’s currently empty.
YOU WANNA DOWNLOAD I KNOW THAT
Soon I’ll upload a small engine demo so you can see how good -or bad- Tanuki Tail is so far, when I get an stable program. Right now I have a super weird and illogical problem that makes the game stability depend on the amount of code and not on how good it is.
Meanwhile…
When I started coding, I found that the PAlib functions for animations were very limited. They have two major problems:
- You don’t chose the frames: you go from frame A to frame B and that is
- Each frame stays the same amount of time.
So I decided to create something I’ve called “Integer Compressed Circular Queue”. Integer because… well actually right now I’m using unsigned bytes, so it’s not actually integer. Compressed because I represent sequences like [4;4;4;4;4;4;4;4] as [(4,8)]. Circular because the next element after the last is the first. And Queue because I can, because you can’t actually enqueue, and dequeuing doesn’t exactly remove the element, just moves to the next one (from another point of view removes and re-enqueues it, since it’s circular).
typedef struct //IntCompCircQueue
{
u8* items; //elements
u8* amounts; //items[i] stays for amounts[i] loops
u8 label; //used to identify the queue's contents
u8 size; //first is always 0, ans also the next to the last. last is size-1
u8 iterator; //current element
u8 counter; //in each element, the current repetition of that element
u8 maxrepeats; //maxrepeats == 0 := infinite LOOP
u8 repeats; //counts to maxrepeats
} IntCompCircQueue;
The point of this is that it’s useful for animations. “items[i] stays for amounts[i] loops”. Or, frame i stays for amounts[i] cycles. For example, for a three frame animation where the first frame is number 4 and stays for half a second, second frame is number 9 and stays for a second, and third frame is number 1 and stays for one tenth of a second, you’d create a IntCompCircQueue with items {4, 9, 1} and amounts {30, 60, 6}, and every cycle you set the frame of the sprite to whatever item the IntCompCircQueue considers next. They also have some control on how many times the animation is repeated (including infinite), and if the ICCQ finds an amount of 0, it’ll also stop. In such cases the next element is the current one.
Furthermore, the icq_next function returns a struct with both the item number and a boolean that is true when the queue is over, so next cycle you don’t bother asking for the next element, since no changes must be made.
To build the ICCQ, you create an empty one and fill it using a data type that includes the amounts, icq_QueueData. The “constructor” (I’ll talk about this in following posts. This is C, but I use OOP techniques.) of icq_QueueData retrieves size, number of repeats and all the data from an array of bytes. This way, I’ll be able to build the sprite animations easily from files, and then create a tool to easily create and modify them.
This is used for sprite animations, but could have other uses. I have plans on using them for map animations (just have to come up with a way to organize what tiles are to be animated, and keep a reference to them when building the map). I’ve recently used this for a palette animation too:
//Create a pallete animation for the sprite
const u16 colors[7] = //Red -> orange -> bright yellow
{0x001F, 0x00FF, 0x011F, 0x023F, 0x033F, 0x037F, 0x03FF};
icq_QueueData* iqd_pal =
NEW_icq_QueueData((const u8[26]) {
12, icq_INFINITELOOP,
0, 1, 2, 3, 4, 5, 6, 5, 4, 3, 2, 1,
3, 2, 2, 1, 2, 2, 3, 2, 2, 1, 2, 2
}
);
IntCompCircQueue* icq = NEW_IntCompCircQueue();
icq_fill(icq, iqd_pal, LBL_ARBITRARY);
And then I just change the color with PA_SetSpritePalCol (SCREEN_DOWN, 29&15, 31, colors[icq_next(icq).item]);.
I’ve also been drawing, as the been drawing epigraph suggests. These are the characters I’ve spoken of in the story post. The sprites are to be used in dialogs, I have drawn many more but are either variations of these, or the same four characters in different poses. From left to right: Pol Keine, Julie Bourge, Bear Sampson and Usui Akiyama:
Since I’ve already talked about the engine in my first, long post, I’ll talk a bit about the story before getting deeper in the engine.
I warn ya, this post will be a bit hard to understand because the story is messy.
Also, if you are a religious fanboy that doesn’t believe in evolution, you may not like points of the plot.
You are Pol Keine, a dude who has a tail from a dead anthropomorphic racoon person from another universe, which lets you transformate into a variety of things, namely stone, cannon-hands, frogs, birds, chameleons, bulls, bear-gods…
In year 2548, the Earth is different from what we know now. One day, a tyrant decided to bomb Middle East, supposedly as a solution to the wars in that are, which got really out of hand. However, the bomb used caused a so big impact the continents moved and rearranged, destroying almost all civilization in the process, as well as many animal species like -it seems- bears. After that, that tyrant took on the world and became the ruler of all survivors, and it was like that for three generations. Now, his grandson, current world dominator, is making a bomb similar to his grandfather’s, for unknown reasons, and a troupe of youngsters from the city of Lowheaven are trying to sabotage it. They are:
Julie Bourge: expert in software
Usui Akiyama: expert in hardware
Bear Sampson: expert in tupperware, and a very strong young man.
Pol Keine: dude. Wears a cap. He’s also you.
But one day, during one of many stealth sabotage mission, something goes wrong: a strange being captures Pol and when he wakes up the next morning, he has a racoon tail. Turns out that the being that captured him is a racoon-person (also called Tanukis) from a universe where instead of apes, racoons evolved to be intelligent. The tail Pol wears was from an old Tanuki hero, and, like Tanukis (and every evolved-to-be-intelligent species with tail), will let him transform into many things, although he has to learnt to use it first. Now, with that Tanuki tail, defeating the tyrant will be easier, but turns out there’s a worse enemy behind them: In other universe, where goats evolved and are now the demons, those demons want to control all the universes (also known as the Polyverse) and steal other’s tails so they can too transform because them, like humans, have been taken the tail because of their evilness.
On a side note, bears are the actual gods and creators of the original universe. In the beginning, there was only one universe, but, in the age of dinosaurs, a radioactive meteorite fell from the sky killing all the lizards. The radioactive impact also caused the universe to split into a handful of different parallel universes, and in each one of them, a different mammal developed, evolved, and became intelligent like their gods, and were able to transform their body using their tail. But some of these animals turned out to be evil, so the bear gods took their tail away banning them from the transformation.
All that is fixed is that at the beginning of the game you will beat the Tyrant’s butt, learn about the actual enemy (demons) and go on a quest to kick their ass too. I’ve also planned some characters and situations, but it’d be impossible to speak about them without more context. Also I have planned things that would be spoilers so I’ll keep them to myself.
Apart from what I had mentioned in the first post, there’s also some things to know:
Like in the Zelda games where you had to collect the items to use them, you’ll learn your transformations progressively, opening new choices, paths and such.
You will begin (after the tutorial where you’re just Pol and have a lame-ass punch) with a stone transformation. This will let you make giant-stone-hand punches and transform into an statue, for stealth, weight and who knows. This will be explained as an instinctive reaction for self-defense.
The game will develop in Earth, but in different Universes. you’ll travel from universe to universe meeting many different evolved species, and different critters, which may be the typical “monsters” but they’re just wild animals. (For example, in human universe you may find coyotes).
Animals don’t get you money. You get food from them. Food is essential since the transformations will require energy (equivalent to mana, magic, etc in other games), and after spending energy you may want to recover using food. Some foods may also have other effects, and probably I’ll make it so you can also cook your foods to get other (better) effects. Also, you will sell your foods like any other valuable to earn money. So basically you’ll make your living as a hunter/cook.
Last Saturday I came upon M. Lucanius‘ signature in PAlib’s Forums, and a link to his dev blog. Then I looked around drunkencoders and though “Hey! This is what I need!”. I was planning on making a simple web to speak about my doings and release stuff. I was already considered a blog, and then I saw this place.
But question is, am I a drunken coder? However, there was no time to answer since it was Saaaaturday night and so it was time to go outside™.
And so, that night I had:
1 glass of whisky + cola
2 3 shots of Licor Café
1 glass of José Cuervo + cola
1 glass of whisky + cola
So next morning I woke up and said: “Yep, I’m a drunken coder”, and registered.
—————–
Well, as I already implied before, I’m a member of PAlib. That means I’m doing something about homebrewing for NDS – using PAlib. To be more exactly, and actually saying something, I’m making a videogame. Name is Tanuki Tail, and it’s going to be a zelda-style gameplay adventure. It’s my first game, to be honest, since I absolutely hate Pong (I have, however, made a little dumb game a couple of months ago, I’ll talk about it someday). However, it’s quite an ambitious project. I’m a serious man, you guys. I’m structuring the project in a -I believe- efficient way, and making it as general as possible.
Why? Because I want to release the engine too. I’m coding the game in a way that it loads as much as possible from files from the file system. All the pictures, all the maps, all the sprites, texts, fonts, data, animations, etcetera will be stored in files, and the code will contain only the engine. In fact, once the engine is 98% done, the rest will be map creating, sprite drawing, etc (i.e. create the game files). So far, I really like the outcome. I’m still learning a lot of things, and I’m doing things like finding uses for geometry (really!), but I believe I’m doing really good.
I’ll talk more deeply about it on next posts, but, to help you get an idea of the game engine, the game is 2D, but it geometrically simulates 3D shapes in maps and characters. Each character (this will include npc’s, bullets, items and everything that is not map, actually) will have its own properties (speed, amount of jumps, acceleration, brake, behaviors… everything I came up with). The game can run scripts stored in files (this will have an special mention because I’ve made a general purpose script language maker/script compiler toolkit for that), and apart from that the rest of the features are the typical on a game like this.
About the game, think of a GBA Legend of Zelda where you transform into things rather than using items. This, with the addition of the fact (that I mentioned earlier) that each character have very different behaviours, adds a little twist on the genre.
The game is being made in C with PAlib, although I’m developing it using object-oriented techniques.
So, about releasing the engine and such: the plan is to have three releases when the game is done:
The game itself: a rom with the game you can play.
The game source: practically a copy of my latest project folder, including all the tools I’ve made and used on it. With this, one would create an “own” version of the game, for instance.
The engine source: a “blank” version of the game source, with no maps, texts, scripts, etc, and without all the non-generic stuff (script language implementation, etc).
Well, this is a long post. I’ll leave something for the upcoming ones.
COMMENTARIES COMMENTED