Yukkuri game

[Zug]

Ok I am creating this discussion so we dont spam the gallery site.
Here is basic concept again so this post is not so empty.

Yukkuri Game will be 2D game programed in C++ and Allegro 3rd party
library which will handle graphics, input and possibly sounds. The
game should be something like mix of Tamagochi, where you have a pet
about which you have to take care and Black & White where you also
have pet but you can train it, reward it or punish it for its actions
and so. Game will have multiple zones but main should be yukkurarium
where the yukkuri will live. Other zones should be frying pan or
livingroom with TV ,where yukkuri can compare its life with wild
yukkuris, and so. There will be 4 basic types of yukkuris: Reimu,
Marisa, Patchouli and Alice. Everyone of them will have different
personality and behavior. Every action taken on yukkuri will change
its opinion about you and in extreme cases it may even permanently
change some of their attributes or personality. There should be many
way of how you can affect your yukkuri including pairing them into
famillies. I dont think there is any way to get yukkuri like voice so
they will communicate with speach bubbles. Ill try to keep basic laws
of yukkuri life and survival but if it will make game more fun, Ill
change them.

Of course it will change in time.

And BTW Im not really used to these google group sites so bare with me
if I post something wrongly.

[Poweryoga]

I am well versed in C++ so if you have any problems, feel free to let
me know. If you are not planning additional interaction besides
tomagochi actions, I don't imagine this will be very hard to program
at all.

If you want to start up a codeproject (http://code.google.com/
hosting/) so that the source is open, I can help debug and what not.

What platform are you programming on?

Welcome to the groups, by the way!

[Zug]

Thanks, the platform is windows if thats what you mean.

[Zug]

Ok i made it here http://code.google.com/p/yukkuri-game/ but Ill have
to learn to use it first but that shoudnt be a problem.

[Three]

Awesome, hope something fun comes out of this.

Some ideas I think would be interesting, but have no idea how feasible
they are:
-Varying speech patterns. Based on how old/educated/well behaved the
yukkuri is it talks differently, e.g "Reimu is hungry."/"Stupid Human,
bring Reimu's munch-munch!"/"Yuuuu! Yuuuuu!"

-Different starting situations. Is the yukkuri from the pet store or
did it come in through the cat door? Each would have different
attributes, whatever those are.

I know next to nothing about coding, so can't contribute much there.
Will try messing around with sprites though.

[Zug]

This variability shouldnt be hard to code, it should only take more
time, I dont really care if the whole game will take year or so take
make. My main priority is to make a fun game to which you will return
every now and then because its so much fun :)

[Tea]

Just dropping this here as it might be relevant... from what I
gathered back when I was toying around with my own project, it seems
the average system here is going to be quite good spec so resource
constraints shouldn't be too much of a worry.

Although something more relevant is the comment list on
http://bbs.shii.org/yukkuri/post/view/4547
A lot of good ideas there. I actually really like SUN's suggestions,
but even I know that they'll likely be a lot of work, as well as time
consuming to implement. Still, they fit in with the idea of having
multiple zones and maybe the yukkuri hunting/trading part could be an
extension of that, so it might not actually be too bad.

[Moeman]

Well, I'm going to spout my image of what the PERFECT yukkuri game
would be like. Shoot out a lot of ideas to consider and shoot for.

Customizeable environment with various objects. Everything ranging
from toys for them to play with, to horrible torture devices, like a
hot plate floor panel. Then a range of tools for interacting with the
yukkuri, default tools like hand with "grab, rub, flick, take
accessory, and poke" and some food to start with, in "Super easy, wild
like, and dry fiber" with "Heven mode and raw garbage" flavors
unlockable.

Ideally, to keep things interesting and promote use of everything, I
favor the final game and more advanced releases having some kind of
currency or points that you need to earn objects with. A sense of
achievement would add so much more enjoyment. that ultimate happy
smile or fully defeated slump is so much more fulfilling if you have
to work for it by earning points and getting better self-emptying
sandboxes or spicy flooring.

The crowing code request would be the making all yukkuri have unique
personalities. here's one potential way of structuring it:

Personality stats: can be influenced by where the come from, such as
gutter trash being more frequently fearful and timid, pets being well
behaved, and wilds being arrogant and strong willed, but all yukkuri
should have some variance.

