next »

[saluk]

The crafting menu is pretty cool! I recently added crafting to my rpg and the first thing you can craft is poison and poisoned food so it resonated with me that's what you showed!

That map is quite lousy with trees - but the spacing feels very natural. Nice job.

About the crafting, were you asking whether the interface should reveal when a match can or cannot be made? I like how the recent monster hunter games handle it. They don't tell you what you will get, but only allow you to combine items that will have a result. When you choose the first item, it limits the selections only to items that will actually combine and result in something. It's only 1+1 rather than a flexible system like you have though so I'm not sure how well that would work. I think your system is probably fine.

[pmarincak]

That map is quite lousy with trees - but the spacing feels very natural. Nice job.

Thanks. But I'm not sure what you mean by lousy?

About the crafting, were you asking whether the interface should reveal when a match can or cannot be made? I like how the recent monster hunter games handle it. They don't tell you what you will get, but only allow you to combine items that will have a result. When you choose the first item, it limits the selections only to items that will actually combine and result in something. It's only 1+1 rather than a flexible system like you have though so I'm not sure how well that would work. I think your system is probably fine.

Yeah it was whether to show the item for experimentation, or to just say "you might get something". Maybe I'll switch the message to show a "you will fail" and disable the button, and then if it'll be successful to have a "? something will be made" and if they've made it before, to just have the item appear.

[pmarincak]

Devlog #11 - 28/11/15

I'm literally never free from illness it seems. The past few weeks I've generally just been a mess of sick trying to work through some stuff. Doc's have just told me it's a virus and I'll "get over it" eventually. Eventually being the key word here.

In any case, I've spent the time working on skits and story and rewriting stuff. Can't really show that just yet.

Since my health improved a bit this past week, I went back to working on maps. Some people from #indiedevhour were interested in a timelapse video of me working on one of the maps from beginning to end. So here it is:

(Just make sure to click on the image)

[saluk]

Viruses suck! So do bacteria. The bad ones anyway.

Thanks for posting your photoshop process. It is very involved. How long realtime was that? Also, at what point did you decide to make the maps in photoshop rather than using Tiled directly? Obviously you can do a lot more with shading and details that way, but it seems to add a lot of extra effort. Was that part of the plan from the start, or something you hit on as you fleshed it out?

[pmarincak]

Thanks for posting your photoshop process. It is very involved. How long realtime was that?

You're welcome It took two hours and just above 9 mins. (02:09:04)

Also, at what point did you decide to make the maps in photoshop rather than using Tiled directly? Obviously you can do a lot more with shading and details that way, but it seems to add a lot of extra effort. Was that part of the plan from the start, or something you hit on as you fleshed it out?

It's hard to say exactly when, since I've been working on this game for ages, but it was definitely earlier on in development. There's a couple reasons why I decided to do it in PS actually:

1. The Victorian Era tends to focus on details a lot with their design and architecture, so as you mentioned, it would be harder as straight tiles.
2. I found this parallax method (that's what it's called according to the RPGMaker community) while researching tilesets. (I was originally going to use a premade set but ended up paying someone to make it for me, which was worth it.) I liked the result from it more than using tiles.
3. When I was first writing the collision handling, I was using tiles in Tiled to manage it based off of tutorials, but I found a lot of FPS issues with it. I made it so that polyline objects would be read in as collision borders, so with it being more-or-less tile free, I didn't need large tile sizes (it would've been 64x64).
4. A lot of the maps for the game are made up of fields, cliffs and forests so having everything stuck to a grid wouldn't have a very organic feeling.

So all of that combined led to me going with using Photoshop to make the maps.

I actually do use Tiled to read the maps in as layers, for collisions, and put images the player can walk behind (like those trees), but most of it's merged into a couple images. (I cut up that PSD file to put it into the game.)

This actually ended up being the best option for me because my maps are so huge. (That one in the video is 3200x3200.) When I was using Tiled in Cocos2dx to load the images, it would have the image cut up into 64x64 bits and stored in memory. When it came to animating water, for instance, it caused the FPS to tank. Unfortunately Cocos2dx can't handle large Tiled maps very well, so I ended up writing a custom TiledMap class that didn't bother with cutting up the texture (and some other stuff).

As for extra effort to make the maps, I think it's worth it in the end. People seem to like it a lot, and I think if I did a Tiled layout I would have even more comments on how the game is "obviously made with RPGMaker".

[pmarincak]

Devlog #12 - 05/12/15

