next »

[Alex N.]

Just played it for 20 minutes now. Fun stuff! I like the adjustments and the direction in which it's going. Keep up the good work

[microrignal]

Thanks Mr.Jail!

This thing is slowly getting out of hibernation. When I'm done porting the code to Cocos2d-js, I'll overhaul the layout once again - probably forever. Here's a mockup.

[microrignal]

I don't want want to be tooo incremential with my updates, but here's another potential screenshot from the future. Spot the differences ha ha  



I prefer this version of the layout as it seems more appealing visually and directly connects the spoiks multiplier to its countdown (the color inside of the big multiplier text will be animated as a slider as it depletes every turn). The other one had a couple things going for it, including being more clear about the actual number of turns left until depletion, but it's something I could adress with the newer one, by making the number of turns left briefly show in place of the multiplier after a move or whenever you click on it.

In any case, let me know what your brain thinks.

[microrignal]

More fiddling with the layout. I like this one quite a lot. You can see that you're doing well if there's more red on the right side than there is on the left.

 

On another note, since forever the player's level (raised by killing monsters) and the difficulty level (the floor, raised behind the scenes as sectors are visited) have been independent from each other. The idea behind this was to encourage the player to try and level up faster than the game would. I don't think that mechanic is necessary anymore, since the spoiks multiplier (and the ever-depleting health) now provides a good incentive to reach the next level. Thus, the concept of a separate "floor" will disappear in favor of a single "level" stat, raised by killing monsters as has always been.

[microrignal]

The multiplier bar is back.



All those extra grey squares are just there to show how easy it will be to fit more HP/XP in there. Much better than the current system.

[microrignal]

HEARABLE STUFF BELOW!
========================
Oh là là... long time no see.
Farming (as in, vegetables) is devouring my time. But. I think I see the light. Again.

PROOF: A first version of Spoïks' 'theme song' oooooooh: On Soundcloud

I'm doing this.

[microrignal]

Okay. The first step for for me to get things rolling again is to figure out which framework(s)/tool(s) will suit my needs. I already wrote that cocos2d-js looks very promising, but I've been weighting more options these past few days. Here's a recap:

Platforms to be targetted

- Android
- Web (desktop and mobile)
- Windows, portable (no installation required)
- (IOS is a plus, not a must)


Options considered so far :


PHASER
The framework the game is currently built on

PLUSSES:
- Free and Open source
- Super lightweight and portable project folder
- Great performance for web
- Making a portable .exe for windows from the web version works flawlessly using nwjs/Web2Exe

MINUSES:
- No native Android export. Actually possible to achieve trough cocos.io, but performance is unsatisfactory and I hit a wall in the past (android app didn't launch half of the time).
- No visual IDE, only code.
- At this point I need a solid javascript editor to work efficiently. Webstorm costs 60$ per year


COCOS2D-X (Cocos2d-js)
PLUSSES:
- Free and open source
- The best performance I've seen on Android, fantastic for web as well.
- Seems a bit obscure at first, but actually quite solid. Pretty much everything works as expected
- Great scene structure/hierarchy. What you'd expect. I prefer it to Phaser in that regard

MINUSES:
- No visual IDE
- Here again, I'd need Webstorm
- Here's where it really hurts though: Windows export doesn't produce a portable folder (requires VC++ redistributable) and last time I tested the web version didn't cope well with Web2Exe at all


COCOS CREATOR
Been checking that one out today. It's fairly new.

PLUSSES:
- Free
- Has an integrated IDE kinda similar to that of Unity
- Engine is based on Cocos2d-x, which is pretty great as stated above

MINUSES:
- Though promising, more unstable than Cocos2d-x at this point. Youger too. Supports less export platforms
(though the ones I want are supported), some features are missing and documentation is not always up to date
- From what I've read, performance doesn't match that of Cocos2d-x either
- Has the same problem as Cocos2d-x when it comes to exporting for Windows. Web2Exe mostly works, but when testing with the "first game" tutorial game project there's a couple-seconds pseudo-lag when loading a scene and the sounds don't play. NOTE: My test with Cocos2d-x was different (I tried to convert a more complex app in that case).


UNITY
PLUSSES:
- Solid, lots of resources available
- Exports to whatever platform your hearts might wish for
- Windows export results in a nice, simple, portable folder
- From what I've seen, super convenient and fast workflow thanks to the integrated IDE
- It's about time I learn it?

MINUSES:
- Web export targets webgl only (as well as unity web player), no canvas
- Closed-source
- Costs 35$/month or a « made with unity » splash screen at the beginning
- Seems kinda overpowered for such a minimalistic, 2d game. I suspect I wouldn't get the best possible performance.


Bottom line

I see two options emerging:

A) The safest path to victory: Do it all with Unity.