Maternal instincts, how important children are, whether it will
selfishly neglect them, or give it's life for them.
Friendliness, how quickly it forms other relationships, or if it's a
selfish turd.
Sense of fear, determines whether a yukkuri will run or threaten, and
how much it has to be hurt before becoming scared.
Scope of thought, Or just "memory" How well learned changes to
personality stats stick. (I personally interpret them not having bad
memory, some just think more than others, and the ones that rarely
think at all aren't going to be very easy to influence.)

Then maybe some traits:
Sympathy: When it sees another yukkuri harmed, it's feelings about
what did the harm are influenced. (may cause a yukkuri that also has
low sense of fear to "punish" mister fire)
Elitist: Only likes it's own type, shuns others.

And then some slots reserved for how it feels about "mister," and
however many other individual yukkuri can be in there at once. Then
some space for how it feels about various objects.

Next, some kind of hub area, that you have an avatar walk through.
This is where you'd find wild and gutter trash yukkuri. Wild and
gutter trash continually regenerating in several easy places. Also the
option of carrying yukkuri along, make it feel good about being a pet
compared to gutter trash, or suddenly release it to the wild after
pampering it. There would be several easy places in both the town and
the forest, having a high random chance of spawning a yukkuri or
family each game day if empty. shop would be available this way, but
also have an instant shop menu from home.

Personality would be hardest, but definitely the most satisfying
aspect.

[Three]

Moeman, you've described the Dwarf Fortress of yukkuri sims, minus the
horrible interface and coding issues.

I'd love to see variable personalities as well. Learning what foods
your pet does/doesn't like would be interesting, especially combined
with other personality traits. Won't get Marisa her favorite food?
Starved! That's an extreme example though.

Not so sure about the budget/earning points mechanic. Maybe as you
progress down a "path" new options are unlocked? Keep kicking and
poking to get fancy things like http://bbs.shii.org/yukkuri/post/view/17365
! Food could be abstracted; each week/day choose the yukkuri's meal
plan; some sort of drop-down menu of Garbage/Cheap/Average/Expensive/
Super Special.

Or at the start choose a setting, like Home, Factory, Wilderness. That
sets up what your basic tools are and new ones are unlocked with time
and/or goals being reached (keep alive for two weeks, fend off home
invaders, etc).

Spent over 9000 hours in Paint.NET on this
http://i15.photobucket.com/albums/a363/UrbanShaman/reimu_sprite_front_scared.gif
Braids are missing and the original has a blank face for ease of
creating variants.

Oh, and the idea of sharing/trading yukkuris is neat. Some sort of
"export" option that outputs the yukkuri's stats to a .txt file; put
it in the yukkuri folder and load it or something. Kind of like DF's
worldgen settings can be saved and shared.

[Maximusfive]

About the factory start that was mentioned, I think if you started in
a factory setting that maybe you should have 'Goals' to accomplish to
earn points. Some of the goals might be like 'successfully breed a non-
shitting yukkuri' or 'breed a yukkuri who can sing beautifully' or
maybe even 'Breed yukkuris that can handle mass births so it can mass
produce yukkuris for us' and other Factory style goals. That may be a
bit ambitious for simply one of multiple starts, so it might be easier
to simply make that its own game. For the people who hate abuse, you
might include 'Train/breed badge level pet yukkuris' or other such
family friendly goals that could be done in the Factory.

With the wilderness start, maybe you could have the player act as
mother nature(sort of). I'd imagine this style to be more sandboxish
with you simply causing nature oriented events and seeing how the
yukkuris react. Another possibility is that you have a goal, such as
'Act as natural selection and eliminate the shithead yukkuri only',
which would add a challenge to the game as you would have to eliminate
only a specific type of yukkuri. Maybe, instead, you could have the
player cast as a Zoologist whose goal is to experiment on the yukkuris
in their natural habitat, without being seen by said yukkuris.

Remember, these are only Ideas, whoever makes a yukkuri game can pick
and choose from among them and I don't think anyone would complain. I
think we would all just be happy to have a (english) yukkuri game.
(Disclaimer: If you make a Yukkuri game that is only abuse or only
family friendly, my previous sentance does not apply. XP)

On Jun 14, 8:50 pm, Three <threeste...@gmail.com> wrote:
> Moeman, you've described the Dwarf Fortress of yukkuri sims, minus the
> horrible interface and coding issues.
>
> I'd love to see variable personalities as well. Learning what foods
> your pet does/doesn't like would be interesting, especially combined
> with other personality traits. Won't get Marisa her favorite food?
> Starved! That's an extreme example though.
>
> Not so sure about the budget/earning points mechanic. Maybe as you
> progress down a "path" new options are unlocked? Keep kicking and

> poking to get fancy things likehttp://bbs.shii.org/yukkuri/post/view/17365

> ! Food could be abstracted; each week/day choose the yukkuri's meal
> plan; some sort of drop-down menu of Garbage/Cheap/Average/Expensive/
> Super Special.
>
> Or at the start choose a setting, like Home, Factory, Wilderness. That
> sets up what your basic tools are and new ones are unlocked with time
> and/or goals being reached (keep alive for two weeks, fend off home
> invaders, etc).
>

> Spent over 9000 hours in Paint.NET on thishttp://i15.photobucket.com/albums/a363/UrbanShaman/reimu_sprite_front...

[Moeman]

I was thinking a "park" where you could take your yukkuri to meet your
friend's yukkuri.

Yeah, my post as I said, is what I'd want in a dream yukkuri game. No
limits. Some ideas of what I'd like to be able to do in the game.

Put food in the center of a rough floor, or use a loud tool to make
little Reimu afraid of a flower, then put the food there.

Put lower quality food elsewhere, then spoil Reimu every time she
eats, poke and flick the others when they go to eat the good food.
Make them jealous, until they start eating worse food too.

Make a family-loving Marisa afraid of the moat, then strand a timid
Reimu in there with something scary.

Hmm, give each type something they can do that the others can't?
Floating Marisa, Singing Reimu, Reading Patchouli, At a loss for
Alice, since any bad-natured yukkuri should be able to rape.

[Three]

The park would be interesting.

The unique things for each type is also interesting. For Alices, maybe
a stronger tendency towards better behavior/training? The whole
"rapists lololol" thing is pretty much their defining trait aside from
"city-sect" which I'd interpret as an urge toward being less messy and
rude. Or at least more obstinate; so Alice types are stronger willed.

[Zug]

Almost anything can be made, it will only take forever but thats not a
problem. After basic playable game is made we can release newer,
better version sometimes leater. Ill probably start coding today and
hopefully Ill make wandering reimu sprite.

[Zug]

On 14 čvn, 19:02, Poweryoga <nospam11...@gmail.com> wrote:

> If you want to start up a codeproject (http://code.google.com/
> hosting/) so that the source is open, I can help debug and what not.

Ok I give up, how do I post a freakin code there?

[Tertius]

I'm guessing

1. svn co <url-to-repo that google code displays for you>
2. make changes
3. commit changes

But then, I've never used google code before.

[Poweryoga]

Version control (depending on if you use subversion or mercurial) is
controlled by your subversion client. Anybody can check out code but
you need to assign an admin and commiter for the code, if you have
more than 1 person in the group.


From a forum post for an example on using cygwin:

using svn under cygwin to upload any file to your depot.

- install cygwin subversion.

(see cygwin install from http://ist.berkeley.edu/as-ag/tools/howto/cygwin.html)

start a shell > export SVN_SSH=ssh$

> svn import $some_file https://$your_project.googlecode.com/svn/$some_file
\

-m $some_message --username $your_user_name --password
$your_password

delete a file from the depot

$ svn delete https://$your-project.googlecode.com/svn/$some_file \

--username $your_user_name \ --password $your_password \ -m
some_message


Alternatively if that's too complicated, you can just post up the
project file (assuming you're using visual studio) in a little file
down in the files section and I'll clean it out here once in a
while.

[Poweryoga]

Also, lots of good ideas folks. What Moeman and Three described is
originally what I had intended for my game. I had built it from the
ground up to be modular so that it can do all of those features, which
is why i favored C# initally. However, the project grew a bit beyond
my control due to the 3d graphics so it's on an indefinite hold for
the moment.

[Matt]

Why not use 2D? It's not only easier, but it tends to look better with
less effort. Then again, my opinion probably has little impact as I
have no skills to add in the making of the game.

[Tea]

Huge post incoming. I love taking ideas and running with them, so I
apologise for getting carried away...

>The park would be interesting.

Definitely agree, and also with the no limits thing... for people who
just want a sandbox type game, where they can just screw about and
pass some time with yukkuris, that would be perfect. But if there's
also tasks and "missions" to accomplish, like for the factory, then
it'll also give the people who want a little more depth a great
experience too. They shouldn't be mandatory though, so that people who
just want to mess around for a bit can like I said. Or maybe it could
be split into two modes, a "sandbox" type mode where everything is
available from the start and a "story" mode.

Just some ideas for different "zones" taken so far. Just a general
overview, it would be best if each one then split down into different
sections themselves; like at home, you have might have a basement, and
also a living room. If you decide to abuse and torture yukkuris in the
basement, then you could still be nice to the ones in the living room
and they wouldn't know better (although after a while, due to the
whole death scent deal they might become apprehensive). Also the
kitchen for re-enacting 'A method of abuse' and frying pan fun.

Park: A meeting place where all the yukkuri owners meet every few days
or so. You can let your yukkuri play with the others, etc. At the
other times, you can search round it to find a few random gutter trash
families about.

Street: There'll be the odd gutter trash family wondering through
every now and then. You can catch them, if you like. Sometimes, there
might be a yukkuri performance/singing troupe, so you could either
bash them in and take the cash, or you could take them in, as well. So
you'd have an easy catch of special property yukkuris, without having
to buy/breed them yourself.

Factory shop: Buy/sell yukkuris here, and also get the latest yukkuri
specialist equipment. You can also take on various missions and
contracted tasks from the factory, too. At different times, different
yukkuris may be desired over others, so prices may fluctuate.

Home: Your house, of course. Here's where you keep your yukkuris, in
various yukkurariums and whatnot. As described above.

Abyuse club: Hentai time with Aya.

>The unique things for each type is also interesting.

This is also definitely a good idea; it's established that different
types act differently, and brings variety to help make the game more
entertaining. To me Alices seem like a more elitist (the whole city-
sect business) version of the Reimu. Non-rapist ones, that is.
Actually, Alices are a special case, because of their rape behaviour.
I imagine there'd be 3 unique traits: Raper, Non-raper, potential
raper. For example, a non-raper type would react the same way most
other yukkuris would to some sort of stimulus like a vibrator; in a
raper, it'd send them on a mega rape rampage; for potential rapers, it
would send them to raper status temporarily. That brings me onto
another point... yukkuri puff-puff dolls must be a feature (http://
bbs.shii.org/yukkuri/image/14731.png)... especially an Alice version
with rapeface and flailing peni-peni. Going with the idea of different
unique traits... Reimus would probably just bounce around crying to be
saved, Marisas would puff up at it and try to fight it, and Alices...
as mentioned previously.

Over reading, for Patchoulis I think a much more interesting ability
for them would be to have the knowledge to heal other yukkuris, given
the right ingredients. Or maybe they could gain skills after reading
certain books? Of course, wide individual differences inside the
species. Low-end Patchoulis would probably still desire the books, but
instead mess them all up and vomit all over the covers.

>At a loss for Alice, since any bad-natured yukkuri should be able to rape.

That's true, but I don't think it's much of a problem. Rape IS the
stereotypical Alice type trait, after all. It's like with Reimus-
typically defined as being selfish and lazy, although any bad yukkuri
could be like that it's far more associated with Reimus now.

[Three]

There could be a fake yukkuri doll for each type. Reimus puff and make
noise, Alice ones are as you said, Marisa's make more noise, move back
and forth aggressively and Patchoulis would, I don't know, say smart
things. Could be a teaching tool that repeats messages.

Another location could be Yukkuri Shows/Badge Examinations where you
show off against NPC-owned yukkuris. Probably randomly generated ones.
Earn prizes, either practical (new unlocks/money) or just for show
(badges and ribbons). Could affect the yukkuri disposition as well.
Win too many and the yukkuri gets arrogant. Or if it's a timid/weak
one, it gets stressed out.

Ease of modding is something that would be good to have. That way the
differing opinions on yukkuris can be accommodated. Don't like paste
cores or breathing yukkuris? Want to have the death smell factored in?
Could make adding new varieties easy as well.

I prefer a 2D, maybe isometric. Easier to design assets for and
modify.

My ideal yukkuri game is pretty similar to what ideas have been thrown
around so far. One addition is that it wouldn't take up too much
processor space and just work quietly in the background. Little popups
(like when Steam tells you friends have signed on/what they're
playing) in the corner would announce things like "Reimu is hungry!"
or "Patchouli is sick!" while the game pauses for you to react.

[Poweryoga]

I suppose my rationale is because XNA studio is a 3d program for the
most part. 2D isn't hard to do, I'll agree on that. I made a few 2d
games just to test the waters, and it felt like it wasn't too
difficult. Isometric is just a different version of 2d, to be quite
honest.

[Moeman]

I'm going to stop with random suggestions, and give a more organized
description of what your description brings to my mind.

First off, I'm imagining it having 16-bit type graphics, since that
style would Look pretty nice, and be simple to animate. You could even
have a "bald" yukkuri in the early testing phases and have the hair
and accessories, maybe even eyes added later in a separate layer that
allows them to be removed in the final game.

You'd have a game area that your yukkuri live in, which you can place
various objects in. The "zones" idea seems a bit rigid, I'd personally
favor the idea of giving the player several blank rooms or yukkuariums
that the player can put anything they want into.

As for earning currency, maybe have a set amount of time that forms a
game day, and the happiness and unhappiness of the yukkuri is
transferred into currency, possibly with more minute amounts earned
through the day as they interact with objects, eat food etc. Might be
interesting to have two currencies, one earned with happiness, the
other with unhappiness, in a way that promotes doing both, yukkuri
lover's shop offering better prices for abuse currency in hope of
making the lives of abused yukkuri better, and the inverse for the
abuse shop.

As i've said, the highlight for me would be the yukkuri having
individual personalities and preferences, start with some attributes,
like:

Sense of fear, loyalty and maternal instincts, which determine how a
yukkuri will react to situations. All of these should be influenced by
constant or intense stimuli. If that mouthy Marisa is continually
bullied into submission, sense of fear rises, or suddenly losing all
of it's children causes a Reimu to become less maternal.

Then some on/off factors, like Courage: Ignores sense of fear when
family are harmed or in danger.

from there, the other yukkuri, "mister" and the objects it interacts
with, get a simple slider that goes from love and dispise to dictate
how the yukkuri feels about something. By default mister flower is
easy, but if you use the air horn every time one looks at it, it will
blame the flower and dislike it. This would work by having a yukkuri
thinking about things it's near or trying to go to. A special
unlockable tool might even show you the things a yukkuri has on it's
mind. Three things max I'd say. Target, nearest object, nearest
yukkuri.

[Tea]

> You'd have a game area that your yukkuri live in, which you can place
> various objects in. The "zones" idea seems a bit rigid, I'd personally
> favor the idea of giving the player several blank rooms or yukkuariums
> that the player can put anything they want into.

The whole idea of the zones thing is actually so they're not rigid,
ironically. The idea of the player having several blank rooms that
they can put anything into is what I described with the home zone
above. The other zones aren't essential; you can play without them
(and then there's the sandbox mode I mentioned). But for the people
who want to take it a bit more seriously, then there's the other zones
they can go to for some variety and tasks.

The currencies system is interesting, but best implemented alongside
another system of currency as an additional way of earning money. So
you have a fixed income every day of a small amount; you can raise it
by trading/selling yukkuris (which could also fit well with the
happiness idea- the abuse shop would pay more for happy yukkuris,
etc.) and then there might be the "activity" currency system. I say an
additional system, as if it's the only way to earn currency then it
might force players to do things they don't want to.

I'd also say a Kiriraitaa drawing style would be awesome because I'm
an extreme victim of the moe effect but it'd depend on who's doing the
spriting.

[Poweryoga]

To be honest, customizable environments are going to be hard to
program in terms of displaying them. You can set a pre-determined
location for them easily in XNA and then plop it down when you "buy"
the object, but in terms of customization it'd be weak. If you want
to add in interactable objects (via Sims) or anything like that, it'll
add a whole level of complexity as well. Not to mention behavior for
yukkuri... if you want it to have an AI of any sort, that'll add huge
levels of complexity. There's a reason why most games are devoid of
complex AI, because having anything more than 1 layer of basic
function adds tons of complexity. (NP hard problem for those of you
that care)

Adding any sort of feature that involves buying and selling the
yukkuri would add another level of complexity as well, and a big one
at that. You'd have to objectify yukkuris to make them non-essential,
which changes the way the variables in the environment affects static
values. It opens up a whole spiders nest worth of bugs that I can
imagine as well, but it wouldn't be as bad as the AI.

The little sprite test i did yesterday (just animating the little
bugger) took about 2 hours to do. So adding any sort of features
would be fairly time consuming. Not to mention we have few enough
contributors to stories as is, so if I start working on the game then
it'll mean no translations.

In any case, I want to hear from Zug to see what his opinions are on
these ideas. If we want to go forth with the game project, we'll need
to nail down a language and development suites, as well as basic
specs.

[Toawa]

Oh now, don't poo-poo my efforts! I've been working on just this; an AI
engine for yukkuri.

(Also, I gotta call you on the use of NP Hard; any links to papers
explaining why the AI problem is NP Hard?)

[Zug]

In time, anything can be made. Now Im going to try to fulfill my
promise from yesterday and finish wandering yukkuri sprite.

[Poweryoga]

Well, I'm not saying all AI problems are np-hard by nature. Most
problems that involve some sort of search are np-hard, because the
choices always go up exponentially in terms of difficulty after the
first level. Especially if you want a "complete" AI tree, which is
near impossible (and thus the reason why most people go with simpler
heruistics like A* search). If you want complete interaction with the
environment, each scenario would become sort of like a "traveling
salesman" problem, which is np-hard, which is why it's easier to just
code in basic 1 level functionalities with both objects and user. Of
course, simpler choices and problems are not np-hard because they're
easily computable, same with 1 or 2 level problems.

This paper gives a good overview on planning of an AI problem, and
explains why certain aspects are NP hard.

http://www.cs.toronto.edu/~sheila/2542/w06/readings/RintanenHoffmann01.pdf

[Poweryoga]

Sorry for double post:

Zug: do you want to stick with C++ and Allegro, or do you want to try
out C# and XNA studios? C# is almost exactly like Java (if you know
it), and it's a beautiful object oriented language that's fairly
intuitive and easy to use.

I can post a sample code of my yukkuri sprite test if you're
interested in the code format.

[Toawa]

Just like Java, minus the sadistic class loader :)

The only thing Java has over C# is its enumerations. (Oh how I wish for
overloadable operations on C# enums...)

[Matt]

I can't even get the spritetest to work...damn old computer.

[Zug]

Im planing to stick with C++ Allrego for some time but Ill surely
learn C# in future.

[Three]

@Moeman
I'm messing around with something like that. Trying to get a yukkuri
template that's just the body facing several directions (left, right,
front and back), each occupying a 150x150px square. Then I'd make a
copy of each chart for each type, add accessories and faces and go
from there. Probably would leave the faces blank on the front icon so
that different versions can be made for different emotions/actions.
Would definitely make heavy use of layers for all the variations.

