Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411279 Posts in 69323 Topics- by 58380 Members - Latest Member: bob1029

March 28, 2024, 04:14:08 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsGataela - Victorian Steampunk RPG (Graphical Demo Update Out!)
Pages: [1] 2 3 ... 6
Print
Author Topic: Gataela - Victorian Steampunk RPG (Graphical Demo Update Out!)  (Read 17765 times)
pmarincak
Level 1
*



View Profile WWW
« on: October 01, 2015, 01:14:40 PM »




                                                                                       

A Victorian Steampunk RPG where saving the Kingdom requires more than just brains and brawn: you also need to talk to people! Featuring a debate battle system, talk, debate, convince and negotiate with NPCs in order to save the country!

Try out the Demo

                                                                                       






Features

  • Two Battle Systems: Timed turn-based, and Debate battles where you can negotiate, convince, and debate with NPCs
  • Science is on your side: Use gunpowder and science to craft items which can help you get out of a pinch
  • Speaking to NPCs is important: NPCs can give you the facts you need to back up your arguments in debates
  • Saving the country requires more than just strength: Debate with the local lords and win their favor
  • Costumes: Changing your outfit will also change your overworld's appearance, and their appearance in skits
  • Skits: Get to know more about the characters and the world
  • Skills level up with you: The more you use a skill, the better you’ll get at it
  • Build your party to suit your play style: Decide your party's classes, and distribute stat points when you level up

And more!

The game was Kickstarted mid-2014, and has been worked on full-time since January 2015. There have been monthly progress updates since 2012 or so when I started working on the game. There are a few other people working on the game, which you can see here, and the soundtrack for the game is slowly being uploaded to soundcloud here.

As of writing this the game is about 62% complete, and will be on iPad, Android and Windows Tablets, Playbook and Windows PC (7/8/10). I'm using Cocos2dx and C++ to develop the game. If you're interested in more screenshots or world/character information, please feel free to poke around on the site.

Going forward I'll likely be posting more technical stuff I'm doing with the game, but if you have any questions, comments or suggestions 100% feel free to shoot them off. I'd love to discuss them. Thanks for reading and have a great day!




« Last Edit: November 01, 2019, 12:18:59 PM by pmarincak » Logged



Cranktrain
Level 4
****


making gams


View Profile WWW
« Reply #1 on: October 02, 2015, 06:02:48 AM »

Looks good! It's so clear that the game isn't developed with RPG Maker, which immediately makes it stand-out. The promise of a turn-based debate system is intriguing, well done for trying something that is decidedly off the well-trod path of RPG's, I'll be very interested in seeing how that works. Can you elaborate on how the 'battle'/debate mechanics function?
Logged

NinthPower
Level 2
**



View Profile
« Reply #2 on: October 02, 2015, 09:37:44 AM »

This is an RPG that def interests me Smiley Love seeing new things done with the genre.
Logged

pmarincak
Level 1
*



View Profile WWW
« Reply #3 on: October 02, 2015, 11:35:48 AM »

Both of you thanks a lot. Smiley I think that's the first time someone has said to me that it doesn't look like an RPG Maker game haha;;;;


Can you elaborate on how the 'battle'/debate mechanics function?

The debate system went through a lot of changes. It was originally going to be more of a text-analysis or "npc has certain facts" type of thing, but it proved to have a lot of difficulties in terms of getting a similar experience when playing through (like for more story/boss battle type stuff) and also for time/scope reasons.

The current version of the the system uses a weighted node graph that the player traverses with the choices they pick. Each time the player visits a node the node becomes "consumed" and cannot be visited again. The weights on the node links is either: Positive, Negative or Neutral. Positive/Negative links can your values which then get applied to the same equation for Neutral links. Different difficulties have different transformations applied to the equations (for instance, in easy mode you cannot ever lose points but in hard mode you can).

The player needs to traverse links in order to:
  • gain new information; and
  • gather enough favor to "win" the battle


In order for a debate to end, the user either runs out of choices, or time runs out (they have five minutes). Winning the debates means gathering enough favor, and hitting a "debate goal". For instance, gaining a certain piece of information.

Visually it looks something like this:

Logged



pmarincak
Level 1
*



