July 02, 2013, 10:20:53 am

Alright, over my time off I've decided to split the project into two to make things easier. I've really been wanting to get started on programming and stuff, rather than spend all my time doing graphics. So in conclusion, I split the project into "Normal" and "HD" graphics so I can go ahead and start writing scripts.

This will allow me to go ahead and start programming using the "Normal" graphics, and then as I finish the "HD" graphics, implement them and replace the old "Normal" graphics as everything gets completed. Make sense? hint: (Replace "Normal" graphics with "HD" graphics as they're finished, rather than sit and wait so I can begin programming)

Putting most of my effort into them this weekend, here's my progress so far with "Normal" graphics:

The amount of progress has allowed me to already started on working on the Battle System, but graphically all I have left is 3 things, which is the bridge, the house roofing and door, and the pine tree. The tree is giving me a bit of a problem, but the rest should be done in a matter of time.

. . .

For the "HD" graphics, I've pretty much translated everything into tiles that was in the original picture. The hard part is attempting to actually visualize what was in mind and manage to manifest it. Here's the progress on that:

The tileset:

Was hoping the community could offer alittle help on the HD graphics that way they get finished. Otherwise, I'll most likely have to abandon them due to difficulty. If we focus on one object a day, everything should be caught up by the end of the week. Here's the listed objective for the Basic Tileset that goes with the project:

You say "HD", but they're the exact same resolution? I suppose you mean stylized rather than HD.

Makes sense to go with simpler graphics so you can focus on the game. Though that would mean you could really get two versions of all the graphics, in which case I think it might be a good idea to separate these into clear directories and give the game the ability to switch between the two (when things get that far, of course).

At the same time, instead of clearly deciding what you're going with, you seem to be indecisive and instead plan to do both. That's almost double the work! You could choose to continue with the stylized graphics and treat your current "normal" tileset as placeholder, then spend some less time on new placeholder graphics as you need them and replace them with the stylized ones later. But it's up to you, of course.

/*** Returns the file name for a sprite, depending on the current resolution.* Example:* CreatePerson(getSpriteFileName('hero.rss'), true);* // will be CreatePerson('hero-hd.rss', true) if the resolution is greater than 720,* // CreatePerson('hero.rss', true) otherwise.*/function getSpriteFileName(spritename) { if (GetScreenHeight() >= 720) return spritename.slice(-4) + '-hd.rss' return spritename;}

// and in every person's create script addSetPersonSpriteset(GetCurrentPerson(), LoadSpriteset(getSpriteFileName('thispersonsspriteset.rss')));

You could do something similar for maps. Admittedly this is very tedious, especially if you have to set all the create scripts manually. My RPG framework, Arq, has ways to automate that, and RadRPG (Radnen's RPG framework) and Spectacles (Bruce's RPG framework) probably have similar things. All three are awesome, I've looked at the code of all of them and you really can't go wrong with any of them except that they're all in alpha at best and only used in one game each.Hm, maybe an "RPG framework and tech demo" competition is in order. A lot of people (try to) make RPGs with Sphere, encouraging several tools to help them is a good thing.

alpha123: the RPG frameworks are also slightly different, mine is more foxused on action RPG's, while Bruces is for FF styles games and your is, well yours (I don't remember you showing your game anywhere?).

Anyways, I like "HD on Normal" look, but please stop calling it HD unless you intend for it to be high resolution. Just call it the 'detailed' version.

If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

alpha123: the RPG frameworks are also slightly different, mine is more foxused on action RPG's, while Bruces is for FF styles games and your is, well yours (I don't remember you showing your game anywhere?).

By default, mine is focused on action RPGs, although every module can be replaced and it wouldn't be hugely difficult to write an FF-style battle system for it. I've tried to keep things as loosely coupled as possible, so in theory you could rip out the whole party system and write a new one with different stats, new ways of handling items, etc, although that would be quite a lot of work. Just adding a turn-based battle system is fairly easy though.As for the reason you haven't seen mine, 1) I'm not very far along with the story and 2) It's using almost entirely placeholder graphics right now, and I'm a terrible artist. I've found a few tilesets I can use, although currently I'm occupied more with the programming than the map design.Perhaps I'll release a tech demo soon, once I get cutscenes working again (I'm in the process of updating from Scenario 2.1 to 3.6).

Perhaps I'll release a tech demo soon, once I get cutscenes working again (I'm in the process of updating from Scenario 2.1 to 3.6).

Good to see someone other than me is getting some use out of Scenario. I don't know if you noticed when you were looking through the code for Spectacles, but I'm currently working on Scenario 4.0, which includes conditional branching/looping. I'm still trying to perfect the variable system, it's a bit... odd... at the moment, which is why I haven't released it. Plus there are a few other changes I want to make to the architecture first (adding a finish handler to scenelets, for one thing, so commands can return values).

