Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411491 Posts in 69377 Topics- by 58433 Members - Latest Member: Bohdan_Zoshchenko

April 29, 2024, 07:13:52 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsHalley - Multi-Setting Classic JRPG
Pages: [1]
Print
Author Topic: Halley - Multi-Setting Classic JRPG  (Read 1526 times)
tterlinden
Level 0
**



View Profile
« on: May 10, 2015, 01:53:05 PM »

Halley is a SNES era influenced RPG, heavily inspired by FF3/6, being developed by Metrognome Games.

The Story So Far
A mysterious comet brushes Earth's atmosphere during a slumber party, The group of gamers involved find themselves trapped in alternate dimensions that resemble their favorite games. Using their imaginations, they travel through these worlds in order to find their friends, family, and get back home. Along the way, they come across clues that suggest this warping of realities is no accident and realize that before they can go home, they must use their imaginations to become the heroes of the games they love. They set out to save not only their world, but the alternate realities they've grown to love.

The Game So Far
The development has come a pretty long way in the past few months, starting from a messy codebase from a previous SRPG project. There's support for menus, world maps, towns, NPCs, battles and many things revolving around those main pieces. The goal for the programming side, all being done by me, is to make sure at least something gets done every day, so there's always new things being completed, whether they be huge pieces like the battle system or small things like dialogue triggers. The more immediate goal is to get towns complete to the point where the player can go into and out of buildings, then I'll be getting back to adding more features to battles.

The game is being horribly written in C++ using SFML, RapidXML and soon to be using SQLite for the items, characters, dialogue, etc..., everything but the maps, basically.

Here's a clip of some simple menu stuff that's working pretty smoothly.


Almost all the art is either ripped from FF3/6 or Shining Force or obtained from opengameart.com except for the one sprite that I'm using, which is from an old, abandoned project.


I'm definitely looking for some good feedback, whether creative or technological. I usually post daily updates on my FB page, some more technical than others. I think I'll probably roll those up into a weekly update for TIGSource and make sure I post on those screenshot Saturdays. Looking forward to getting this devlog rolling!
« Last Edit: May 16, 2015, 06:33:06 AM by tterlinden » Logged

C# developer by day, C++ developer by lunch break

- Halley Devlog
Gregg Williams
Level 10
*****


Retromite code daemon


View Profile WWW
« Reply #1 on: May 10, 2015, 05:54:13 PM »

Hurray, feel like I've been waiting for you to make a tigs dev log forever  Cool

Guys, watch this project, I've known Travis for years now, and he is really dedicated to this project.

Logged

tterlinden
Level 0
**



View Profile
« Reply #2 on: May 16, 2015, 06:39:48 AM »

The past week has been pretty lax as my main dev machine (my laptop) has finally called it quits. Hard drive failures are a dev's worst enemy. Luckily, everything's in source control and I got it all moved over to my desktop and got RDP access setup to work on there whilst the lappy is getting fixed. Enough about that, though.

I started working on gettingo SQLite into my codebase and it went easily enough. I should be able to have the entirety of my object reading code ported over to using SQL by the end of this coming week, methinks. From the last post, I mentioned I was attempting to get towns working fully, and I've been successful in that, so far as getting NPCs talking and buildings enterable/exitable. Once the SQLite changeover is complete, then I'll be getting back to battles and making some fun stuff happen in there.

For the buildings, the method I ended up going with was to create a new layer in Tiled for each floor of each building, then setting up a trigger on the first tile of the door that will switch the draw layer(s) to the that of the buildingID specified in the trigger attributes. The main reason for this is that it allows us to make the buildings 'bigger on the inside' and also not having to worry about switching maps entirely each time a building is entered or exited.

As you'll be able to see if you follow along with the log is that I'm fairly miserable at determining the best part to work on next and I jump around to different parts of the code quite a lot. At least it should keep things interesting  Smiley

Maybe I should do collision next? *shrug*
« Last Edit: May 16, 2015, 06:56:53 AM by tterlinden » Logged

C# developer by day, C++ developer by lunch break

- Halley Devlog
tterlinden
Level 0
**



View Profile
« Reply #3 on: May 23, 2015, 12:11:44 PM »

After all the work to get SQLite into the project, I decided to can it unless our designer decides he'd rather do DB editing instead of XML. It also helps that I've finally come to my senses about coding what I don't need and not fixing what isn't broken.

As far as what was actually done in the project, I added terrain types & zones to the world map so it's easier to assign enemy encounters to different sections of the map and so that those encounters make a little more sense based on the type of tile the player is standing on. This will help encounters make a little more sense so that the player won't encounter, say, a laser mounted sea turtle while walking through a mountain pass.