View Profile WWW
« Reply #4 on: October 04, 2015, 10:05:09 PM »

Devlog #1 - 05/10/15

Had to take most of the weekend off because I wasn't feeling well (horrible headache), but I managed to get some work in here and there.

I updated Cocos2dx to 3.8 (from 2.2.5) the other week and I found that they had made Chipmunk the default physics engine and streamlined making the physics simulation. It wasn't too much work to adapt the Box2D code over, and I figured it was a good time to consider using the callbacks instead of the preemptive checking I was doing before, but I found a pretty nasty problem with it: tunneling.

For whatever reason, Chipmunk has a lot more tunneling issues than Box2D. I thought at first it was the world simulation step, but even reducing it to roughly 0.0001 didn't help fix it. Poking around on the internet brought me to suggestions to modify the physics world to some certain settings, but even fiddling around with those didn't help either. So I moved everything back to Box2D a few hours ago.



I've managed to get it running again. Everything got messed up with the update (of course), and I had to add in something that would draw the physics objects, but hopefully all of this can get sorted out soon. I might need to do a mixture of preemptive checks and callbacks, but I would really rather just do straight callbacks. I'll have to see how this goes through the week.
Logged



Korvex
Level 0
*



View Profile
« Reply #5 on: October 04, 2015, 10:12:25 PM »

This looks awesome! I'll have to keep an eye out for this game and tell one of my good friends. She loves Steampunk and RPGs so she'll probably flip.
Logged
pmarincak
Level 1
*



View Profile WWW
« Reply #6 on: October 05, 2015, 10:07:52 PM »

Devlog #2 - 06/10/15

I managed to get something pretty ok to work collision wise, but when I threw the player into a maze to check how it felt it was really annoying. The player kept getting snagged on corners. Plus, there's still some tunneling issues (even when setting the user's body to being a bullet), but the worst part is that the FPS drops significantly on a map that was running at 60FPS before. I don't think Box2D can do what I need now.