Here's a five-minute MSpaint example of what I'm thinking.
http://i15.photobucket.com/albums/a363/UrbanShaman/game_chart_example.jpg

Of course, this hinges on what the programmer(s) need for graphics.
And if I can get the hang of this. Not much of an artist (yet).
Definitely not familiar with game design. Learning, though.

[Tea]

As well as the left, right and front and back directions, it would be
very nice if you could make diagonal direction ones as well because
then I could use them too... :P

Layers definitely seems the way to go. It'll save space so each part
can just be placed on as needed, rather than a new sprite being needed
for each different emotion/physical effect/etc, although it will
probably mean more processing to do. Just out of interest, how hard
would it be to learn something like C# or C++ if you already know
something like pascal? In a previous life I wasn't too bad with it...
the recent programming stuff I did in GM was just fooling around
without paying attention to any tutorials or docs mostly, which is
probably why I found that hard. Most of the ideas being proposed are
also yeah, pretty complex as they are. But brainstorming is too fun...

Also, nice chart idea, but each one needs to be centered right when it
comes to the proper thing.

[Three]

Diagonals? Can do.

When you're talking about layers, what meaning are you using? I'm
guessing something about altered accessories, damage and facial
expressions as separate sprites. Then, thanks to code magic, those
sprites are added to the body sprite or something?

