LucidLyes

Matlab de Hakken! Fan-made vintage Tamagotchis

Recommended Posts

22 hours ago, LucidLyes said:

I've programmed the game so that Shirobabitchi evolves into Tomarutchi in 65 minutes and Tonmarutchi evolves into Hashitamatchi in 48h. So basically you get Hashitamatchi after 49h. So it's highly probable that during the catching up phase, your Shirobabitchi evolved, died (it doesn't take long for death to occur, just a few hours without food or games) and then STILL evolved (I haven't programmed it so that it doesn't update the Tamagotchi after it died) into Hashitamatchi and the bug happened and crashed the program.

So, a Tamagotchi Zombie briefly existed, but it missed Halloween. :P

 

12 hours ago, leogames2012 said:

Sharing the roms Is Legal but only if you have the game,

Not even then. People treat it that way as a moral concern, but it's not the letter of the law.

  • Like 1
  • Haha 2

Share this post


Link to post
Share on other sites
14 hours ago, Penguin-keeper said:

So, a Tamagotchi Zombie briefly existed, but it missed Halloween. :P

I have a vision of programming the Santaclautch around christmas but I don't think that's going to happen.

Edited by LucidLyes
  • Like 3

Share this post


Link to post
Share on other sites

So I haven't been able to work on the project since Tuesday because of a quite busy schedule followed by fatigue but I was able to solve an annoying issue on the Android app. With this issue fixed the basis of my Android Tamagotchi app has been laid down so I can now start implement the same Tamagotchi mechanics that I used in Matlab de Hakken

Here's a screenshot of the app. This shirobabitchi is animated:

Screenshot-2020-11-13-16-17-34.png

Here's an apk of the app if you want to check it out for yourself

https://drive.google.com/file/d/1yc-BHJS-NEzu43CAlOTuqrgGbb70TLLR/view?usp=sharing

 

Edited by LucidLyes
  • Like 5

Share this post


Link to post
Share on other sites

Hi!

So I've been working on the Android project some more these last few days and made relatively rapid progress. The difficulties I have with android programming are related with putting everything in place when starting a new app, but once that's done I'm usually almost as fast as in Matlab.

I've added the logic for a menu and the "eating" animation. The Tamagotchi will eat 4 times and then say no. You can skip the animation. I don't have graphics for the food yet so the Tamagotchi's only pretending to eat. I haven't programmed it to lose hungry hearts yet.

The graphics are once again ripped off from the Tamagotchi Simulator 3 since they were more readily available than the ones I've been using for my Matlab app. I'll be using my own as soon as I get the chance to convert them from the tiny bmp files I manually drew on my PC to some larger PNG files which are more recommended for Android development I think.

Here's the link for the apk of the latest build:

https://drive.google.com/file/d/1EyJ3MlgUDKEo-apMhrn9vv7T3HyJng8I/view?usp=drivesdk

keep in mind this is only for the most curious of you guys, the app has very little utility so far.

Since I'm coding this on my phone and not on the laptop I should (paradoxically) be able to advance at a more steady pace because I can code just about anywhere and at any time. I hope development will go smoothly.

  • Like 3

Share this post


Link to post
Share on other sites

Just tried out the apk and it's really coming along nicely! Didn't realise how much I missed the status screen while it was gone.

Just some feedback, I'm still able to feed the tamagotchi while it's sick, and the sprites appear a little blurry. I think it might be due to the anti-aliasing?

  • Like 3

Share this post


Link to post
Share on other sites
49 minutes ago, Eggiweg said:

 

Hey Thanks!

About the sickness thing, that's already fixed. The first hour of gameplay (The Babytchi stage) is now completely implemented. I'm currently trying to implement a basic save system.

About the blurriness, it's bothering me to no end as well but from what I've read there's not much I can do about it (besides using larger sprites of course). I'm keeping this fix for the latter stages.

I'll upload a more recent version later.

  • Like 2

Share this post


Link to post
Share on other sites

Here's my latest build:

https://drive.google.com/file/d/11lWpo4eLhYIC8nGedjK_7i4ZH5wJjWgN/view?usp=drivesdk

I think it's pretty much self-explanatory. This time I've actually implemented the P2 game instead of the P1 (@Tamacass).

Only thing you should know is that everything happens based on a timer that keeps advancing when the app has focus and is paused when the app is in the background. Events happen based on this timer, which you can reset by disciplining the tmgc. Babytchi must evolve 65 mins after being born, but in this version it doesn't, and nothing happens after a certain time. So if you want anything to happen after this point you should reset the timer by disciplining tmgc.

 

  • Like 3
  • Haha 1

Share this post


Link to post
Share on other sites

I used to say that the "catching up" period of my Matlab de Hakken PC app took around 8s for each hour that passed since the user closed the app. I eventually realized that that was completely wrong. My wife's i3 laptop took approximately more than a minute for each hour, which means that if you just close the app at night and open it up in the morning it can take around 10~15 minutes to catch up, which obviously is unacceptable.

I thus decided to work on a smart way to do the catching up and it's turning out to be a really complicated process. Mathematically it can be done without having to guess anything. But to program the behavior is the real challenge. I like programming challenges. However, you probably won't hear from me for a short while as I'm now going to delve into it completely until I figure it all out.

Edited by LucidLyes
  • Like 4

Share this post


Link to post
Share on other sites
On 11/20/2020 at 10:10 PM, LucidLyes said:

 

 

On 11/21/2020 at 4:59 PM, LucidLyes said:

I used to say that the "catching up" period of my Matlab de Hakken PC app took around 8s for each hour that passed since the user closed the app. I eventually realized that that was completely wrong. My wife's i3 laptop took approximately more than a minute for each hour, which means that if you just close the app at night and open it up in the morning it can take around 10~15 minutes to catch up, which obviously is unacceptable.

I thus decided to work on a smart way to do the catching up and it's turning out to be a really complicated process. Mathematically it can be done without having to guess anything. But to program the behavior is the real challenge. I like programming challenges. However, you probably won't hear from me for a short while as I'm now going to delve into it completely until I figure it all out.

You know what, I think I should get back to this once I've implemented everything else, because an efficient "catching up" mechanic will take quite a while to implement (the more I think about it the more complicated it turns out to be). It reminds me of these riddles one would give you which would keep your mind busy for days and days until you figure it out. (I feel like I'm programming a rubik's cube solver, without knowing how to solve a rubik's cube) I'm pretty sure only research-level programmers actually bother to delve into solving mathematical problems such as this one. Since I'd learn absolutely nothing in Android programming by forcing myself to solve this problem, I'm thinking I should go back to programming all the easy stuff and then I'll get back to it once everything else is done.