Good to see someone other than me is getting some use out of Scenario. I don't know if you noticed when you were looking through the code for Spectacles, but I'm currently working on Scenario 4.0, which includes conditional branching/looping. I'm still trying to perfect the variable system, it's a bit... odd... at the moment, which is why I haven't released it. Plus there are a few other changes I want to make to the architecture first (adding a finish handler to scenelets, for one thing, so commands can return values).

Walk('hero, 'north, tiles: 5);"Hero": "I've just returned from the south.";"Master": "I take it you were successful?";"Hero": "Yes.";Walk('master, to: [45, 9]);fork Walk('hero, to: [45, 10]);endsync;Turn('master, toward: 'hero);

I'm still messing with the syntax a bit; I'd like to get rid of parenthesis, semicolons, and do a few other things to make the language seem tailored specifically for cutscenes.Once I get the bugs ironed out of my pathfinder, I'll make a graphical cutscene creator.

I'm having enough trouble upgrading to 3.6, don't change too much stuff in 4.0. (Mainly my problem lies with the fact that it doesn't manage its own update/render loop anymore - which actually fits my code design much better - but I was pretty reliant on the old behavior.)

In 3.6, I was pretty sure Scenario.prototype.run() included a 'waitUntilDone' argument that, if you set it to true, mimics the old behavior. It even handles the case where your map engine framerate is different from the global framerate. If you use a custom threader like I do in Specs to drive Scenario updates though, you may have to monkey-patch the .run() method to get it to cooperate.

One comment about your code above, though: Your usage of fork above is incorrect. Fork essentially means "start a new thread and run everything in this block in that thread", sync means 'halt current thread until all subthreads are done'. Since you didn't do anything between fork and sync, that's the same as not having the fork at all. What you should have is this:

In 3.6, I was pretty sure Scenario.prototype.run() included a 'waitUntilDone' argument that, if you set it to true, mimics the old behavior. It even handles the case where your map engine framerate is different from the global framerate. If you use a custom threader like I do in Specs to drive Scenario updates though, you may have to monkey-patch the .run() method to get it to cooperate.

Yeah, I noticed that. However it looked from the code to be effectively deprecated, plus I figured the new way is somewhat cleaner and allows me to do things like have weather in cutscenes.

Quote

One comment about your code above, though: Your usage of fork above is incorrect. Fork essentially means "start a new thread and run everything in this block in that thread", sync means 'halt current thread until all subthreads are done'. Since you didn't do anything between fork and sync, that's the same as not having the fork at all. What you should have is this:

Ah, thank you!

Sorry for hijacking your thread Vakinox. I really do like the look and especially the feel of your graphics.

Apologies for late reply guys. My internet is down, so having to hook up at a nearby gas station.

Didn't actually mean "Higher Definition" :p silly me.Just didn't know what else to call the other project, pseudonym semantics... "Detailed" version is what I'll use from now on.

As for framework, game will be an action RPG, but can be turn-based when enabled from the menu. Also, includes FF tactics-style gameplay depending on amount of players in party (>3).

. . .

Quote

Makes sense to go with simpler graphics so you can focus on the game. Though that would mean you could really get two versions of all the graphics, in which case I think it might be a good idea to separate these into clear directories and give the game the ability to switch between the two (when things get that far, of course).

That would be cool to implement, just would take alot of rewriting script-wise.If am going to work on both version, might be simpler to just keep themas two separate projects.

Quote

At the same time, instead of clearly deciding what you're going with, you seem to be indecisive and instead plan to do both. That's almost double the work! You could choose to continue with the stylized graphics and treat your current "normal" tileset as placeholder, then spend some less time on new placeholder graphics as you need them and replace them with the stylized ones later.

Personally, rather drop the "detailed" version altogether if I have no one to help work on them with me. Without some kind of cooperation on the graphics it'll take too long, and just end up with me losing interest. The "normal" tileset is already enough trouble as is, though it may not look it. Mainly cause of my lack of artistic talent, or vision, and inexperience with pixelart.

And because the inhabitants over at pixeljoint and pixellation are kinda avoiding contributing help, and making complexing demands (additional color-space), I'm pretty sure giving up on "detailed" version is a better thing to do. Pixeljoint began to really help, but recently they've just stopped. And it's hard to get a topic going with people interested. Even harder at pixellation where almost no one will bat you an eye unless some sort of talent is expressed. I got one comment from them on my topic, and that was really surprising.Just wish they (both forums) would actually help on the "normal" version rather than talk about how there should be one more color. Gets kinda annoying I'm still working on the same graphics of the "normal" version for 3 days now without constructive contribution to it.

Soon as I get my internet back up (Saturday) though, I may have a small demo ready for the normal version.

. . .

Quote

Hm, maybe an "RPG framework and tech demo" competition is in order.

Sounds good to me. I can always to a quick two week project. Just has to have a fair time limit. Trouble graphically is what usually handicaps me.

And no, this game isn't in actual HD. Just had to refer to it in some way different than the other version, and didn't know how. Only difference between the two is one additional colorspace, because of the folks' over at other pixelart forums demands.

Quote

As for the reason you haven't seen mine, 1) I'm not very far along with the story

If you need help with this, I can in my free time. Not hard for me to write a story, in fact may do a tutorial for VideoGame Storyboarding whenever I'm not working on my game.

Also have the original one track piano midis, if these suck too bad or if anybody wants the originals for editing, I'll post those as well.

. . . .

Just finished up a few more tracks today. ZIP Package includes: 1.) Battle Theme 2.) Main Theme 3.) Town Themeand two other unnamed tracks. Each also comes with separate versions, (piano-only) + (instruments-only)