The meaning I'm using is that I make the "yukkuri, facing forward"
image, make several copies and each copy gets a different face. So
then each is a unique, standalone sprite.

[Poweryoga]

Hm, I'm not so sure about layers. For the sprite sheet in XNA studios
at least, it's easier to have a long horizontal strip of sprites
because the way they animate sprites is the following:

1) Load the sprite with the viewbox window location, so that it cuts a
segment from the sprite sheet.
2) draw the sprite
3) Update the canvas and locations of the sprite viewbox
4) update timer
5) Go back to 1.

So what happens when you load up the sprite is it checks each segment
of the long strip, and read in a xcoord x ycoord piece of image from
one big image. So then you have to have both pieces (accessory +
yukkuri) be the same pixel size or you'd have x and y coordinate
increment problems.

I'm not sure about allegro, but I imagine it'd be similar.

@Tea

C++ and C is very different from pascal. I'd suggest starting from
the basics, because even the syntax is drastically different. It
won't take long to learn a basic working knowledge of the language
though.

@Zug

Ok sounds good. Feel free to post up the source code or any specs you
have so we can help out with the programming.

[Poweryoga]

Also, JPG doesn't support transparency. Better use PNG.

[Three]

So something more like this then? With more organization and less
QUALITY of course.

http://i15.photobucket.com/albums/a363/UrbanShaman/heeble_weeble.png

In any case, I should start sketching some thumbnails. I'm thinking
expressions will be interchangeable between types, unless accessories
are involved (a Reimu holding braids in front of eyes for example).
Some I'll try out:

-Expressions: Happy, Sleeping, Puffing/Angry, Scared, Crying, Eating,
Dead, Aroused
-Status: Burned Feet, Burning, Dirty, Clean, Something Random (paint
your yukkuri!), Wounded
-Accessory Alterations: Damaged, Clean, Badge (Gold/Silver/Bronze/
Trash), Missing, Mismatched (too small/large), Unique (Shell Marisa)

[Ohai]

...can't even suggest anymore, you guys pretty much covered up all
what I want in a sandbox-type Yukkuri game.