B) The more daring path to the best performance and completely transparent/reusable code: Buy Webstorm, keep using Phaser for the standalone exe version (and possibly the web one) and Cocos2d-x for the Android/iOS version (and possibly the web one). The idea would be to replace all framework-specific code in the game logic by higher-level functions that would, in turn, run framework-specific code. In other words, have all the framework-specific code in one place to be able to switch between said frameworks easily by replacing one file.


How would YOU do it? I'm super ears for your magnificient input.

[microrignal]

Today I purchased a license of Webstorm*. As you can deduce from that, I'm definitely going for a Phaser/Cocos2d-js mighty hybrid shapeshifting version. The process of wrapping all of Phaser-specific code in one place has started and is going well.

*That's my first expense ever for this project. Gasp!

One or two days a week is all I've got to push this thing forward, but that's not so bad. Fun updates will be back before we know it.

[microrignal]

Things are moving! I'm practically done wrapping the Phaser-specific code in a bunch of user-friendly classes and functions. The next step is writing its Cocos-friendly counterpart.

Or actually... not doing that and rather just rewriting the whole project based purely on cocos2d-x. Indeed, after fresh tests with a new version of Cocos2d-x, it turns out that converting the 'hello world' template project to a portable exe actually works like a charm. Since that previously-alleged shortcoming was the only reason left for me to keep a Phaser-based version around, I might drop it entirely. I do appreciate the improved ergonomics of my framework-wrapping code, but probably not to the point where it's worth adding one or two layers of function calls every time something happens.

I did tests to export a Cocos project for Android in the past and it worked very well. So that's not a concern, however I need to fix a weird issue with my old benchmark phone, where it doesn't seem to detect a USB connection anymore. I guess it might have to do with that one time I dropped it in a swamp.

In other news, TexturePacker is pretty great. For a long time, I relied on a web-based application to combine my sprites into an atlas but even the free version of TP seems much better/flexible so far.

The likeliness of a IOS release is increasing! And I've been introduced to the lovely game 'Polytopia', which, besides making a point about expectations nowadays for free mobile games, is kinda making me want to do new vector graphics for Spoïks. But, well, let's calm down.

Oh! I almost forgot to mention that I discovered new coverage of Spoïks out there, on Pocket Gamer.

[microrignal]

I've been giving a shot at doubling the graphics' resolution




Mostly though, I'm still figuring a comfortable (and functionnal) setup to code and export for Android.

Remember what I said about cocos2d-x working very well? Wellll, turns out that story belongs to the past.

Here's a recollection of the process and obstacles I encountered in my quest to make it work again, hoping it might help others. I'm on Windows 7, and I'm seeking to code in javascript and export for Android (for now).

- Installed Android Studio, used its Android SDK to install the SDK for Android API Level 10 (Android 2.3.3, Gingerbread)- which is the lower version supported by Android and also by my phone (a Nexus One with 2.3.4).

- Downloaded/unziped the latest version of...
. cocos2d-x for windows (3.13)
. the java sdk (JDK)
. apache ant
. android NDK
. Python 2.7

- Ran setup.py at the root of the cocos2d-x folder, provided paths to ant, android NDK and android SDK when prompted to.

- In a windows console (run -> cmd), used the 'new' command (e.g. cocos new -l js -d C:\dev Cocostest --portrait) to create a new helloworld template project named 'Cocostest'.

- Still in the console, cd'ed to the root directory of Cocostest and used the 'compile' command to compile the template to an installable .apk file I could test. e.g. cocos compile -p android --ap android-10

In theory, at this point I would have had a functionnal test


HOWEVER, NOPE

- When trying to launch 'setup.py', the command line interface insisted that 'python' was not a reckognized command

SOLUTION : Add the root of the Python directory to the 'Path' environment variable e.g C:\Python27 (In the 'environnement variables' part of windows control panel)...
AND
Make sure to close and reopen the command line interface for the change to be taken into account.

- Providing the root of the ant directory to cocos would not create a new environment variable.

SOLUTION : Use the ant\bin folder instead of the root

- I can't remember if it was when using the 'new' or 'compile' command, but there was a 'command not reckognized' error involving java or javac.

