Well, it looks like the UDK forums are no longer accepting new posts, so it’s time for me to transition over here.
Himeko Sutori has been in development for about two years now. I’ve been working on it with virtually all of my free time for at least the last year and a half and I hope to have an alpha demo ready in the next month or two. My UDK forum entry was over at First Peek: Himeko Sutori - Epic Games Forums. I’ll be posting my updates here from now on.
First up, in response to majic12’s last post on the old forums: Yes, I’m planning on PC and Mac for the first release. If it does really well, then I would love to do console versions. I’m really glad to hear your optimism for the game!
For now, let me repost some older gifs showing the gameplay…
Battle scenes:
Building your squads:
And over the last couple of weeks I finished some other menus. Here is the menu for changing character class and equipment:
This is the level-up system, recorded in Flash with placeholders that would get overwritten during gameplay:
‘Himeko Sutori’ seems to be inspired by ‘Final Fantsy Tactics’.
The some graphic detail and high resolution UI is better than ‘FFT’.
Good work.
But I think that the the mobile version has the advantage over the console version.
Because people want to play the game that is filled with super high quality 3D data(mesh, texture, motion, …) in Play Station 4 or X Box One.
I hope that you consider the difference between ‘the expectation about console game’ and ‘the expectation about mobile game’.
Good luck.
Thanks very much Kee Hoon Ahn. And yeah, maybe I should look into mobile next.
And yes, FFT was one of my inspirations. I loved FFT, but the battles were so small that I never felt like I was an important player in the war. I think I was more directly inspired by Ogre Battle 64, but I felt the fighting itself was too generic and uncontrollable. So I took the best of both, and made a game that was tactical, turn-based, with some control over combat, but on a large scale. I think people are going to like it.
We’re going to be launching the Kickstarter tomorrow. This is the trailer we’re using. I’ll post the address of the Kickstarter campaign tomorrow after we’ve launched.
And we’re live! The Kickstarter campaign is now up. Thanks everyone for all the help you’ve given me over the last few years. This forum has made this game possible.
Hey! It’s been a while since I posted an update here. I guess when I get out of marketing mode and go back into development mode, I just want to sit down and finish the game. But I do have a few things to post:
So the campaign was successful. I got myself the full license to UE3 and I’ve been spending some time on the UDN. I have all of that set up now, and I compiled my own game and editor.
As for updates on the game itself, here’s my latest video. It shows off smart sprite layering, switching layer order, switching sprites based on items equipped, switching hair sprites based on helmet equipped, and adding literally hundreds of items into the game.
And I realized that there’s some older stuff I should link here too. For example, here’s Himeko Sutori’s composer, Kevin Won, recording some of our soundtrack:
Hey Kee Hoon Ahn. Thanks so much! I was really impressed by what Kevin turned out there.
As for the UE3 license, I don’t think the NDA covered price, but I also don’t know if they change prices or negotiate rates so it might be best if you just asked Epic directly. The price was a lot less than I thought it was going to be honestly, and Epic’s people are really smart and friendly. They’ll talk to you about your project and then help you decide whether a UDK or UE3 license is best for you.
The one thing I wasn’t prepared for was the cost of getting SpeedTree separately. I thought to myself, “If SpeedTree is included with UDK, and it costs only $19/month with Unity, then I can totally afford a license with UE3.” I was wrong. If you don’t already have an arrangement to bundle SpeedTree in your prepackaged game Engine, and if you don’t have a million-dollar budget, I don’t think you’re going to be getting SpeedTree.
As for the music, you’re not going to believe this… The recording was free!!!
Kevin was working on his master’s in Composition for Film and Videogames at Berklee Valencia, and as part of the program, each student gets one day with a recording studio and an orchestra. I’ve been paying Kevin for composing, and he volunteered to use his day at AIR Studios to record Himeko Sutori’s prelude. I say it over and over again every chance I get: I cannot believe how lucky I was to run into this guy.
I’m going to try making a monthly update video, showing the game’s progress. Here’s what I can show off for October:
The most time-consuming task was making a placeable actor to serve as the data structure for the different hairstyles. I had to tell the game, for example, that if a character had short blue hair, then this was the sprite for short blue hair, and this was the character portrait for short blue hair. After I manually filled in the acceptable combinations, I let the game generate all the characters for me. Also, the characters have names picked from some long lists. I have several hundred names for men and women, compiled from several European languages, Japanese, Hindi, and a bunch of African languages. I’ll add a few more name lists from other languages before I’m done. But mostly I have to make a lot of sprites for the different weapons in the game.
Edit: Removing last month’s video. Looks like I already posted that.
Thanks so much Kee Hoon Ahn. I think it’s improving too. In fact, I put together a side-by-side comparison of some of the art I was using just to see the difference:
In 2014 I made my first sprite, on the left, which was terrible for many reasons. The sprite on the right was the one I used in my embarrassingly bad Steam Greenlight video. In 2016 I was most recently working on the two sprites at the bottom, showing the paladin and ranger armor, with some layers turned on and off to show the different armor tiers. I think they’re a big improvement.
And I just now put this together:
animated gif
(It’s too bad we can’t actually show animated gifs in our posts here.)
That’s showing my start on the vendor system. I’m still trying to decide on how to determine item prices and was thinking about these systems:
Set price for buy, half price for buyback: This is probably the most common in Japanese RPGs. It might also be the easiest to implement. It might work best here because that’s just what players would probably expect.
Calculated price based on stat boost, small percentage for buyback: This is the system at work in a lot of MMOs, making sure that item prices are balanced. Throw in a lot of loot after a battle, and you have an exact copy of World of Warcraft’s vendor-trash economy.
Supply-demand economy: This is definitely the hardest to simulate, and it might be the most interesting, but it could also just be unappreciated effort. For every item there’s a base price, and then based on the availability of that item in a given city, adjust that price up or down. So with every item you offer back to the vendor, he’ll offer you a lower price. This is the system at work in Mount and Blade, one of my favorite RPGs.
By the way, the items in your inventory are listed individually, and not stacked. The reasons for this are varied, but one reason is that I want to include weapon level-ups at some point. Basically you can enchant your items, but only after you’ve leveled them up through use in battle, and different enchantments requiring different stats (including one powerful enchantment that will require at least one previous wielder to have died). There will be a popup window that appears on mouseover to show you an item’s stats, so you know not to sell that sword that’s about ready for a new enchantment.
But that’s all pretty far down the road still. For now I just have to decide on how to calculate the prices. If any of you have any thoughts, I’d love to hear it. Or if you have any thoughts on the look of the UI, I’d love to hear that too.
Here is a major update, showing off the world map, a day/night cycle, resting and eating, and a bunch of other scope creep that I’m glad to include for you.
Thanks very much udkultimate and Kee Hoon Ahn. I’m slowly getting this game to where I want it to be, one line of code at a time.
Here’s the official February update:
In there we have the world map, enemy armies, transition to combat and back again, plus background music. I think the mix got messed up because I set the music to higher processing priority, and so the music probably got ahead of the timer during a performance hiccup.
In the video I also mention that I had the game spawning around 5,000 pawns, which was slowing down the game. Each character is only a square that adds two triangles to the scene. 10,000 additional triangles shouldn’t make a difference. I used Unreal’s profiler to find out what exactly was slowing down my game, and discovered that most of the problem was with ticking the pawns’ controllers. So I only give controllers to the enemy pawns when they enter combat. The next biggest slowdown was a deproject that I perform on every character to find out where on the screen it is so that I can tilt the 2D character sprites to counteract the camera’s perspective. Somewhere around here I have a long explanation for how I draw the sprites and why I do it that way. Anyway, point is, it involves a deproject and doing it 5,000 times per tick is pretty costly. So I changed that to update only while the character is onscreen. After some other optimizations, the game runs just fine, even with up to 5,000 characters in the game.
At this point the game engine is pretty much finished and I’m going to focus on making a playable campaign.