Edited by LucidLyes
  • Like 4

Share this post


Link to post
Share on other sites
7 hours ago, LucidLyes said:

 I'm pretty sure only research-level programmers actually bother to delve into solving mathematical problems such as this one. 

Not quite, but kind of:

http://www.cs.toronto.edu/~heap/270F02/node54.html

Good news is, now I have a name for it (it's an Event Driven Simulation) and I can learn more about how implement one.

Edited by LucidLyes
  • Like 4

Share this post


Link to post
Share on other sites

So based on the name "event driven simulation", a few videos and a few paragraphs, (and a lot of programming trial and error) I figured out that I didn't need to start reading lessons about Event Driven Simulations or anything. I just took the general idea and tried to apply it to a tmgc. At first I had trouble doing it but then at some point it became so obvious I couldn't think of any other way to do it.

For those interested I'm going to try to explain what the problem was and how I've found my way to solving it. I hope it won't get too tedious.

The problem is, be it in the PC or android version, there has to come a time when the user shuts off the program and/or machine. A real tamagotchi obviously doesn't have this issue but if you're going to code a PC or Android app, having a save feature is mandatory.

But the save feature isn't just your average save feature that just saves the tamagotchi's current state and loads it back up when you re-open the program. It has to actually simulate the passage of time until the moment when the user re-launched the app, to give the user the impression that the tamagotchi was still alive after shutdown.

Now this simulation is what I was referring to as the "catching up" mechanic. When you clicked "close window", the program would just save every necessary bit of info about the tmgc. Upon loading it would calculate how much time has passed since shutdown and simulate every time step from last shutdown to this re-launch. I erroneously said that this took about 8s for each hour that the app was closed, but that was so far from the truth it wasn't even funny. In fact the app took more than a minute to simulate each hour, which might be acceptable for a really patient and dedicated user (i.e. me) on a PC, but for the android app this is just impossible to work with.

So I thought of a way to speed things up by only simulating time instants where something *actually* happened. So for example if all that happened between shutdown and relaunch was the tamagotchi lost a happy heart, just take off one happy heart and let the user play normally afterwards. 

But how do you know what's going to happen when the user leaves without knowing when he/she's going to come back? Easy! you just assume the user is not coming back at all and predict events up until the tamagotchi's death, each event being associated with a given time stamp. If the user comes back after the last event (death) then just give a (creepy and disturbing) death screen. If he comes back before that, find out where in the predicted timeline he has returned and apply all predicted events up to the user's return. Ta-daa.

But then how do you start predicting events? Well, that was the tough part. You might say, "the tmgc still has 3 hearts and lost its last heart 30s ago, so it's going to lose another heart in e.g. 3600-30=3570s." The problem is, a LOT of things can happen to a Tamagotchi that's not taken care of. And some events actually modify the instant when other events happen. For example, if you predicted that the TMGC should lose a heart in 1000s but fall asleep in 300s for 12h, obviously the heart loss should be postponed to 12 hrs later. So the sleep event is an example of an event that modifies the other predicted events and you should pay attention to when the tmgc is going fo fall asleep... if it's not already sleeping that is! The "evolution" event is even more nightmarish because it both depends on previous predicted events (care misses) AND it modifies heart loss instants, sleep/wake up instants etc.

This is hellish, so that's when you need math.

In event-driven simulation, you predict the time when a lot of events (in our case, heart loss, poop, sleep, sickness etc). are going to happen next and only care about the closest one (in time of course). Once you know what the next event will be you can modify the predictions made for other events if necessary. This is an iterative process that in our case is stopped whenever the tamagotchi's death is the next event. As soon as I figured that out I instantly found my way towards solving the problem (and my sanity).

So today I've been able to implement this prediction of all possible future events up until death except for the dreaded evolution event. I'm going to leave that for tomorrow and hopefully start implementing this in the PC or Android version of the app (I'm coding all of this in a separate draft program just to get the hang of things).

Now this was only a part if the whole system, the other one being the process of finding out where we are in the list of predicted events and applying them up to the current tamagotchis state. I'm not too worried about that though, this should be a trivial task.

I wonder if the complexity of the algorithm is the reason why Tamagotchi Simulator 3 and Eternitchi just freeze the passage of time when you close them. What do you think?

Edited by LucidLyes
  • Like 2
  • Thanks 1

Share this post


Link to post
Share on other sites

 

On 11/25/2020 at 12:49 AM, LucidLyes said:

Now this was only a part if the whole system, the other one being the process of finding out where we are in the list of predicted events and applying them up to the current tamagotchis state. I'm not too worried about that though, this should be a trivial task.

Well, it wasn't as difficult as the first part but it wasn't "trivial" either. It took me a while to figure out the simplest method to get this done, and there's still work to be done on the "future prediction" system because I didn't take the Babytchi and the Egg stages into account. The advantage however is that based on a few tests, this algorithm should take less than 5 ms upon closing the app and 5 ms upon reopening it. And it won't take any longer to predict what happened to the Tamagotchi if you've left for 12 hours than if you've left for 10 minutes :) . That's about more than 100000 times faster!

This project is really putting me to the test but it hasn't heard the last of me. I'm planning to finish the Matlab version before the 15th of December (or as soon as I can really). I've made it a personal goal of mine to finish this project completely, because I got tired of starting projects and never getting them done. I hope I can make it before the next "work thunderstorm" (as I like to think of them) arrives.

Good day or night!

  • Like 4

Share this post


Link to post
Share on other sites

After a huge amount of work, I can now say that my faster catching up mechanic is functional. Now don't get me wrong, it's probably still crawling with bugs that I now have to hunt down and fix, but I think as long as the user starts his/her new egg in the day (from 10 AM to around 4 PM) there should be no problem. I'm going to continue working on this for about a week to iron out as many bugs as possible, and I'll be releasing a 3rd build of the Matlab version of the app around December 15th. After that I think I'm going to only focus on Android development, except I make no promise whatsoever on if and when I will be delivering a complete app, because "Winter is coming" at work, and I'm already bracing myself.

  • Like 3

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.