SOLUTION : It's trying to use a previously installed JRE instead of the new JDK. Define a new system variable named JAVA_HOME and make it point to the root of the JDK directory. Then add %JAVA_HOME%\bin to the 'Path' variable.

- Can't test the app on my phone using ADB (Adobe Debug Bridge) to install it, since its USB connection doesn't work anymore.

SOLUTION :
. Manage to copy the apk file to the phone's SD Card (In my case, using a small USB reader)
. Reinstall the SD card in the phone, boot it, and in Android's default navigator's adress bar, write "file:///sdcard/Cocostest-debug.apk" to install it.

ANOTHER 'SOLUTION':
Use an Android Emulator. Create devices using Android Studio's AVD (Android Virtual Device) Manager, and connect to them with adb as you would with an actual plugged in device.
** In order for the adb command to be reckognized, you need to add it to the 'Path' environment variable e.g. C:\Android\Sdk\platform-tools

That said, So far I never managed to have a build that worked on an emulator, while a build eventually did work on my phone. The Android version on both is similar, and the emulator is supposed to imitate a Nexus One.

- Once I managed to build something, well, the installed app didn't work on my phone. All I got was a brief black screen.

SOLUTION : I have no clue as to the cause of this, but after several inconclusive tests trying to fiddle with some pieces of the puzzle such as the NDK, I decided to simply revert to the version of Cocos2d-x that had brought me success back in the days (v3.8.1). This led to a few more problems:

- 'cocos compile' would end prematurely because of error(s) involving the NDK.

SOLUTION : Revert to the version of the NDK that did work back in the days (r10e). Hopefully, that folder was still hanging around. Change the NDK_ROOT environment variable accordingly. Try to compile again.

At this point, I managed to get a functionnal build! I didn't realize it at start, though, because the app didn't work on the emulator as previously stated. Indeed, prior to this realization, the plan was to first test on the emulator until I got a functionnal build, then move to the actual phone.

Happy, I tried to compile again with the same setup and then...

- My computer started to straight up shutdown in the middle of the compile process. No warning, no blue screen. It seemed consistent. Awesome!

SOLUTION :

First, I wanted to know at what point of the process this happened, since things moved pretty fast in the console. I ended up finding how to redirect the output of the a command to a text file.
It goes like this : cocos compile -p android --ap android-10 > C:\dev\cocoslog.txt
To get both 'standard' and 'error' output, use: cocos compile -p android --ap android-10 > C:\dev\cocoslog.tx > cocoslog.txt 2>&1
More info about that here: http://www.robvanderwoude.com/redirection.php

It turned out that the crash actually never happened at the same moment, which made me suspect it might be an hardware problem e.g. the computer overheating.

Turns out, I was right! I used Speedfan to monitor temperatures during the compile process. Basically it went from 40 to 86 Celcius before shutting down.

I don't know the cause for sure, but I don't think this is a normal situation at all. It's especially bizarre that it's the only circumstance that I know in which said computer would overheat.

Fortunately, I have another one around. I moved to set it up the same way. I copied the whole cocos2d-x 3.8.1 folder, as well as that of the NDK r10e, to that machine. And I tried again. But then...

- At the start of the compile process, got a 'file not found' error when trying to run 'C:\ndk\ndk-build'

