Thursday, 25 August 2016

100th day of development



I had big plans for this milestone and, sadly, I am behind the schedule. Had to finish another assignment for uni, and also my exam is only two weeks away. I planned to complete all interface work and some of the device testing to have a working prototype. In reality, I have a prototype — but “working” part is debatable.

Two weeks ago I started device testing. I set up my test environment with iPad 2 and iPad mini (there’s a long story behind a search for a power cord for an old iPad, but that’s for some other time), built a new version, deployed it to the device through XCode, and got mentally ready to look like that:



And yes, I did. Because when application loaded, I got a black screen of death with the main menu on it. The main menu was missing a couple of images, but “start running” button was there. When I pressed it, I saw my parallax — and nothing else. There are three things you can watch forever — and sadly, my parallax is not one of them.
So, what may be the reason for such unusual behavior?

After some swearing and kicking things, it became apparent that the reason is a changed default setting value. To make parallax work as a texture-filled rectangle, I had to set default display to “textureWrapX” and “repeat”. As a result, my coordinates were all over the place, and static images just moved beyond the screen.

I had to rewrite all my background structure and re-animate (reanimate, too) it. Now I just repeat all the background images with a simple “for” loop, and it gets the job done — though not very elegantly.



After some additional manipulations, needed because of my love for magic numbers, I have a version of my game on my iPad.

The next stop was the interface — all those collectable things and blowable things and other things.

Again, my lack of knowledge about software architecture design fired back — I had to work around my package system, instead of it working for me. At this point, I am not ready to redo the architecture, so I am going to let it be. Anyhow — coins and lives are now being collected, stored and displayed.

I wanted to make a good introductory video where I talk about my project, explain how it works in case someone will be interested in helping me with the graphics, but with the exam and a new work project (designing interfaces, of all things!) I couldn’t finish it on time. So I am going to postpone it until day 150th.

The next step is load-reload. After that, I’ll have a playable version of the game that you can install and enjoy. My plan was to finish this part this month, but it looks like I have to move it to September. Next course at uni starts on the same day that the exam for the previous one takes place, but the first two weeks usually are not that intense, so I should have time to work on my game.

Monday, 11 July 2016

63 day of development and mushrooms

For two weeks I didn’t do anything for my game because of Uni! Assignment! Deadlines! Work! And life in general. But this week I returned to development, and as always after a break — decided to change stuff.
Test imagery

One of the main changes concerns dialogues. The more I tested my game, the clearer it became that simple static dialogue, even if there’s some animation in the background, doesn’t work for me. Overall my EndlessRun is, of course, about running. Unending movement forward, like an engine, pushing and pushing towards the end of the story. Static dialogues just stop that. So what are my options?

  1.  Voiceover. It would be nice to voiceover the game, so the player doesn’t need to move her eyes from the moving character, but I don’t think that’s possible for me. My accent makes people think about Russian mafia, and though it might be usable in some game voiceovers, it doesn’t work here. And I don’t have money to hire actors.
  2.  Text on the screen. Logically the only way for me to convey some additional information about the story and the world is through reading. And read and at the same time control a running character is not an easy task. Because of that, I can’t just have a character running while the player reads through the dialogues.

I sketched some ideas about how to this problem and next week I’ll try to work on that.
The second thing I worked on last week is the level parsing — loading and displaying level map. I am not even half way there — even though it works for now, in a simulated environment, I didn’t test how heavy this process is, and that’s the task for another time.

Still test imagery, but this blue guy is super cute!

At this point, the flow is like this.
Gameplay loads related act data. From that data, we find related level maps (CSV) and images. Then we load and parse all the files.
Full data loading flow is like this:

1. Load images for platforms and static enemies.
2. Load physics for platforms (long thin objects).
3. Load objects that kill a character on collision — like static enemies and sides of platforms.
4. Load collectable objects and point of interests that trigger dialogues.

Platforms and dangerous objects

Now my character can run into mushrooms and it makes her sad so she falls and cries. Also the elemental power of the mushroom is randomised, so sometimes it has air effect or fire effect and so on.

The next step is to familiarise myself with magical corona’s “isBullet” feature and try to implement obstacles destruction.
And a video proof:

Monday, 20 June 2016

42 days of development and a new idea


One and a half month into development I hit a roadblock. It wasn’t any of my usual “WTF why it doesn’t work” things, it was a creative obstacle. In my last entry, I wrote that there are no generated levels in my game, all the levels will load from the pre-generated file and on the same level player will always get the same obstacles. But that lowers the excitement of re-playing levels, and on top of that — I am not sure of my ability to create a level that is exciting enough for a player to be interested in re-playing it.

Of course, I started to search for answers in the places where I usually find them — in books. At this point, I am reading several books — A Theory of Fun for Game Design by Raph Koster, Surviving The App Store by Amir Rajan, and also re-reading The Art of Game Design: A Book of Lenses by Jesse Schell. I always read several books at the same time. It compensates my inability to focus on something for long, so any moment I start feeling my attention is drifting away (on the days when your dog wants to have a walk at 6 a.m. that happens like every ten mins), I switch to something else.

Also, I checked some interesting articles, for instance:  Endless Runner Games: How to think and design (plus some history) by Ben Chong, Gameplay Design Fundamentals: Gameplay Progression by Mike Lopez and Designing Games That Don’t Suck by Jason Bay.

