BARO'S SOFTBARO BY BARO!

Finally, here it is a polished, mastered, perfectioned, improved version of BaSS, Baro’s Script Compiler!

HERE IT GOES, A DOWNLOAD LINK
HEY AND THE SOURCE IS UNDER GPL LICENSE (I tried to do my best to make it legible)

In case you haven’t heard of it (It was already available as Beta), BaSS is a set of tools that let you define an script language and compile scripts with it. The most immediate use of this is to write event scripts, e.g.: what happens when you speak to someone. But, it can be used for anything you find it useful for.
BaSS currently consists of three tools:

Luthier: Lets you define and describe your language: a set of commands and constructs (premade script fragments) that your scripts will use, as well as other options concerning how the script is compiled (endianess, size of some things, etc).

Performer: Compiles the scripts you make, using the references you’ve defined with Luthier.

Technician: Decompiles a script compiled with Performer, in case you need to retrieve a valid source that, when compiled, produces the same script.

The final results, the compiled scripts, contain an array of bytes that can be read by your program to run the script.

The program comes with a manual where this is explained more deeply in the introduction, and then details of everything the tools are capable of. At the end of the manual, there’s a suggestion section which can help you designing your command set and writing your script running function.

(It is likely that I soon write a template language and a C function to read it, including if commands, etc)
(Changes from Beta version posted in first comment)

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.

Enjoy.

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.

I recently mentioned that I was thinking about making a secondary project, likely a rpg with tile based movement (i.e: easier coding, more “what should the game do” thinking instead of “how the fuck do I do what it’s already obvious it has to do (and make it efficient)” thinking).

Well, this is already settled. Just like Tanuki Tail will be able to be considered a L.O.Zelda ripoff with lots of twitches, this new game is planned to be a Pokemon ripoff with lots of twitches. No shame, no regrets: a ripoff.

In other words: turn based fighting (or something similar, here is where I want to innovate, since it’s the most important gameplay), the overworld is a grid and you move from block to block (uncare for corner collisions, circles, volumes, etc. unlike in the super-geometrical Tanuki Tail), you ‘catch’ and ‘fight’ monsters, you probably played pokemon so you know the long etc.

I’ve though about some aspects of the game (concepts) but won’t tell much until it’s solid. Just that the current ‘project name’ is Channelers and involves people summoning souls and controlling them.

This game, however, doesn’t mean an end to Tanuki Tail, which, on the other hand, gets tedious over time, because of library switchings, and the need to optimize already, with only 2 moving characters on screen and 3 frozen ones, and lots of things to implement. The plan is that the games help eachother. The tools will be used in both, or the tools’ code will be reutilized when necessary (for example, map editors would be too game-specific). Also, having more friendly coding goals allows me to rest from TT for short periods of time, and work with the other game.

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.

Controls, quick

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.

So, what have you done in this?

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.

Coooool

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

Why lazy

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.

Why liar

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.

More

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.

Hello readers of my blog or readers in general if you’re seeing this from the drunkencoders front page and don’t actually read my blog!

This is a game I made for a college project (in which, in an unrelated note, I got high marks). It’s a small game about sport fishing with dynamite (that’s the meaning of the title).
It’s simple and you’ll probably get bored son as there’s not much to do. But it’s cute to watch for a while and there’s a dopefish cameo. Also you get to fish with dynamite by killing the fishes with explosions, so actually it may be worth of some of your minutes.

You can download it directly from here or read more about it on its page here in my blog.

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.

Also

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?

Added a new widget (on the right, under the logo). In that section, I will post the activity I am (or should be) currently doing. See it as a “quick news not worth/able posting”. Current one is surely an achievement worth posting, but I need to have internet working on my computer (this is not it) so I can post pics and such.

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/

Reading the man makes you a man
(This has nothing to do with anything related to TT or NDS dev, but is something I’ve learned today)

On dev-related notes, I’m working on the inventory. Currently I can get/lose items and show them on a grid (displaying little numbers for quantities ). I’ve also started an intro logo. (An animated face “saying” ‘Baro’… you see the lips moving accordingly (B-A-R-O), but there’s still no voice).