If ever, can I be the beta tester? I can't help on programming and
drawing, but I can help on other stuff.

[Poweryoga]

Something like that is good. But it's easier to load into a program
if you separate the images into a few categories.

example: base Marisa as a png. (you need to start the image off as a
PNG else it will retain a white background when you convert it back)
Then you can make a emotions.png, accessories.png and so on.

[Poweryoga]

By the way, for people working on images with the intent of overlaying
it on top of existing images, please take a look at this discussion.

http://www.codingforums.com/showthread.php?t=19818

I'm not familiar with graphics design, but you do need to fiddle
around with the png/gif file's alpha transparency levels. Paint does
NOT do transparency, as I found out to my dismay today.

[Ohai]

Try Paint.NET. It has transparency for .pngs.

(If I can draw some goddamn 'kuris, I will help you guys out. Can
someone provide some sketches/samples?)

[Zug]

Thanks everyone for ideas but I wasnt able to get to it as much as I
should because I have been busy last two days so now I continue
creating simple wandering sprite of yukkuri. It takes little longer
then I thought it will because I wasnt working with random number and
time library for some time so I need to refresh them a little but
thats one of the reasons why I want to make this game, not because Im
really good programmer but because Im kinda begginer and this looks
like good praxis

[Three]

@Ohai

Original sketches or stuff from OYP? Weekend's going to be busy and
little time for drawing, but I should have some thumbnails up by
Monday.
If it's OYP stuff, just browse around and take notes I guess.

[Zug]

BTW does anyone here has at least basic experience with Vocaloid or
something like that? I think we could use it for yukkuri voices. If
not Im willing to learn it but it will only make whole thing last
longer.

[Poweryoga]

Don't bother with voices until you get the basic functionality down.
It's trivial to implement compared to all the other stuff.

Zug:

If you want to toss up your project source code I can help out with
the coding as well. I'm just playing around with a few concepts in C#
and XNA right now because I don't want to double up on the efforts.

[Toawa]

For anyone interested, I've uploaded my current AI simulator. It
requires .NET 4. http://groups.google.com/group/yufanfics/web/Debug.zip

Look in TestAI.txt for an explanation of the AI description language.

As usual, work in progress...

[Poweryoga]

Google disabled zip file downloads because of a recent swarm of
viruses, so you'll have to upload it somewhere else temporarily.

[Toawa]

You'd think if they were going to do that, they'd be nice enough to tell
you when you upload it...

I'll see what I can do...

[Toawa]

Ok, I've uploaded it as a 7z file. They don't seem to have a problem
with that.

I do hope they get the zip issue sorted out, since otherwise there goes
our Anko archives again... I also hope they fix whatever it was that
was causing Firefox to end up in an infinite refresh loop...

[Poweryoga]

I just cleared out my cache when that happens. But yeah, I have no
idea when they will fix it... probably when they figure out how to
plug the hole. You'd think they would scan stuff like that before
uploading...

[Poweryoga]

Ran the file for a bit, seems to be working fairly well with your test
case. However, a few questions/suggestions.


-I really like the stat definition. Versatile and I can imagine using
it for a variety of things. I will play around with it a bit more
tomorrow to see if I can come up with an AI script. Is it possible to
put in a fluctuating decay rate? Not necessarily a linear decay rate
per-se, but maybe something more unpredictable like random with a
range of -1 to 1.
-How complicated can the actions be? Can we define decision trees or
do you use action + queues + wait times for the most part?

[Toawa]

Well, you can specify custom update functions. Decay Linear is actually
just a shorthand for such a function; you could get the same effect
manually. I plan to add other decay modes; it's early days yet.

As for actions, again, it's early days. I have plans to add if-then-else
blocks, let blocks, possibly some sort of looping construct (fixed
count, to ensure that it won't hang), etc. If you can think of anything
else you might foresee, functions and whatnot...

[Maximusfive]

I'm just wondering but, if...IF...you guys have vocals for the
yukkuris in the game will they be in English or Japanese? I would
prefer English, as my understanding of Japanese is almost non-
existent, but as you guys are the game makers your preference comes
first. If you guys want English vocals, I may be able to get Vocaloid
and see if I cant gain any proficiency in it and contribute that way.

[Toawa]

Ok, before I finally go to bed (because I can't break myself away from
this), I've uploaded a new version.

I've added to the action blocks, the following construct:

select (each|first) {
case <expresison> { actionblockstatementlist }
case <expression> { actionblockstatementlist }
...
}

As well as two other statements, break and continue.
Break breaks out of the select block entirely; continue continues with
evaluating the next case.
The each|first selector defines what the default behaviour is if you
fall out of a case block.
Each acts like a continue, thus every valid case will be executed unless
a break is encountered.
First acts like a break, thus only the first case which succeeds will be
executed, unless that case continues.

Tomorrow I intend to add if blocks, logical operators (which can
currently be represented with addition, multiplication, or subtraction
from 1), and let blocks.

[Toawa]

And I've posted another new version. The file is Debug-3.7z

Additions:

I've added let blocks, which let you define temporary variables for some
block of statements.
The variables are read-only within the blocks.
Variables may only be defined once per let block (unless it's a let*
block; see below).
They will shadow any previously defined variable outside the block's
scope, including other let variables.
There are two forms: let and let*
Both take the form of:

let[*] [binding list] { statements }

A binding list is a list of zero or more variable bindings:
variable = expression[, variable = expression [, ...]]

(Note that the binding list is entirely optional, though why you'd have
a let block without one is not clear to me...)

The difference between let and let* is that the block

let* x=1, y=2, z=3 { statement }

is functionally equivilent to
let x=1 {
let y=2 {
let z=3 {
statement
}
}
}

Thus, it is acceptable to write something like

let* x=1, x=x+3 {statement}

I've also added the following functions:

avg(x,y,...) Calculates the average of the list of arguments. Minimum 2
arguments.
erf(x) Calculates the error function of x. Uses a precomputed 20 term
Taylor expansion (which converges very quickly)
ierf(x) Calculates the inverse error function of x.
IErf uses a precomputed 500 term Taylor expansion, with checks to
ensure that it stops calculating after the numbers get too small to
matter. IErf(1) = 2.451305. For values outside the range of +/- 1,
IErf will return +/- infinity. It starts to lose accuracy at arounf
IErf(0.99), losing one point in the 5th decimal place, and rapidly
degrades after that.

[Poweryoga]

More updates:

Bug: If you open a file, click open and then click on play... and
then open another file and press stop, the app crashes.

Is it possible to modify the count timer for testing purposes?
Lowering the tick seems to not help, and it looks like it's just
advancing by ms using the normal timer function.

What's the syntax for the if statement? Your usage is:

if(Easiness<0.3,1,0)

The first one is the condition to check for, what's the 1,0 after
that?

Also testing this out, I found that even after easiness dipped below
<0.3, the yukkuri didn't speak up until much later (at easiness ~
0.195). So I'm not sure why there's such a big delay...