But after reading several chapters, articles and posts I wasn’t any closer to the answer. It looks like you can’t become a level designer after a short read (who knew?). So I decided to take for granted that my levels on their own won’t be interesting enough, and I should look for other ways to make my game more interesting. I returned to some of my old ideas. For instance: casting spells, similar to “Infinity blade”. But that would slow the game down, and it would lose the momentum. Or like having enemies that are vulnerable to a particular type of weapon. But how does one show that this enemy can be killed only by fire? And how the player will remember that water enemies are killed only by fire, but wood enemies by stone?

I was lucky. Every year here in Sydney we have a Vivid festival and this year there was an interactive installation wormhole-galaxy and it was awesome!  To put it simply — it is a game for four players, each one has a coloured button. There is a character that runs through the pipe with coloured obstacles and by pushing the button of the same colour player destroys the obstacle.

That’s when it struck me. I can use my idea with elements, distinguish obstacles with colours and instead of generating levels, just have a pre-programmed level with randomised colour elements for obstacles. This way on one level player has to have a water weapon to destroy the blue barrier, but if he replays the level this obstacle can become green for wood or white for air.


At this point, I finished the menu that allows to choose the elements for the level and hopefully I’ll start to work on randomisation in the next couple of days.


I also worked a bit on my package plan, just to remember which package requires what and how the relationships look. Quite a mess! And that’s only my 42nd day of development 8))

Saturday, 21 May 2016

When it kinda works

Finished my test animation and made a video with test controls. She runs, she jumps and she stops!

Looks like it all works but… it actually doesn’t.

Run into trouble with transition.pause(). It took me pointless hours of changing code — and after creating a new simple project to test it, I can say — it is the problem with Corona’s built-in function, and not with my code.

As you can see on the video, character can run and stop, and jump and stop. But if you use controls to jump, run and then stop — transition.pause() won’t work.

The example from my simple project:
We have a background transitioning to the left.
A static object (or sprite).
Set of controls triggering events Listeners that catch events, pause or resume background transition, and call a function that changes the position of the static object.

Problem: transition.pause() doesn’t work if you resumed it more than once before. Though if you do catch event with transition.pause() 2 times — it will pause, as if it stops resume 1 and than stops resume 2.

Google doesn’t know what to do with this. I don’t know either.

Luckily for me, in my game user won’t ever get a chance to use “stop” control — all scenes where character stops are script-driven. But still, it would be nice to know how the hell I can fix that 8(((

Friday, 20 May 2016

Menu and opening

Most of the week I was fighting with project architecture. Though problem was not the architecture per se, but myself mostly. My ideal project architecture looks like that: everything is global, and everything is available to everyone at any given time. You call it anarchy, I call it freedom, blah blah.

With this mindset I always end up with main.lua about 20k lines.

So this time I decided to do it the right way (kind of), and use packages. It worked out fine — until I got a dialogue package, and an act package, where the act triggers the related dialogues, and the dialogues had to trigger each other, and the animations that are in the act package that just triggered this dialogue. The word “mess” doesn’t even start to describe it.

4 days and many swear words later, I sorted it out. At least now I have a file called gameplay.lua, because… why not?

The proof of concept:

Actually, I also finished spritesheets and animations for a test character. But before I can show it to anyone, I need to work a bit on the controls, and I am too drunk to do that today (It’s Friday, yeeeeiii!)

Monday, 9 May 2016

Endless run and endless troubles 8)

I decided to take a small break from interactive stories (still working on Russian translation, and Android version of Koschei though) and get acquainted with Corona physics.
So from now on, at least until I released update for Koschei, I am going to work on my endless run game.

First, I thought about developing a platformer, but endless run is a bit easier to make.
Now I enjoy the "research" stage. I installed Temple Run, Subway surf, Jetpack, Joan Mad Run, Nyan Cat, Nosferatu and Rush City 8))

But I don't just play games, I actually started working on my own endless run and immediately ran into trouble (irony!).

I still use Corona, but this time I started with a setup for several devices. There's a very good tutorial about it and it actually works perfectly. Until I decided to load my stage.

At this point, I don't want to spend too much time optimising stuff - so I simply load an image and fill a rectangle with it, repeating it as many times as I need (actually there are 3 textures and 3 rectangles to create a parallax effect, but who cares 8))
And... Corona magically resizes it, but instead of fitting the screen based on base resolution, as it says in tutorial, it re-aligns it to the middle of the screen, making a margin at the top for iOS status bar.

The only fix I have found so far is:
Instead of using an example of actual device resolution by default (for instance 1024x768), I use an average resolution for all available devices (1136x710) and Corona adjusts it a bit, leaving out parts off the screen. Then I create background images with this resolution, keeping in mind that some parts of it will be omitted on different devices.

So, here it is, my first parallax (all textures are just for testing, they will be redrawn later)



Monday, 18 April 2016

Working 8)

When a picture is worth more that a 1000 words.


This is a plan for the first act of my new interactive story (there are 13 acts like this one in it). It may look confusing, but when you think that it is only the first out of 13, and at this point only the connections inside that one act are shown... It will get much worse 8))

 By the way, ClickCharts in its free version is functional enough to create diagrams like this one. So it is good not just for UML stuff.