Was adding in new content the past few days and found the algorithms I wrote for the debate system before were far too harsh to be practical, so I spent a couple days remaking them and making sure the debates I had planned out before and implemented were still passable.

The main problem was that the player would need to increase their Charisma stat to be about 3-10 points higher than whatever the enemy's Charisma stat was to be able to pass the debates. Unfortunately, this would be for every 1 increase in the enemy's Charisma. Given that a player can only increase 1-3 stats each time they level up, and there's 5 stats, it would mean a lot of grinding.

I'm not sure how I missed this before, but I did.

In any case, there's new calculations in the game, and while I was at it I adjusted the calculations for Easy/Normal/Hard gameplay modes.

In other news, I was updating the skit images and had some fun

[pmarincak]

Devlog #13 - 08/12/15

Took a break from adding events today to work on maps. Got quite a lot of work done, so I'm glad. I worked on a dungeon today. It's just a one-off for a side-quest, so it didn't need to be too complicated. Some shots from it + a small gif.

[pmarincak]

Devlog #14 - 13/12/15

I can officially say I'm finally over my onslaught of colds. Hopefully they don't come back for a long time =A=

I finished adding all the new story content to the game this past week. I hope to get into pre-beta release testing before or by the weekend; I still have some balancing and NPCs to deal with. But it looks like I'll be able to start the next beta Round by Christmas. If I can get that done, I might take a few days off....

In other news, Toggl has been really great the past month and a half I've been using it. Obviously, it's been a great help in seeing if I'm ACTUALLY hitting a proper 40 hour work week, but since I've been properly dividing up the tasks I'm working on when I start the timer, I'm starting to use it to estimate how much more work I have left and for the beta release schedules (since I want these to happen more often). It's also nice to see that some tasks don't take nearly as long as it feels it does, so it's more motivating to do them.

I would definitely recommend this to people who're self-employed, people who do hourly work, or people who just don't know how long some stuff takes and can't plan it out properly just yet. For instance, I can pretty accurately guess how long some web dev tasks will take just because I've been doing it for so long, but things like creating maps, adding them to the game and so forth I have been severely underestimating.

So- uh- TL;DR use a time tracker like Toggl. It's great.

PS. I'm starting to work on Steam Greenlight stuff, but my first hurdle is dealing with steam customer support to change my store from US to Canada. Let's hope that doesn't take so long that I need to go purchase it using the nearest McDonald's WIFI. This is why geolocating based on IP is NOT a good idea.

[pmarincak]

Devlog #15 - 26/12/15

Small update in the middle of testing hell and holidays.

As expected, testing hell is testing hell, especially since I have a new platform - PC - to deal with. You wouldn't think there would be so many issues with it considering the WinTab port works fine, but there is.

One bug I came across and gave me a headache for the past few days (when I could find the time with family and all) was a memory heap error. It's worth noting this only occurred on PC. Some of you might find this solution helpful.

Basically, when I went to switch maps, very often - like 95% of the time - it crashed and there was a memory heap error: HEAP[App.exe]: HEAP: Free Heap block BLOCK# modified at BLOCK# after it was freed

I thought that maybe a specific line of code was causing the problem. Except, when I went into debugging, the crashes always happened in the engine (Cocos2dx) and NOT in the same place every time.

After poking around on the net, and doing some reading, it 100% had to do with the malloc and free commands being called. I installed a program called Application Verifier from Microsoft to see if it could tell me where these errors were, since it was highly rated to help.

At first I didn't think it was doing it's job properly, since it was stopping the program at a line of code that wasn't being called (I think it's a bug on it's part?), but the line underneath that call in the stack - that started to consistently show up each time the program stopped. It wasn't the same line every time, but what it was doing was the same: in the destructor, it was making a call to release a sprite pointer if it hadn't been already.*

Now the checker for it, was that the object wasn't null (>0) and it had references. Then I remembered a previous bug I had with it: Windows doesn't set pointers to 0 as null, it's some other value (0xFFFEEE maybe?). So code that works fine on all the tablets, doesn't work on PC because of that one thing.

This was a simple enough fix, go to the code that releases the pointer and sets it to nullptr, and change it to set it to 0 instead. Done. Fixed.

It likely would've been best to set the checks for checking for nullptr, but given the sheer number of checks in the game that are looking for 0 (it's being developed on Playbook/iPad (more iPad these days) and ported), it's more efficient to change 4 words.