[Zug]

I wont post the code yet because:
a) There is nothing importnant done yet.
b) Code is for now pretty ugly and I pity anyone who would have to
read it in this form.
Ill finish it during the weekend and add some comments and stuff, then
Ill post it.
Basicly Im just trying to create sprite that will randomly wander
around screen, Its little harder then I expected but as I said it
should be finished this weekend. If we want to have greater number of
yukkuris of same type available then Ill also have to remade it
someday leater so it works with containers of objects instead of
objects them selfs-

[Toawa]

Fixed the open bug; it will be in the next build.

Concerning tick and actions, it helps to understand how the scheduler works.  The scheduler holds a bunch of events in a priority queue, letting them out in the order of their scheduled execution.  The tick value specified in the tick statement controls how often the scheduler is run.  Once the scheduler is turned on, it continues executing until it's run through an amount of real time between the previous tick and the current tick.  Once it reaches that point, it stops and returns control to the program so that it can update the display and wait for the next tick.  Thus, the only thing you gain by decreasing the tick is that the display updates more often.

The delays specified for actions and decay functions are in terms of real time, not ticks, so if you want them to run faster, decrease them.  The frequency clause on stats controls how often the stat's update function is called by the scheduler. (BTW, the syntax has changed; the frequency clause is now 'every TimeLiteral' instead of 'update every TimeLiteral'.  (The extra update was causing a shift-reduce conflict in the parser.)

(For reference, there are currently three types of scheduled actions: StatUpdate, ActionSearch, and Action, which updates statistics, searches for a new action, and performs an executing action, respectively.)

Concerning if:  if() is a function, not a statement. if(x,y,z) is the equivilent of C's (x?y:z).  To get control flow statements, use the select block.  The equivilent of
if (x) {
    y;
}

would be
select first {
    case x {
       y;
    }
}

x is evaluated, and if it is nonzero, that case block is executed.
Here are some other equivalents:

if (x1) {
    y1;
} else if (x2) {
    y2;
} else {
    y3;
}

is equivalent to

select first {
    case x1 {y1;}
    case x2 {y2;}
    case 1 {y3;}
}

if (x1) {y1;}
if (x2) {y2;}
if (x3) {y3;}

is equivalent to

select every {
    case x1 {y1;}
    case x2 {y2;}
    case x3 {y3;}
}

Why did I do it this way? Cause parsing if blocks is a pain in the ass, that's why. ;)

Concerning action timing:
At any given time, there can only be one action active.  Once that action is complete, the scheduler schedules a new action search.  A new action is not scheduled until it is selected by the action search.  The time between the end of the last action and the start of the next action search is controlled by action wait and action rest. The action search is scheduled for the later of the start of the last action search plus action wait, or the end of the last action plus action rest.

The eat action takes a total of 30 seconds. There is a one minute wait and a 15 second rest.  Thus, once the eat action scheduled at T+00 seconds completes at T+30 seconds, the scheduler schedules for the later of (T+00 + 60 seconds) or (T+30 + 15 seconds), which is T+60 seconds. That's when the next search occurs.

[Poweryoga]

I see, that's fairly complicated in terms of plotting out action.
Regardless, I think it has great potential for simple behavior but
it's not a true AI if you're just programming in preset actions/
behaviors. (Since there's no standard heuristics to match for
pathfinding and no nodes really). Still, better than anything I could
come up with. :)

@zug

I've done the same exact thing in C# (container objects for a generic
yukkuris (polymorphic) + basic random walk), I can send you the source
code if you want. To be honest, programming a good random walk is non-
trivial (much like moving a camera around in a circle!) and you
shouldn't spend too much time trying to make it perfect. Trust me,
I've been there before and it took about a whole week just to make my
yukkuri bounce around like an idiot. There's a reason I like some
level of transparency in terms of goals that you are reaching for,
because chances are I've probably done a lot of the work earlier last
summer. Why double back and start from scratch if all you need to do
is translate C# to C++? ;)

On Jun 18, 6:42 pm, Toawa <pap...@gmail.com> wrote:
> Fixed the open bug; it will be in the next build.
>
> Concerning tick and actions, it helps to understand how the scheduler
> works.  The scheduler holds a bunch of events in a priority queue,
> letting them out in the order of their scheduled execution.  The tick
> value specified in the tick statement controls how often the scheduler
> is run.  Once the scheduler is turned on, it continues executing until
> it's run through an amount of real time between the previous tick and
> the current tick.  Once it reaches that point, it stops and returns
> control to the program so that it can update the display and wait for
> the next tick.  Thus, the only thing you gain by decreasing the tick is
> that the display updates more often.
>
> The delays specified for actions and decay functions are in terms of
> real time, not ticks, so if you want them to run faster, decrease them.  
> The frequency clause on stats controls how often the stat's update
> function is called by the scheduler. (BTW, the syntax has changed; the
> frequency clause is now 'every TimeLiteral' instead of 'update every
> TimeLiteral'.  (The extra update was causing a shift-reduce conflict in
> the parser.)
>
> (For reference, there are currently three types of scheduled actions:
> StatUpdate, ActionSearch, and Action, which updates statistics, searches
> for a new action, and performs an executing action, respectively.)
>
> Concerning if:  |if()| is a function, not a statement. |if(x,y,z)| is

> the equivilent of C's |(x?y:z)|.  To get control flow statements, use

> search is controlled by |action wait| and |action rest|. The action

> search is scheduled for the later of the start of the last action search

> plus |action wait|, or the end of the last action plus |action rest|.

[Toawa]

Well, to be fair, right now there's nothing for them to react to but
time and their own internal variables. ;)

I haven't added any kind of external stimuli yet.

[Zug]

Sure, why not? It may help, C++ and C# shouldnt be so much
different. :)

[Toawa]

Yet another build up. I've added stimulation.

Stimulation acts like stat variables; they can be read from by defined
variables and written to by actions.

'stim' Identifier '=' Number [<Range Clause>] <Stim Type> ';'

The Range clause is optional, and if it is not present it will be
assumed to be 0 to 1.

The two available types are 'slider' and 'button'.

Slider is a slider from min to max.
Button is implemented as a check box; if it is checked, the value is
max. If it is cleared, the value is min. If the value is set in an
action to a value other than min or max, the checkbox is considered
inteterminent.