Just a recommendation: when you share a song with people on the internet (or include them in your game), it's better to convert them to ogg or mp3 format. WAV is uncompressed and zipping them doesn't gain you as much as converting them to compressed music formats (ogg/mp3).

BattleTheme02I like the alternative timing you've got going on there. However, listening to it for the first time, you can't tell at all where one measure ends and the next one starts. Try to define the first beat of each measure more - by making (some of) the instruments a bit louder, or by not cutting the note, or by adding percussion that guides you along the way, or by adding one more instrument at only that moment (an orchestra hit, a cymbal crash, a...).

Looking at the MIDI (through a program that is admittedly not intended for MIDI), I find that you used 8 channels (that is, 8 notes playing at the same time).Suggestion: try to find a way to find less instruments. If it's for this GB-style game you're showcasing, you're really limited to only 4 channels. That's what makes Gameboy sounds so minimalistic. Try to adhere to this by deciding what exactly you're going to use each of those 4 channels for, and sticking with that. For example, a channel for the bass line, one for defining the bass line, one for the main melody (if any), one for percussion. You can break the rules a bit and use 5 or 6 channels if you like, but make sure it's not much more than that!

ALL of the notes also play at exactly the same time, there's no variation between the instruments' different timings.Your song kind of reminded me of this: https://www.youtube.com/watch?v=l30EEyXQ8tU&list=PLBF60BFC46EBC9E49Now listen to how different the bass line is from the rest of the notes. Heck, they even make it into the main instrument because it has the strongest melody in the song!

Speaking of which, you have no main melody going on. Either that, or every instrument is playing it at the same time, which means you're lacking an accompanying background melody to the main melody. It's either of these, but not both. I think you set up a good background melody that doesn't have a main melody that goes on top, myself. Now, what I also think is that you could just keep playing this basic background melody as it is (that is, with all the suggested changes), make the song twice as long, and break into a nice melody in the new second half. A high melody might work well on this low-note melody.

The last random bits sound like you mashing the keyboard randomly. If this is supposed to be game music, this makes the music not very unloopable (also it just sounds weird, suggestion is to remove it)!

But... It's short. Really short. This is a main theme, we want some music that builds up, something that has a strong main melody that you can then keep using subtly in some of the other tracks to tie a main theme together!

Also, there's one channel too much again. Mute it and you won't even notice all that much - maybe it has something to do with your instrumentation? Which is nice and unique, but more reminiscent of the Mega Drive than the GB.

It also just plays that (very easily repeatable!) pattern only once. You can easily make this repeat and add in another melody to keep it interesting - see this edit I made (and it could be much longer and building up even more, mind you!).http://davince.tengudev.com/music/others/MainTheme02.mp3

NewTrack02wSuspenseIncredibly short. The notes seem kind of random - try making a cohesive melody and then building around that. If you did... Well, I can't make much sense of it, to be honest.

NewTrackPart0202wDrumsAddedMore interesting. Now repeat the bit you have and build further on it. Try a few more things with your percussion - I think you'll need a bass drum type chip sound in combination with the snare-like chip sound you have right now.

TownSong02Once again, incredibly short. Ask yourself: do I want to listen to this for long while I'm spending time being in town?Also, ALL your song seem to use non-standard timing and rhythms. It's interesting, but at the same time, it's more fitted for those situations that really require it - an action scene, or some dramatic cutscene... When you're in town, what you'll want is something structured more simply, following 3 or 4 beats per measure.

Also, this tune doesn't really sound like it defines where you are to me. It sounds like a "you received this mysterious item" kind of fanfare, perhaps. Think about what feeling and location your town is supposed to give off, and try to base your tune on that - Is the place small and quaint? Busy and bustling? A town near the sea? Or one in the mountains? Is the town occupied by the "bad dudes"?