SOLUTION: I figured there migh be a problem with the NDK, since I copied it from a 64-bit environment to a 32-bit one. So I downloaded that version of the NDK, which came as an exe rather than a zip (http://dl.google.com/android/ndk/android-ndk-r10e-windows-x86.exe - see the trick here: http://stackoverflow.com/questions/6849981/where-do-i-find-old-versions-of-android-ndk), ran that exe to extract it, replaced the old one with it, and launched the compile process again.

Let's test the result!

"Sorry, the application has closed unexpectedly".

Android Debugger says:

694 Android Runtime
java.lang.UnsatisfiedLinkError : Couldn't load cocos2djs: findLibrary returned null
at org.cocos2dx.lib.Cocos2dxActivity.onLoadNativeLibraries(Cocos2dxActivity.java:288)
at org.cocos2dx.lib.Cocos2dxActivity.onCreate(Cocos2dxActivity.java:303)

To be continued!

[microrignal]

Hey, look at that :D



Apparently, compiling from a new project created *after* switching the NDK solved the problem.

It works on my Nexus One running Android 2.3.4, and Bluestacks.
It still doesn't work, however, on neither of the two virtual devices I've created so far, which run Android 2.3.3 and Android 4. I get the infamous "sorry, the application closed" message.

EDIT: It also works on a Nexus 9 Tablet running Android 6.0.1
EDIT: Also successfully tested on Kyocera Rise runnning android 4.0.1 and a Samsung 'GT-S5830D' running Android 2.3.4. So far so good on every 'actual' device.

[microrignal]

This week, I sat down with a friend to sort Spoïks things out. I asked her to check with me regularly how progress is going.


SCHEDULE AND MILESTONES

By October 1st:

• Finished design doc
• Technical test version, with the following working on web, windows, android and hopefully iOS
  - input
  - sprite atlas and animation
  - audio
  - multiple scenes
  - save local data
  - leaderboards

By November 1st:

• New layout
• A minimal playable version with only the crucial elements, working on all target platforms

By December 1st:

• Fully playable version (normal mode only)

By January 1st:

• Polished and final version (normal mode only) - including final assets
• Begin of shameless self-promotion

By February 1st:

• Extra modes
• Unlockables

March 1st
Launch


And so, onwards to October 1st Milestone

Design doc:
Has since made great progress, as we figured which features from a massive list would make it.

Technical test version:
Saving local data works on web, windows*

On Android (Nexus One, 2.3.4) I get an error:
dalvikvm
dvmFindClassByName rejecting 'org/cocos2dx/lib/Cocos2dxLocalStorage'

Might be that the permission to READ_EXTERNAL_STORAGE isn't set in AndroidManifest.xml. Testing that.

*Apparently version 0.4.3b of Web2Exe is required? 0.5.1b's output doesn't run.

[microrignal]

Blarhg!

That didn't work. I'm stuck with that problem for now and have sought help on the cocos2d-x formus.

For future reference, here's the relevant log bit :

Code:

998 cocos2d-x debuginfo [D] cocos2d: fullPathForFilename: No file found at script/jsb_prepare.jsc. Possible missing file.
998 dalvikm [W] dvmFindClassByName rejecting 'org/cocos2dx/lib/Cocos2dxLocalStorage'
998 cocos2d-x debuginfo [D] cocos2d: fullPathForFilename: No file found at script/jsb_boot.jsc. Possible missing file.
998 cocos2d android build version: 10

Meanwhile, though, I've fixed that overheating problem (with a good cleanup and some thermal paste). It means I can now compile the project in mere seconds with that better computer.

However, the lack of a working USB connection with my phone is still plaguing my workflow. I looked into ways to establish an ADB connection through wi-fi rather than USB, but all methods require either that my phone be rooted, or an initial USB connection. I thus looked into ways to look that Nexus One without a PC, but what I found was either not working for that particular version of Android, or involved granting permission to an app to do anything with the phone.

And thus, I'm now looking into getting a new, similar, used phone.

Also, it became clear to me that I can't realistically tackle an iOS version right now. Assume that the schedule and milestones I posted earlier are for web, android and windows.

[microrignal]

I've got some bad news, and some fabulous news.

Bad!

Still no progress on that local storage issue: I haven't heard back from anyone on the Cocos2d-x forums. I'm slowly realizing that the Javascript implementation of that framework is far from being discussed and supported as much as its C++ counterpart.

Fabular!



I got a new phone which is slightly more powerful than the last, a Samsung Galaxy Ace IIe running Android 4.1.2. Since that's greater or equal than 4.0, I was able to give Cocoon.io a new chance**.

**_{Cocoon.io is a commercial cloud service that "wraps" uploaded html apps into a native "shell", essentially turning it into a native app. In previous episodes, I had started working to bring the game to mobile with Cocoon.io - "CocoonJS" at the time - faced a big roadblock, then rejected that option when they re-made it as Cocoon.io which required Android 4.0 or higher, which means it couldn't produce playable games for my previous phone.}

Although the game would still need optimization, first tests show great promise. The game is fully playable (as much as the web version), lags just a bit on that Android phone - especially at startup as it did back in CocoonJS days - and runs perfectly smoothly on my Iphone 5. The only major problem I encountered so far with Cocoon.io is that I can't install their developer application on my Samsung Galaxy - it's a know issue related to application signing for which there's a workaround - but I was able to compile a custom developer application and its debug version works fine. There's also what seems like an undocumented need for a config.xml file upon creating a new project.

My guess is the main cause of the lag is sprites changing frame, which would make sense if that operation involves pre-drawing the sprite on a buffer to enable tinting effects. As I did with Flixel in the past, I might tweak the inner workings of Phaser to make it render sprites to the main buffer directly - giving up on tinting effects which I don't use anyway. I might also be completely wrong... I feel like I probably have explored that avenue already.

Another good thing to report about Cocoon.io: the resulting installation packages for Android ask for no intrusive permission, only internet access. That's actually quite a relief.


So... what now?

Cocos2d-x is full of promise if I can make it work completely - especially in the sense that performance would be better without me walking on eggshells so much - but I keep encoutering roadblocks at every corner and help isn't too easy to get. Cocoon.io's community hasn't been *fantastic* either so far, but its services would allow me to truly have only one version of the code to maintain and potentially speed up the process of bringing Spoïks to 1.0 considerably. It actually seems like a good fit for the scale of that game, in comparison to the much heavier cocos2d-x which exports spoiks as a 50mb app.

There's drawbacks to going with Cocoon.io, of course: Spoïks would only be compatible with Android 4.0 or higher (well, that's still around 95% of the devices nowadays) and their splash screen would have to stay at game startup unless I pay $500. That's alright.

Next step is testing the following features with Cocoon.io :
- leaderboards
- local storage (ha ha)
- in-game purchases (see if it works as advertised)

[microrignal]

This week, I...
- Succesfully tested local storage with Phaser/Cocoon
- Did a good chunk of work on the design doc
- Registered as an Android developer for $25
- Implemented a test leaderboard through Google Play Games Services. It works! Useful documentation was this and this.

What remains for October 1st Milestone (technical tests and design doc) to be met :
- Make the test leaderboard work for the web version
- Finish the design doc
- Test in-app purchases

That should be done by the end of the week. And then, onwards to reworking the graphics and layout!

[microrignal]

Hey everyone,

Not much has been accomplished since last update. I had to go take a little spontaneous break close to nature, and face pretty harsh news.

I'm back, though. Spoïks' protagonist, Victor, has got a message for me.



Thanks to all who still follow Spoïks' development despite its many twists and delays

[Pixel Noise]

Hey, haven't seen this pop up for a while - loved it when it was SPOINGS (I think?), and it looks even better now! The theme music you posted sounds great, and fits really well. Keep it up 

[jctwood]

Woah this looks super interesting!

[microrignal]

Hey, haven't seen this pop up for a while - loved it when it was SPOINGS (I think?), and it looks even better now! The theme music you posted sounds great, and fits really well. Keep it up  

Hey thanks so much! That means quite something, coming from a skilled music composer team! I'm not actually certain that this particular tune's such a good fit for the pace of the game, might be too busy/upbeat. I'm pretty satisfied with its sonority, though. You can hear the cubes. Tweaking that will be the fun part (one of many, ha!).

Woah this looks super interesting!

I'm glad you like it! Your comment comes at a time when steady progress is about to be made, so stay tuned  

Today I fought with google's patchy documentation, attempting to make google play games leaderboard work in the web version. In the end it does work, except there's a couple annoyances. Namely, it seems impossible to make a google play games profile public unless you do it on mobile. I also still can't figure how you're supposed to share your best score with your google+ friends unless, again, you have access to an android device. Aaaaand unlike on mobile, there's no pre-made UI to display leaderboards, which means I'm going to have to make my own. All in all, pretty disappointing. I can't rely on that service solely for web, but it would be okay as one of many options. Wasn't too fond of 'forcing' people to create a google account anyway.

Technical notes :
In order to make it work, I had to mix two different methods for signing in to google play games services.

• Start with this; "async defer" isn't necessary.
• As mentionned here, change the value of "google-signin-scope" to "https://www.googleapis.com/auth/games". Do not mind the other "page-level configuration options". "google-signin-callback" doesn't seem to work at all.
• As mentionned there also, step 3, add a line to the html document to load "apis.google.com/js/client.js" in addition to "apis.google.com/js/platform.js".
  
• Skip to step 6 of that method("Make calls to the RESTful service"). Insert that bit of code in the "onSignIn" handler function and you're good to go!
• The google accounts used to sign in need to have google+ activated.

[microrignal]

Woah

Do you know what does exist? A decent - actually super convenient - cross-platform leaderboard service. App42, they call it. It's free until you reach 1 000 000 API calls / month.

I tested it just enough to make sure I could submit/retrieve scores, which went smoothly, minor hiccups aside*. For now, I'm just generating a new random user every time the game is launched. I'll need to implement a register / login screen eventually.

Another thing off the checklist!

*Technical notes :

• Version 3.1 didn't work. There's an error at initialization (t is not defined). This problem occurs with sample code as well. Had to use 3.0 instead.
• App42 doesn't accept a score of 0 when submitting a score (considers the parameter 'blank' and incorrect).