Defined variables can read from stimulus variables; however they will
only be updated while the simulator is running, and then only once
before each time slice starts running (so don't worry when the numbers
don't change while paused).

[Zug]

I have just finished the wandering yukkuri, tommorow Ill make its
movement more smooth, edit the code so Its readable when I post it and
maybe Ill also add some basic animation.

[Toawa]

Redirecting back to this thread, so we don't splinter.

Yes, stims. Stimulation. User modifieable variables.

stim Test = 0 from 0 to 1 slider;

would be a slider from 0 to 1. There's also a button. (It's a checkbox
in the last upload, it'll be radio buttons on the next one.)

[Poweryoga]

Zug:

The random-walk routine that I have isn't perfect. It takes a random
number each time and uses that to determinate the motions it should
take. I don't have it stopping in place, it just kinda bounces around
like a broken pogo stick.

Parameters: Type modelobject and takes in a modelobject to modify, and
takes in a random # seed. Modelobject is just a 3d object, you can
imagine it having 3 axis to traverse. The modelobject checks to see
if it has finished bouncing (don't worry about the details) and then
gets the next direction, returning the updated x and y axis of the
modelobject so that XNA will draw it in the new location.

PS: Bad programming practices everywhere. Don't do what I do, just
take the basic ideas. :P Let me know if you want the generic
container object yukkuri as well, though I think it will be hopelessly
more complicated because my object is 3d and there's a shit load of
variables and functions that I wrote specifically for 3d model
objects.


class AI {

public ModelObject autoMotion(ModelObject myball, int seed)
{
Random random = new Random(seed);
float waitTime = 400; //not used

if (myball.gravity.finishBouncing == true)
{
myball.gravity.Direction = random.Next(0, 7);
myball.gravity.finishBouncing = false;
}

//-1 = bounce infinitely
myball.yloc = fullGravity(myball.gravity, -1);

if (timer < waitTime)
{
//fuckit
}

//update location
myball.direction = myball.yloc;
return myball;
}
}



@Toawa: I will take a look in a bit.

[Zug]

http://www.megafileupload.com/en/file/243246/Yukkuri-game-zip.html
Ok here is the wandering yukkuris if anyone's interested. Ill try to
post code soon.

[Tea]

I get an error trying to run it. "This application has failed to start
because alld42.dll was not found".

[Zug]

Oh yes, Ill fix that and repost it.
http://www.megafileupload.com/en/file/243261/Yukkuri-game-zip.html
It should work now.

[Poweryoga]

Works on my rig. Looking forward to additional features!

[Poweryoga]

Also, is there any plans to make the sprite animated?

[Zug]

ofc, but ask someone who can draw for the details :)
all I can say is that size of yukkuri sprite is 200x150, someday we
can make koyukkuris and maybe dosu but this is size of basic yukkuri
so if you intent to make a sprite you can use yu2.bmp as template for
size but not for drawing, it looks horrible :)

[Zug]

Sorry,cant do it no matter what I do :) . Its alien technology for
me,I never heard about it let alone worked with it. I uploaded all
code on this site under the name YGcode.zip

On 15 čvn, 22:59, Poweryoga <nospam11...@gmail.com> wrote:
> Version control (depending on if you use subversion or mercurial) is
> controlled by your subversion client.  Anybody can check out code but
> you need to assign an admin and commiter for the code, if you have
> more than 1 person in the group.
>
> From a forum post for an example on using cygwin:
>
>     using svn under cygwin to upload any file to your depot.
>
>     - install cygwin subversion.
>
>         (see cygwin install fromhttp://ist.berkeley.edu/as-ag/tools/howto/cygwin.html)
>
>     start a shell > export SVN_SSH=ssh$
>
>     > svn import $some_file https://$your_project.googlecode.com/svn/$some_file
> \
>
>         -m $some_message --username $your_user_name --password
> $your_password
>
>     delete a file from the depot
>
>     $ svn delete https://$your-project.googlecode.com/svn/$some_file \
>
>         --username $your_user_name \ --password $your_password \ -m
> some_message
>
> Alternatively if that's too complicated, you can just post up the
> project file (assuming you're using visual studio) in a little file
> down in the files section and I'll clean it out here once in a
> while.
>
> On Jun 15, 3:54 pm, Tertius <numerus.tert...@gmail.com> wrote:
>
> > On Tuesday 15 June 2010 21.44.36 Zug wrote:
>
> > > On 14 čvn, 19:02, Poweryoga <nospam11...@gmail.com> wrote:
> > > > If you want to start up a codeproject (http://code.google.com/
> > > > hosting/) so that the source is open, I can help debug and what not.
>
> > > Ok I give up, how do I post a freakin code there?
>
> > I'm guessing
>
> > 1. svn co <url-to-repo that google code displays for you>
> > 2. make changes
> > 3. commit changes
>
> > But then, I've never used google code before.

[Toawa]

If you're using VS, there's one called VisualSVN. Downside is that it's
$50, but it's a nice program; it integrates into VS. It uses another
package called TurtleSVN, which is free (and open source, I believe),
but which only has Explorer integration, no VS integration.

[Zug]

BTW what do you suggest I should code next? I think I should do the
boring stuff first like change program so it works with container
instead of sole object and GUI so we can then work on details of a
good stuff because those tiny details make games awesome,lots of
sprites,smooth animations and so.
And someone could replace my ugly sprite (yu2.bmp) with something
nicer, but it should be something he drawn so we dont have all frames
of animation different. Come on, there have to be someone who can draw
nicely :)

[Three]

I'll have a basic sprite up by late Monday/early Tuesday hopefully. A
little busy with family stuff and schoolwork so I haven't had time to
scribble.

[Poweryoga]

@Zug:

It depends on what you're looking to do overall in the program. The
program itself looks relatively simplistic, so now what you can do is
try to animate the sprite. Do you know what kind of format allegro
needs your sprite to be in and how to work with it?

I'd test with a sample sprite from somewhere on the web while others
finish up their sprite. I'm not sure what you mean with the container
objects though, because to my knowledge STL containers just hold a
bunch of objects, which is not something you really need since you
already got the yukkuri class setup.

[Zug]

Ok Ill try to make 4-5 framed animation of walking in each side. Far
as I know allegro takes only *.bmp files as sprites. I know how to
make animation and how to work with buffers, is there anything more I
should know to do with sprites besides the basics? I think Ill need
container for things like for example wander() function. Program only
calls it for that one object. Leater when we gonna have more yukkuris
which can get in or out of game any time then I gonna need container
because I cant code it for every single yukkuri ,that would be
busywork and it would be really limited, I need to make functions and
such to be called for every member of that container no matter how
much of them there is, but I dont have much experience with containers
so maybe you are right.

[Poweryoga]

From what you're saying it sounds like you meant classes and class
functions rather than containers. You are right though, from what I
see here you can do with a bit more organizing of your code.

For example: in your UpdateScreen() function:

if(reimu.getX() < 0)////////////// few lines that will take care about
that our reimu wont leave the screen.
{
reimu.chaX(0);
}
if(reimu.getY() < 0)
{
reimu.chaY(0);
}
if(reimu.getX2() > screenW)
{
reimu.chaX(screenW-200);
}
if(reimu.getY2() > screenH)
{
reimu.chaY(screenH-150);
}

You should toss that into the Reimu class into something like the
following to prevent huge blobs in your main code...

void CheckBounds(int screenW, int screenH){
if(getX() < 0)////////////// few lines that will take care about that
our reimu wont leave the screen.
{
setchaX(0);
}
if(getY() < 0)
{
setchaY(0);
}
if(getX2() > screenW)
{
setchaX(screenW-200);
}
if(getY2() > screenH)
{
setchaY(screenH-150);
}
}

Couple of notes:

1) Don't directly set variables in your class. It's easier yes, but
it's good programming practice to write a function that will set your
variables to retain abstraction. (i am guilty of it myself
sometimes :P)