TLDR; Windows doesn't set null pointers as 0. It's likely other systems might do that as well (even though 0 is most common). If you get weird heap errors, you're either freeing a block that's been freed or allocating a block that's been allocated. Watch out.

And Merry (late) Christmas and Happy New Year!

* It's worth noting that I split the parent of the sprite to be a batch node from the data object itself. So if the map is released, the batch node, sprite and object are released. But if the object is released, the sprite needs to be released and removed from the batch node. This is where that check comes into play.

[pmarincak]

Devlog #16 - 28/12/15

Short update. Remember those collision bugs I talked about in October-November? I was getting tunneling with both Box2D and Chipmunk. Well, I fixed it.

I noticed when I added keyboard support that there was no tunneling at all for the PC version and I thought to myself: well what's the difference (besides being PC)?  The difference is that the keyboard, being binary (pressed or not) meant that there was no acceleration for the user. If it was pressed I moved the user in that direction.

For tablets, there was a "joystick" and the velocity would change based on how far "pressed" it was (being a screen and all). This was originally because it was going to switch to a running animation at a certain velocity. I changed it to ignore the velocity and only pay attention to the direction and tada, no more tunneling.

I've since removed the "shifting the physics body back upon contact" thing that I did before and everything looks to be running smoothly.

[pmarincak]

Devlog #17 - 06/01/16

First update of the new year !

Yesterday the new beta round was released now supporting PC! Essentially, everything I've been working on since May has been included... which resulted in a long release notes list....

But it's out! So I'm glad... I can finally take a sort of break for a week. Go outside. See people. Have a life. Focus my attention on a 2015 feedback survey and greenlight and plan out the next releases so it doesn't take as long.

Happy New Year!

[pmarincak]

Devlog #18 - 07/01/16

As per usual, I've released our yearly feedback survey today. It helps in making sure the development of Gataela is transparent and I post things of interest to everyone. It would help a lot if anyone here would also fill it out or share it with others.

[pmarincak]

Devlog #19 - 12/01/16

I got a pretty interesting comment from a beta tester so I was wondering if anyone else here will have the same reaction/observation: In the following screen cap there's NPCs with ... bubbles above their heads. What do you expect them to do?

My beta testers have now reported that they expect them all to have dialogue. What actually happens is that they tell the user "the NPC is busy". The ... is supposed to mean "silence" or "thinking". Apparently, people will continue to talk to the NPCs with the ... bubbles even if every response is the same.

Some have suggested that I change the bubble to be a thought shape. Others suggested adding in the UI tutorial that ... bubbles means "don't bother". Another one suggested to switch ... bubble NPCs with the others (i.e. all the NPCs that have dialogue (99%) have a bubble and the ones that don't (1%) don't have them).

Personally, I think changing the animation from a ... to something else would work best (an x perhaps?), but I'm wondering if anyone else has any suggestions.

[pmarincak]

Devlog #20 - 24/01/16

I'm getting back into developing things instead of bug fixes and testing so I need to remember to post here more often. The following's just a bunch of stuff I've done the past week in preparation for a patch release.

There were some graphical issues from the new map method that, although it didn't cause the game to crash, it didn't look right. A lot of this was fixed by messing around with values between opengl's vertexz buffer and Cocos2dx's parent-child node relationships. I also took the time to transfer over the other huge maps in the game to the new map method while I was at it so that loading times would be reduced. In any case, here's a quick before and after:

Another problem I found was that for some reason on PC saving took a LONG time. On the mobile platforms it was usually 1-2 seconds but on PC it was about 30+ seconds. It's worth noting I'm using SQLite for the save files and they're about 30KB large, so that save time was ridiculous. After poking around, it had to do with the fact that each insert and update was its own transaction. So I put most insert and updates into their own transactions and got the following results when testing a random file I loaded (i.e. saving without any changes):

Before:	After:
10.000000 player save time 10.000000 item save time 0.000000 event save time 1.000000 skit save time 2.000000 statement save time 0.000000 enemy save time 2.000000 system save time 25.000000 total save time	0.000000 player save time 0.000000 item save time 0.000000 event save time 0.000000 skit save time 0.000000 statement save time 0.000000 enemy save time 0.000000 system save time 0.000000 total save time

Of course, it's not exactly 0, but it rounds between 0 and 1 seconds at output despite being a float. In any case, it's practically instant now. Some other things I found out:

• It's a bad idea to put create statements into transactions with insert and update statements; nothing actually gets inserted apparently with the sqlite c implementation (although if you use DBVisualizer and use the same sql statements it works fine?)
• For some reason in the sqlite c implementation, if you include the begin and commit INCLUDED with the rest of the sql (i.e. not executing them on their own with nothing else) it won't actually commit and keep the table locked
• Once again, in the sqlite c implementation, if you try to use a prepared statement instead of just executing the sql, only the first item in the transaction will go through and the rest will be ignored

So all of that has been changed and mobile file saving actually somehow got faster? It's consistently at 0 seconds save time now.

TL;DR

Map Graphic Layering: Fixed
Average Huge Map Loading Time (PC): 1 second (300% improvement)
Average File Save Time (PC): 1 second (3000% improvement)
Average New Game Start Time (PC): 2 seconds (950% improvement)

[pmarincak]

Devlog #21 - 26/01/16

Lots of bug fixes. Also slopes.

[and]

Bug fixing is the worst. On the bright side, this is looking great!

Looking forward to seeing how it develops

[saluk]

Thanks for using SurveyMonkey (I work there!)

I think that the bubble situation is because of years of training on things like WoW - something over the head means something important is going on there. I can't think of many games that use the opposite signaling, where something over the head means you should NOT pay attention to it.

Nice fix on saving. It's interesting that you are using sqlite for saving. Do you use the database during the game as well to search for things?

[pmarincak]

Devlog #22 - 4/02/16

I'm back to creating maps and cutting up maps to put into the game. Nothing too interesting. Here's a couple in progress shots of buildings:

----

Bug fixing is the worst. On the bright side, this is looking great!
Looking forward to seeing how it develops

Thanks

Thanks for using SurveyMonkey (I work there!)

You're welcome

I think that the bubble situation is because of years of training on things like WoW - something over the head means something important is going on there. I can't think of many games that use the opposite signaling, where something over the head means you should NOT pay attention to it.

Yes, it appears I was mistaken on this part. I'm just glad a beta tester brought it up to me now instead of later. I ended up contacting as many of them as I could to ask and they all had the same issue, but they just didn't bother to tell me. Reasons ranged from they thought I knew, to they figured it out, to they didn't care. Surprisingly, during the cutscenes they all pretty much understood it meant "thinking" or "silence" but outside of the cutscenes it was the opposite.

I brainstormed a lot of different ways to fix it, and I got some suggestions, but I've ultimately decided to remove those bubbles from the overworld and give all those NPCs proper dialogue.

Nice fix on saving. It's interesting that you are using sqlite for saving. Do you use the database during the game as well to search for things?

Databases in general seemed like the obvious choice for me given the number of things I needed to save and my familiarity with them. SQLite is also extremely lightweight and it's available on all the mobile devices too. I'm not too sure what other people would use usually though? Properties files?

During runtime I actually do, do searches in it though. Usually while playing things like the events you've interacted with, and skits and such are all saved in memory. Every time you save it gets written to the database and then removed.

These skits and (story) events all have precursors to check (i.e. has this event been completed?). They check the memory and the database fairly often. Some events check more often than others though. For instance, "player touch" events (like moving maps) don't even check until the player has touched it, but "parallel" events check each step (as long as they haven't been completed) if they need to be triggered. So I run a fair number of queries per step depending on where the player is at in the game.   

[pmarincak]

Devlog #23 - 12/02/16

I finished off the maps I was working on the other week and have moved into adding more maps to the game. I'm lucky that one of my friends has agreed to help me out with it since a certain part of it is not technically difficult at all, but eats a couple hours of my time for each map that I should really be spending on other portions of the game. Like adding features. And fixing the UI. There's a long list.

This is just a quick stitch together of the city I was working on the other week. It was in the middle of 4 maps.

And this is just a quick shot of adding the collision data to the maps (white lines) and objects that you can walk behind and in front of.

[pmarincak]

Devlog #24 - 15/02/16

Still adding maps to the game. I had a stream earlier today and someone asked why I wasn't putting the shadows in with the TMXMap with all the other collision data. At the time I answered because stamping the shadows doesn't work like it does for the trees and bushes and such (because it's not one solid "sprite" so it looks very bad when the character is moving in front of or behind them), but after I started to think about it more. I figured if I used the object layers I could get the x, y and height of the shadow I would need, and then some extra custom properties to tell it what type of shadow.

So, bam, that's done now. It only took an hour to figure out the parsing and making sure the maps are still backwards compatible (so I don't throw away my old work) plus with making sure there are no graphic bugs. What used to take 2 hours takes 10 minutes now.

Though I should've done this earlier >A>;;;