Good thing I just commented out the chipmunk changes and didn't remove them. I suppose I'll switch back to it in the morning and see what I can do with it. On the plus side I added escaping from battles (although visually it's lacking...).

-----

This looks awesome! I'll have to keep an eye out for this game and tell one of my good friends. She loves Steampunk and RPGs so she'll probably flip.

Smiley That's great to hear, thanks!
Logged



pmarincak
Level 1
*



View Profile WWW
« Reply #7 on: October 06, 2015, 09:44:16 PM »

Devlog #3 - 07/10/15



Switched back to the Chipmunk engine this morning and messed around with it all day. I ended up having to manually set the body's position back a bit each time it collided with a wall. I tried using impulses and forces but they didn't really work how I wanted. Biggest problem now (which you can see in the gif) is that the camera gets messed up when the user collides into stuff.

Only downside to this method so far is that very rarely does the collisions completely just not work. I can't reproduce them right now, but I might muddle with it more later. On the plus side, I've fixed the "snagging into corners" issue.
Logged



Cranktrain
Level 4
****


making gams


View Profile WWW
« Reply #8 on: October 07, 2015, 12:27:35 AM »

Implementing a full-on physics simulation seems a bit like overkill to me, for an RPG game. Is there some other use for rigidbody physics elsewhere? I would be very tempted to just implement AABB rect collisions if I could get away with it. Looking at your screenshots, it seems like you're using collision polygons, so perhaps that super-simple option is off the table, but there are polygonal collision algorithms like the Separating Axis Theorem that still might be plenty simpler than wrestling with some huge physics library. Middleware can sometimes be impossible to reason about and effectively be frustrating little black-boxes, that time throwing varying inputs at the API to get what you want might be better spent writing something that you have complete understanding and control over.

The video of the debate/battle mechanic looks very interesting. I'd love to try it out, and see what depth there is there, my guess is that the enjoyment of it is actually going to rest very heavily on the quality of the writing, both of the dialogue and the general story.
Logged

BlackseaOdyssey
Level 1
*



View Profile WWW
« Reply #9 on: October 07, 2015, 06:09:50 AM »

Looks pretty cool, any plans for some gameplay footage soon?
Logged

pmarincak
Level 1
*



View Profile WWW
« Reply #10 on: October 07, 2015, 11:56:29 AM »

Implementing a full-on physics simulation seems a bit like overkill to me, for an RPG game. Is there some other use for rigidbody physics elsewhere? I would be very tempted to just implement AABB rect collisions if I could get away with it. Looking at your screenshots, it seems like you're using collision polygons, so perhaps that super-simple option is off the table, but there are polygonal collision algorithms like the Separating Axis Theorem that still might be plenty simpler than wrestling with some huge physics library. Middleware can sometimes be impossible to reason about and effectively be frustrating little black-boxes, that time throwing varying inputs at the API to get what you want might be better spent writing something that you have complete understanding and control over.

The nice thing about Cocos2dx (and Chipmunk and Box2D) is that they're all open source. I'm not really black-box messing around with stuff. Most of my "messing around" is configuring time steps, substeps, collision responses and looking up how other people did it online. Both physics libraries have pretty good docs.

And actually, the wrapper Cocos2dx uses assumes that you will only use the physics engine with proper physics. It made manually setting the position of the bodies protected. So I actually had to change it to a public method (the engine has it public actually). But since it's all open source it's easy to switch around to suit my needs.

Besides all of that, I just use the engine for the collision responses. I've pretty much turned off all the settings that make it have actual physics.

My background is softdev so there's a lot of "don't reinvent the wheel". I think I would spend a heck of a lot more time making my own (probably not as well optimized) algs for everything.

The video of the debate/battle mechanic looks very interesting. I'd love to try it out, and see what depth there is there, my guess is that the enjoyment of it is actually going to rest very heavily on the quality of the writing, both of the dialogue and the general story.

I'm glad you're interested in it Smiley Yes, it's a very "choose your own story" like thing. I'm implementing a lot of critical thinking concepts into the decisions (strawman, fallacies of defence, etc.) and also giving some debates multiple endings. The only thing I can say thus far is that my beta testers seem to enjoy it a lot, which I'm going to take as a good sign.

Looks pretty cool, any plans for some gameplay footage soon?

Thanks Smiley I have some (year old) footage on youtube if you're interested, but if you watch it you'll see I'm very bad at making gameplay videos. After the next content update I should have a couple hours worth of gameplay time to put something together though Smiley
Logged



pmarincak
Level 1
*



View Profile WWW
« Reply #11 on: October 09, 2015, 08:39:08 PM »

Devlog #4 - 10/10/15

Spent the last day or so being wishy-washy ill and doing PM stuff. On the plus side, I managed to fix the camera issue. I've also been updating some larger maps and cutting them up to add to the game over the weekend even though it's thanksgiving.

The camera issue mainly spawned from a tutorial I used about 2-3 years ago when first getting this movement down. If you google some combination of "cocos2dx tmx map" you'll end up with some tutorials. Often times their suggestion is to move the map in the opposite direction of the user when you move the user around. They also tend to have some pseudo code for making sure that the map didn't keep scrolling in any direction once you ran out of map. This is how I had it before.

It worked pretty well and I didn't really have any issues with it, but from time to time if you bumped into something the map stopped scrolling because the user wasn't in the center of the screen anymore. Even with a small offset it was like this. It wasn't a huge deal to be dealt with right away since it was very hard to consistently trigger, so I left it on the back-burner. As seen in the last devlog though, I couldn't quite do that anymore.

There's quite a few suggestions if you look for either the cocos2d or cocos2dx engine, but the one that worked best was using the Follow action: have the map follow the user. It modifies the map's position based on the user's position at every timestep and by default it's set to change the position when the user is in the center of the screen. It also has clamping so the map doesn't scroll too much once the user reaches the edge on the screen.

The only downside was that I did have to subclass the action and make some extra point calculations and set the position using actions to smooth the transitions out (instead of suddenly jumping around), but it wasn't too hard.

I think the main reason the previous code failed was because the map's position was never consistently being set relative to the user's position. It was basically that the user's position would be set to, say, 5px ahead. The map's would be set to 5px behind. If the user hit something, it's movement would be stopped before the map's. It would appear that sometimes, because of this, the errors would be caused.

TL;DR, I've managed to remove a huge chunk of code and simplify things down, and the camera issue is finally resolved.

Hoping to get a bunch of maps added over the weekend when I can. Then it's back to bug fixing =A=;;;;
Logged



pmarincak
Level 1
*



View Profile WWW
« Reply #12 on: October 18, 2015, 09:09:43 PM »

Devlog #5 - 19/10/15

The past week and a bit I'd been low key ill, and late last week it all caught up with me not sleeping for around 24-48 hours so I ended up sleeping for most of the weekend and not getting much of anything done. Or well- what I'd planned to get done.

Adding maps to the game is an extremely tiresome process for me and I spent this weekend trying to figure out how to automate it more. I use Tiled maps for the game, and export foregrounds, background and middle ground from Photoshop. In the current stable build, the foreground and background are added to the map and imported seamlessly, but the middle ground was cut up into individual images and added as code during runtime since the player and NPCs/enemies would need to walk in front and behind them.

This led to a lot of code. For the bigger maps, there were hundreds of lines that looked like this:

Code:
CommonEvents::createSmallPineTreeC(events, Point(34,133), this);
CommonEvents::createSmallPineTreeB(events, Point(0,258), this);
CommonEvents::createBushA(events, Point(15,19), this);
CommonEvents::createBushA(events, Point(79,154), this);
CommonEvents::createBushA(events, Point(39,292), this);

Each one of these methods were more or less the same: they would cut out the appropriate image from the spritesheet (ex. bushA), add a collision body to the object, place it at the point, and shove it into the events array, which would be used to set the draw order at a later point in the update cycle.

This method had it's good points - mainly that the collision body would be set to the object and would be the same of all object types - but it was extremely time consuming and brain-numbing.

Since I'm still in the middle of fixing architecture, and with the new renderer in the game engine, I poked around a bit and saw that there was a method to automatically have the engine parse individual tiles and treat them as middle-ground. For anyone interested, it's using the vertexz method listed in the wiki. The previous method was using the ZOrder method.

It was extremely time consuming to get running, but in retrospect it was actually pretty easy. I suppose doing this while sick is not the greatest idea >A>;;;

I haven't tested how much faster this method is to add to the game than the older one, but since the other one was taking 6+ hours for a map, and my quick tests took a few minutes to add a significant number of items, I'm going to assume it'll save me a lot of time and headaches.

The only cons I can think of is that I need to add the collision details/hit boxes for each object to the map instead of having it automatically done, but even then it gives me a bit more room to tweek each map if certain areas give me issues. Besides that, the items on the left and bottom of the map that overlap onto the other map will need to be added in the engine still, but that's only ~10 lines of code versus 100's so it should be perfectly fine.

I'm likely going to test out creating the middle ground from PS like the foreground and background, and then having it function similarly, to see if it can be simplified even more (and get rid of the second con). Hopefully I'll have decided the way forward tomorrow so I can show it off in Tuesday's dev stream. Smiley
Logged



pmarincak
Level 1
*



View Profile WWW
« Reply #13 on: October 20, 2015, 08:37:35 PM »

Devlog #6 - 21/10/15

Small update as I try to save my computer from combusting. (It's one year old now. Goodbye warranty hello sudden hardware and software failures.)

I tried out the idea of exporting the middle ground in PS to Tiled, but I ran into a problem which makes it easily useless: if an item in the middle ground is taller than the tilesize for the tileset, the user can appear to be on top of and behind the object at the same time. I could just increase the tilesize, but for objects close together, where the user needs to be in front of one object and behind another within 10-20 pixels, it won't work properly.

So I'm just stuck to adding the middle ground manually to the Tiled Maps.

I've actually timed this, and given that the old process took 6-8 hours to do per map, this new method takes max. 2 hours. (I was watching the election last night while doing this so it might've lengthened it out a fair bit, but nonetheless it was 2 hours.)

In other related news, I spent most of the day today fixing issues with draw orders using the OpenGL depth buffering among other npcs and such. I have to update quite a few more event types, but hopefully everything will be running ship shape soon.

I'm also hoping that since this new method removes a couple hundred draw calls, the frame rate on Android devices will improve dramatically.

After that, it's more bug fixing then adding Round 3 content and tweeking some content from Round 2 Smiley
Logged



pmarincak
Level 1
*



View Profile WWW
« Reply #14 on: October 25, 2015, 09:17:49 PM »

Devlog #7 - 26/10/15

Finished adding in the rest of the sub-maps for the next start of beta-testing. Also fixed all of the camera issues so everything should be working great on that end from now on. Smiley

I'm trying out this timer app thing called Toggl this week to see how much time I spend working, and how much time I spend on tasks. I'm hoping to get all of the Round 3 content in this coming week, so it would be good to know for plotting out future dev since I made process changes the past few months.

Also, a screenshot from a devstream I ran the other day; the participants made Ann the apple lover.

Logged



Cranktrain
Level 4
****


making gams


View Profile WWW
« Reply #15 on: October 26, 2015, 12:23:59 PM »

I'm trying out this timer app thing called Toggl this week to see how much time I spend working, and how much time I spend on tasks. I'm hoping to get all of the Round 3 content in this coming week, so it would be good to know for plotting out future dev since I made process changes the past few months.

I've been using Toggle for the last couple of months! It's pretty great. I'm hoping at the end of my current project to be able to look back and see exactly how long the whole thing took. Do you have a roadmap of all the things still remaining for the game?
Logged

pmarincak
Level 1
*



View Profile WWW
« Reply #16 on: October 26, 2015, 09:14:37 PM »

I've been using Toggle for the last couple of months! It's pretty great. I'm hoping at the end of my current project to be able to look back and see exactly how long the whole thing took. Do you have a roadmap of all the things still remaining for the game?

Yep. I've had a roadmap for a few years now? I think? It's how I can give these percentages each month Smiley

Glad to hear Toggl is working well for you. I keep forgetting to turn it on when I start working, but I have liked how if I go idle it asks to keep the time or discard it when I come back. It's been fairly helpful so far today when I was dragged away a few times by my family and I didn't click the stop button. I know with the previous timer apps I was using it wouldn't stop and they were pretty simplistic. I'm interested in seeing my report at the end of the week. Smiley
Logged



pmarincak
Level 1
*



View Profile WWW
« Reply #17 on: October 30, 2015, 12:56:26 PM »

Devlog #8 - 30/10/15

Took a short break from bug fixing to work on some UI designs for the crafting system (which I realized I hadn't done yet).




Basically, you can either experiment or use a recipe to create an item. After a successful experiment, you know the recipe for it and can use it as a shortcut (and to make more than one item at a time). The preview box will let you know if you're going to succeed or not before you try. Not sure if I should change it or not to be "well you might get something" type of message instead; trying to account for mobile/casual users as well.
« Last Edit: October 30, 2015, 02:02:11 PM by pmarincak » Logged



pmarincak
Level 1
*



View Profile WWW
« Reply #18 on: November 04, 2015, 06:09:18 PM »

Devlog #9 - 4/11/15

I'm not feeling 100% (still sick) and bug fixing has annoyed me a bit, so I've taken a break to work on some maps. This is one I completed earlier today.

Logged



pmarincak
Level 1
*



View Profile WWW
« Reply #19 on: November 12, 2015, 10:08:17 AM »

Devlog #10 - 12/11/15

Over the last week or so I've been working on maps and fixing bugs, so nothing too interesting to show in regards to that. The great thing is that I've fixed 99% of the bugs so I'll be adding new content to the game this coming week. After that is a lot of bug testing and then the next beta round can start Smiley

I haven't added new content in a while, so I'm interested in seeing how long it takes. The last beta update I did didn't have too much in terms of content, but testing all the platforms took about half a day. I'm adding PC support in this release so hopefully that... isn't too bad....

In any case, I want to have weekly or biweekly releases with bugs fixes and content so I have a feeling I'll have a lot of planning to do in the next few weeks. In any case, for the next release I'll have more screenshots and gifs to post. Smiley I'm thinking about making a new gameplay video after Round 3 is complete or perhaps during it... I have to fix a lot of UI first though.
Logged



Pages: [1] 2 3 ... 6
Print
Jump to:  

Theme orange-lt created by panic