Hello guys!
I’ve just uploaded one of the tools I made and find useful, because that’s why I made it. I use it for dialogs and such in Tanuki tail.
It’s TTTexT, and it’s just a text parser that generates text files from a text file, admitting scape sequences and generating separated text files from a single text file. I’ve also included the source file, because you’ll probably want to edit the scape sequences to match your personal desires and needs.

You can find the download and [probably] all the info you need in ITS PAGE AT MY BLOG

If everything went well and I understood dovoto correctly, this post also pops the cherry of the tag filtering thing and appears in the main page. I think it’s okay since it’s a release of something.

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.

Also, demons

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.

Also, story

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

Also, that’s all by now folks

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

When you’re mallocating space for an array of chars, allocate one more byte than the expecten string length

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…

Animation system in Tanuki Tail

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]);.

Been drawing

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:

Download

This is a tool I’ve made to develop Tanuki Tail, but decided to release because I’m so awesome and helpful.

BaSS is a script language toolkit I’ve made (and still work on from time to time). It lets you create script files that use a script language of your invention. For example, if you are making an RPG you may want to create scripts for your NPC events. For example, when you talk to someone make him face you, load a text, print the text, maybe give or take an item, etc. It also has other uses, like event animations (example: “walk two tiles up, then turn around, make the character jump…”) or anything that comes into mind. After all, the final result is an array of bytes with the meaning you gave to them.

The current toolkit consists of two tools, Luthier and Performer, both of which are command line text parsers. The toolkit comes with a manual that explains pretty much everything.

Luthier creates BaSS language files from text files. This is, the collection of commands you want to use to compile scripts with Performer. Read the manual and example to get a better idea, but, a quick one:
5 loadtext 1 2 textID
6 printloadedtext 0
X print 1 2 textID // loadtext textID \ printloadedtext
These three lines would put two commands and a construct in the language:

As you can see, this also implements constructs, which are something similar to macros in C. A construct is translated as one of more commands with parameters (constant or parameters of the construct), which is useful for common script lines, aliases (multiple names) of a command, or, with label references, jump commands.
Presumably, loadtext would load a text reference into some buffer, printloadedtext would output it, and print would do both things.

Luthier also lets you define things like maximum script file size, coordinate types size (each script has two coordinates: bank and script, and offset as an offset in the script file), endianess of data bigger than one byte, file extension, etc.

The second tool is Performer, which is the actual script compiler. Given a text source file and a language file (created with BaSS), generates a file containing the array of bytes that represent such script. For example, with the previous commands, the script

%TARGET 0 1
loadtext 10
printloadedtext
print 11
would generate a script with the bytes 5 10 6 5 11 6 (also, would save it in ./scripts/0/1.), which would, presumably, output texts number 10 and number 11. Constructs get translated into the commands they mean

It is possible to #define things with a %DEFINE directive.
It is also possible to insert labels. Labels are references to a script bank-script-offset coordinate, and can be added in a script to create a reference to that exact point of the script. You can create constructs that accept Label or Extlabel types, and then, when compiling, Performer looks up that label. If it’s a Label, it looks in the current script. If it is an Extlabel, it looks in a labels file, where all the labels from compiled scripts are stored.

Once you have your language defined, you have to implement the commands into your game. The logical way to do this is sequentially, with jumps of needed, by creating a while loop that reads the whole array byte by byte and running each command depending on the byte read (with a switch statement, for example).

This is a beta. There is a lot to improve and a lot of code to clean. Once the code is cleaned enough so it doesn’t embarrass me, I’ll release version 1, which will be open source.
Feedback is welcomed, being it praise, bug reports, comments, questions…

Download it right now.

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.

Brief:

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…

Story:

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.

This needs a bit more background, maybe. (Those may sound more coherent when explained slowly during the game)

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.

So that was a neat introduction, what then?

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.

Something else about the game itself, gameplay…?

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.

So!

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.

—————–

So, what’s this blog going to be about?

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.