I also began working on the cutscene subsystem. This is more for script controlled 'gameplay' cutscenes, rather than video based ones. A cutscene is made up of a collection of steps which can be of movement, effect, dialogue, sound or animation types for now. The cutscene controller then runs each step in order and will handle sending messages to any other subsystems if the step calls for it. The maps will then contain a trigger object with an event ID to determine when it should go off, and the ID of the cutscene to play when it does get triggered.

Oh, I also did collision tiles, which just consists of creating a layer that uses tile ID 0 for any spot that the player shouldn't be able to walk to, then checks to see if a tile exists in the collision layer with that ID at the new destination index. Nothing really special there, but a pretty important part of maps.

Unfortunately I don't have any new in game screenies this week, so I figure I'd post a screencap of my random encounter generator. Any feedback would be great  Grin

Logged

C# developer by day, C++ developer by lunch break

- Halley Devlog
tterlinden
Level 0
**



View Profile
« Reply #4 on: May 31, 2015, 04:36:02 AM »

This week was a whole bunch of work on the cutscene system, which I'm proud to say is now in and working as intended. It currently only supports character movement and dialogue (which you'll see needs a bit of work itself), with future functionality to include effects, camera movement and animation switching. Adding more features should be the easy part now that going through steps and triggering everything works well.

This will now bring me back to the battle system, which, as it is for most RPGs, is where the meat of the game's work is. It currently supports basic attacks and the death of enemies & players, but doesn't have much of a resolution besides going back to the world map. Two of the features I'll be implementing first are timed hits and charging.

Also, I got my laptop back this weekend, so I'll be able to code & test right away, rather than trying to code remotely and only being able to test if I manage to stay awake!

Here's a proof of concept gif of the cutscene system. As you'll see, there's nothing massively special about it, but it opens itself up to a bunch more functionality to make things much cooler. And don't mind the stools with white backgrounds. That's all collision tests.

Logged

C# developer by day, C++ developer by lunch break

- Halley Devlog
tterlinden
Level 0
**



View Profile
« Reply #5 on: June 08, 2015, 04:15:50 AM »

The past week was supposed to be devoted to doing battle system work, but it ended up turning into nothing but GUI work. I ended up adding a bunch of customization attributes to an XML file to build all my menu windows from, which includes things like position, dimensions, default text position and default word spacing. The final two are more useful when just adding static text either just vertically or just horizontally.

The better GUI stuff I ended up doing was getting the progress bar working. It wasn't so much a technically difficult accomplishment, but it definitely helps to make things look nicer. The next goal is to use the progress bar to get the post battle experience screen built out, then move on to the loot screen and finally, back to actual battle gameplay things.

I did manage to get the progress bar in for the battle turn timers, a la, FF3/6.



Logged

C# developer by day, C++ developer by lunch break

- Halley Devlog
tterlinden
Level 0
**



View Profile
« Reply #6 on: June 15, 2015, 08:32:14 AM »

The past week has mostly been spent working on the in-battle menu system. While it's nothing special yet, it gets me one step closer to being able to work on the real meat of the combat. The way I ended up doing the menu was by creating a child of my current window class and allowing the addition of menu items, each having a text object and an ID, that are displayed based on the column/row count that is set earlier in the menu setup process. Finally, a callback is set so when an option is chosen, it will hit that method and pass back the ID of the chosen menu item. The calling class (in this case, Battle) will take the ID and decide whether it needs to open a new menu, like in the case of abilities or using items, or if it should move on to target selection, like in the case of attacking or defending.

Getting all this stuff setup ended up giving me a few bugs in the battle flow, but I think I've ironed them all out at this point, so I'm ready to start adding in new steps once the ability framework is complete, which should be in the next few days.

Here's a screenie of the battle menu. Nothing flashy yet, but it's functional and moves me along.
Logged

C# developer by day, C++ developer by lunch break

- Halley Devlog
tterlinden
Level 0
**



View Profile
« Reply #7 on: June 17, 2015, 10:08:16 AM »

The in-battle menu system is nearly 100% complete and works well in the couple instances I've used it so far. The bulk of the work was done on it to support ability selection, which is now working pretty well. The battle flow will be changed tonight in order actually support the use of the first type of ability, which is a timed attack. The goal here is something similar to Super Mario RPG where the player must hit a button just as the character's hit is going to connect in order to produce an additional effect or increase damage.

The way I plan on getting that all to work is by using animation frame triggers so that on a particular frame, it will trigger a the button press window to open, then on a subsequent frame, close that window. Since the game already supports animation triggers, I should just need to setup a messenger callback in my battle controller and subscribe it for any animation triggers. I don't think it will be a lot of work, but I always say that and it always is  Smiley

In other news, the game should have an original tileset somewhat soon. The artist has been working on it for a couple weeks in between a mass of other projects, so I'm hoping we'll have something really nice to look at shortly.

Here's a lovely parting gif of the battle menu system at work:
Logged

C# developer by day, C++ developer by lunch break

- Halley Devlog
Pages: [1]
Print
Jump to:  

Theme orange-lt created by panic