2) anything that you need to pass in a specific yukkuri to do (draw
for instance) I'd suggest moving to the class object. I did the same
thing for my 3d game and it was a whole lot more scalable.

3) there's not going to be any way around adding more yukkuris by
hardcoding unless you start using STL containers. (not the containers
you're referring to!) I suggest a linked list of object type
yukkuris, so it's easier to loop through and to add and delete
elements. Note: This could be complicated concept wise, so let me
know if you need help.

4) suggest making an Init() function for your class, and move the

reimu.chaX(400);
reimu.chaY(400);

up to the init function, and just call reimu.init() instead. It also
sets a good function for the future in case you decide to add more
functionalities to the yukkuri like health, mental level, personality,
etc.

5) Your random() is not seeded, so your yukkuri'll always move the
same way. toss in "srand ( time(NULL) );" first.

[Tea]

To help until Three can get his sprite done, I've uploaded the sprite
sheets I made for use in my own game. Perhaps you can use these in the
meantime or as placeholders.

http://h.imagehost.org/0128/Reimu_cry.png
http://h.imagehost.org/0021/Reimu_cry2.png
http://h.imagehost.org/0087/Reimu_death.png
http://h.imagehost.org/0409/Marisa.png

[Zug]

Can do.
1. Never heard about that kind of good practice but ok, now I do.
2. Can do.
3. List, map, deque and so are what I ment but as I said you might
think its something else because I said something wrong befer I never
worked with them much.
4. Can do.
5. Didnt knew about that because it does moves randomly on my PC . Ill
try to fix that.

[Zug]

Thats the kind of sprites I would like to have in game,especially the
marisa one just without such (O O)-ry eyes, but those arent really a
problem.

[Zug]

Thats the kind of sprites I would like to have in game,especially the
marisa one just without such (O O)-ry eyes, but those arent really a
problem.

On 21 čvn, 17:45, Tea <teama...@googlemail.com> wrote:

[Zug]

I think I forgot something, am I suppose to put srand ( time(NULL) );
in begining if random function?

On 21 čvn, 16:47, Poweryoga <nospam11...@gmail.com> wrote:

[Poweryoga]

Yes. That seeds the random function with system time. Otherwise the
rand() will always generate the same set of random numbers, so the
yukkuri will always move the same way every time you boot up the
program. Don't get me wrong, it's still random, but everything's
always the same random numbers.

>>1. Never heard about that kind of good practice but ok, now I do.

I meant when you're trying to set a class variable, you shouldn't call
the variables directly. If possible, you should always call a
setVar(blah) function to change your variables as opposed to making it
public. Your class variables should always be private as opposed to
public if circumstances allow. It's not necessary for a yukkuri game
but in the industry people are more concerned about little things like
that.

ex:

yukkuri Reimu;

x = 5;

[
Reimu.x = 5;
]

vs

[
Reimu.setX(5);
]

Sorry if I didn't word it very well.

[Zug]

I think I know what do you ment but Im just saying that Im more used
to contstructors :)

One small question, loading of bitmaps take "lot" of system time
right? I mean if Im going to do animation Ill better load all the
bitmaps into classified data file (DATAFILE* or BITMAP* for each
sprite which would be lame) instead of reloading the bitmap into one
BITMAP* every time when frame of sprite changes, right?

[Toawa]

Yes; you should definately preload all of the images you're likely to
use. Gone are the days where you have to be worried about how much you
load (within reason). Also, you must be careful to release those images
when you're done with them, otherwise you will get a memory leak.

[Zug]

Destructor will mostly take care about that. In my first game, 1 level
sokoban, I was reloading them with every move (box was only state of
tile) and it got really slow before I put delete line there.

[Zug]

http://j.imagehost.org/download/0268/BWGcolored
Today I was little lazy for coding so I drew copy of Marisa which Tea
posted. If I will be able to draw it nicer and without looking at
original I may draw other sprites as well, I didnt really drew this
one as sprite but it has a size my sprites use.

On 21 čvn, 17:45, Tea <teama...@googlemail.com> wrote:

[Three]

Okay, here's the first Reimu movement thingie. Each one is in a
200x150 box. Let me know if needs to be in a different format or
something's wrong with it.

http://j.imagehost.org/0725/yukkuri_sprite_base_reimu_test.png


And how I wish I had a scanner.
http://a.imagehost.org/0873/yusketch_004.jpg

[Zug]

Ok thanks, I think I can use it for now.

[Three]

Cool. I can upload a .bmp if you need it (you mentioned .bmp earlier I
think?) and/or post each sprite as individual images if need be.

I'll work on figuring out expressions next and the other types or
something.

[Zug]

Yes, bmp. I would prefer each one individualy and dont work on sprites
we dont need yet, better add more frames to walking animation.

[Three]

Sprites cut and saved as .bmp:

http://h.imagehost.org/download/0948/reimu_back
http://a.imagehost.org/download/0071/reimu_down_left
http://a.imagehost.org/download/0374/reimu_down_right
http://a.imagehost.org/download/0269/reimu_front
http://j.imagehost.org/download/0172/reimu_left
http://j.imagehost.org/download/0981/reimu_right
http://j.imagehost.org/download/0877/reimu_up_left
http://h.imagehost.org/download/0283/reimu_up_right

[Zug]

Thanks. Ill take a break from coding for few days, Im really not in
the mood now, then ill add them to animation.
I have been also drawing today: http://j.imagehost.org/download/0004/right
Worse then previous try but now I almost wasnt looking at other images
and it also didnt took me over 9000 hours in SAI. I think I should
make it look more fat and less like head.

[Tea]

> Sprites cut and saved as .bmp:

I'm not sure, but watch out as it looks like you've managed to
introduce some artefacts into the images... be extra careful when
you're editing them.

Zug, that's actually a pretty good try, especially if you did it
without looking at any other images. Keep practising!

[Poweryoga]

Agreed. Real good sprites all around, especially without spending
9000+ hours.

[Zug]

Ok, Im back in bussines. Today I have done animation using datafile
instead of bitmaps. It has only pictures of arrows with number of
frame but I would need 4 frames in each direction and 4 frames for
animation for standing on place but thats just detail. At the moment I
trying to make standing animation when yukkuri tries to go away from
screen so it doesnt look like it is running into a wall.