Scroller speed bug found!

One of many bugs was that the scoll speed on fish appeard to be slower after an restart of the game, even though the velocity.x remained the same. It would seem that scroller.stop() that is a method inside of the Scrollable class, that extends all scrollable game objects does something to our fish that makes it move slower. The origin has been found, but the reason remain unsolved. However since we have states in our game, we can simple chose not to update the scroller classes when the frog dies. Therefore a stop method is perhaps not necessary even if it would be more correctly architectured with it.

Week 4 html up!

Week 4 HTML build is up with A LOT OF BUGS!

Here!

Implementing fish jump physics into the code!

After calculating the equations for the fish to jump at the correct X position it was time to implement it into the code. Now there still might be a lot of errors and bugs that needs to be taken care of. And the fish physics are acting weird after the game restarts. There is a lot of debugging that has to be done, and I already put several hours into it without finding the solution, or even the problem for that matter.

Anyway this is how the implementation of the algoritms looks,

Fish gravity

Axel and Steven spent the morning trying to freshen up their memory on trajectory calculation. We had to calculate when the fish animation was supposed to start, since we need to have the fish at its maximum position when it is at the frog's position, that is, we need to have the fish at max when the frog has jumped and is right above it (if the frog has the appropriate power).

So the things we needed to calculate was the Y max position of the fish, given a certain initial velocity and the time it will take for the fish to reach this maximum.

Maths and stuff

 We used a combination of Wolfram Alpha and our own old physics notes to get the formulas.


Since our game is a never-ending runner type of game, we need to have continuous obstacles spawn for the frog to jump over. But since we ever only show one the fish at the time, we actually only need 2 instances of our Fish class object, once one of them go out of frame to the left, we move it to the right of the other fish instance, which is by then just out of frame to the right side of the screen.
Axel spent the afternoon implementing this.

Fish jumping out of water (the grey rectangle is a placeholder for the fish).

Steven spent the afternoon implementing the formulas from the morning. He'll make a separate blog post on that adventure.

More detailed graphics

We started to do some detailed graphics today with the water, background image and the main menu. The origami style have been quite challenging because it's hard to define how many geometries we should use for each object. The frog itself got less geometries than the tree in the background which can maybe look weird in the end. 

Maybe we will have to have the most important graphics as detailed as possible so they stick out more and have the background etc less detailed. Right now we don't really consider the color saturation, it will be changed in a later phase. 

Graphic style and the overall theme changes

We have have been thinking about the art style again. A friend of ours thought that the frog looked like it was folded paper, so we are considering to go for a origami looking style. It won't be that different from what we first thought but maybe we will have gradients instead of solid colors, as well as no circle geometries.

There has also been changes to the overall graphic theme. Instead of having the frog jump over nettles we will have the frog jumping over fishes that will come out of the water trying to eat him. The frog will jump from one water lily to another and between those is where the fishes will try to catch him. 

We did some progress on the animation part, where we created a landing animation. Some placeholder graphics were also added. 

Best productive day yet!

So today we added a lot of graphics into the code, I was mainly fixing our scroller class and implementing paralax to work with our game engine. I fixed a lot of smaller bugs with the animation, cleaned up code in most classes.

Most of the code which I implemented today was not anything groundbreaking or new, it was just getting everything to work with the new graphics that we were being fed. Here is an screen shot of the game as of now.

I'll update this post about what was done and why later!

Over and out.

Never give up, never surrender!

SO FINALLY!

I remade the whole screen architecture for the game, with a solid hashmap to store all the different screens that our game will have (splash, main menu, game, highscores etc.).

The code was pretty much straightforward, and I did not hit any bumps, it was just a lot of code to be switched, updated and added. Until I wanted to jump some with the frog. It was gone.

A quick debug session made me realise that the delta value that was being fed to update was way off. The update is using the delta time which is the last time since the a frame was rendered. This delta time value makes the game logic run the same on a device with 12 fps as a device with 60 fps. But as I said it was crazy high. It should be a value of about 0.015 seconds, instead it was counting seconds and going up.

Since I remade the architecture of a lot of update and render methods, I no longer had update(float delta) methods, all my update methods took no variables in the parameters. So I created the delta time using

delta += Gdx.graphics.getDeltaTime();

which is pretty bad because it basically just says how long the game had been running, or since the delta value was resetted.

It took me however a solid 30-40 minutes to figure out this stupid error. Mainly because I am tired. But the solution.

This returns the correct delta value, it prints the smallest value between the .getDeltaTime(), which is when the last frame was added, and 1/60, which forces it to be 60 fps, if needed.

Anyway, the architecture is taking its final form. 

Splash screen!

Added a splash screen to the game, took like 5 minutes, but recoded some architecture to made the implementation of the main menu easier. Which was basically why I did it. But we still have to figure out how we want to handle the swapping between the screens. My experience says store all the Screens in a hashmap and make a custom method for swapping between the screens in a Main.java class. Will need to look through other solutions to motivate why we would do it like this.

HTML5 up and running!

So for fun sake, I decided that the integrated HTML5 feature could not go to waste. And I setup a webserver that runs the game through javascript.

The build was done in gradle with the command:

./gradlew html:dist

which creates all the necessary files in html/build/dist folder of the project. Of course as always there was some tweaking before getting it to work. Nothing is that easy. But changing the android sdk path

On Linux/Mac OS X

set ANDROID_HOME/Path/To/Android/SDK (Applications/sdk)

is something that has to be done nevertheless.

So now you can visit this site to get to the week 3 progress of the game!

Enjoy!

Bugg in android and ios

So after a lot of hair pulling, curses etc, we created a hypoteses about why our frog would be invisible on our devices but not on the desktop application. I made a debug where we finally saw that the frog actually fell through the bounds of the screen. I believe it is because the frog is created before the ground, and falls through it before the ground is created!

The fix will be to create a start state so you must push the screen for the game to start, this will probably solve it. Hopefully that is the problem!

over and out

___

Yep that was the problem, bug resolved.

Swarm API

A downside with libGDX is that since it generates the iOS and Android code from regular Java code, we cannot make use of the standard Facebook API to have users login, share high scores etc. We would have to write our own library to convert both iOS and Android. Instead we have looked at a framework called Swarm.

Swarm has functionality for leaderboards, achievements, monetization and social features. It officially libGDX. With Swarm you can either create your own Swarm account, or log in with Facebook, Twitter or Google+.

We have followed a small tutorial to implement leaderboards and achievements to a test app. It works for Android, but we have not yet tested it on an iPhone. Though it was a little bit fiddly to link everything up correctly, the only real issue we had was with SwarmActivity not properly merging into the app's AndroidManifest.xml (a file that is used to declare how the app is supposed to be built, there's usually one Activity  declared for each new screen in the app). Instead we manually added SwarmActivity to the manifest, which fixed the problem.

A problem with Swam was that the leaderboards automatically has ads in them, which we can't seem to control. Meaning they will potentially be making money off of our game.