[jeffd1830]

Hi! I'm new to the forum, and I have a new project that a friend and I have been working on for a few weeks now.

We are using 8-bit retro style with restrictions similar to the NES, and drawing our inspiration from the classics. Our target platforms are iOS and Android. We have been working on asset creation tools, and have a good tile editor and a map editor completed now. Here is a peek at our overworld map which is rendered by the level editor:



Oh, and it is going to be a cooperative multiplayer game. :)

Is this forum still alive? Can this perhaps breathe some life into it?

[BadMrBox]

Hello JeffD. Nice to see that someone besides than me like the Nes style. I was doing a minirpg with nes restrictions for a contest we held a few years ago, a game I intended to finish but that has been lost in limbo.

How will the cooperative aspect work?
_________________

[Adam]

Yes, that looks cool. Post more plox.
_________________
https://numbatlogic.com

[jeffd1830]

Here are some tiles for natural areas (i.e., towns)



The stone/brick stacks are temporary - they are just there to have something to cast a shadow. I have a set of stone walls finished as well which I will show in a subsequent post. I just haven't screenshot them yet.

In a real town, both sets of trees probably wouldn't be enabled (especially not with the smooth-edged sand) or else there won't be enough tile space for the buidings themselves.

[jeffd1830]

Here are the stone wall tiles, as well as some furniture tiles and stairs that I made for inside of homes and other locations, as well as vendor countertops for shops. When these tiles are used inside a building, the props will be over an interior floor color rather than over the grass color. I still haven't done the tiles for the actual building interior walls, so the city stone walls are acting as a stand-in.



We haven't spent the time to fully utilize it yet, but in our tile format we've included something we call "super mode" which gives an additional 2bpp worth of intensity data without altering the core color data of each tile. The following shot is the same scene with super mode turned on:

[jeffd1830]

Would anyone here be interested in porting the hqx filters to PHP (using GD) for us? We are using PHP for our web-based asset creation and management tools, and I'd like them to be able to generate scaled high-res versions of all the graphics automatically so we don't have to do it by hand.

Someone has already converted these into Javascript, which may be an easier starting point. See: http://phoboslab.org/log/2010/12/hqx-scaling-in-javascript

Supporting alpha transparency would be a necessity. Let me know if you're interested.

[DeveloperX]

How much are you paying for the PHP implementation? I can do the job, I just don't work for free.
_________________
Principal Software Architect
Rambling Indie Games, LLC

See my professional portfolio

[jeffd1830]

Richard, I'll talk to my cohort in this project and see if we can drum up some funds for it. :)

Meanwhile, if anyone is interested in checking it out, here's our first clipping test! This is cut-and-pasted out of our level editor, and is not using the production code for our game engine. NES limitations mean we have the ability to either not paint an entire 8x8 sprite or set its priority bit so it gets drawn in the background ("under" the background tiles.)

http://legendsoffairwind.com/cliptest.php

The characters in the game will actually only be 16x16 (so sprite numbers "0" through "3" in the demo.) You may notice some oddities with the "4" through "7" sprites in this demo since we didn't define the block heights with characters that tall in mind.

[DeveloperX]

Very cool demo.

Alright, let me know if you're interested in hiring me for the job. You can reach me best via Skype: bbastudios
_________________
Principal Software Architect
Rambling Indie Games, LLC

See my professional portfolio

[jeffd1830]

[DeveloperX]

Thanks Jeff, for the kind words, and for the job. :)
I had fun, and learned quite a bit in the process.

Let me know if you need anything else done, and please spread the word to anyone else you know, that I am available for hire for pretty much any task in game development. For tasks that are outside my skill set, I may be able to connect them with someone who can get the job done.
_________________
Principal Software Architect
Rambling Indie Games, LLC

See my professional portfolio

[jeffd1830]

Hi! Just wanted to post a quick progress update for anyone following along.

It's been a while. I was sick with a cold and I also took a little break from coding to actually play some games.

We got the HQX stuff integrated into our level editor and asset generator tools. The system is now fully flexible and generates all of the following formats when requested:

1x normal, 1x super,
hq2x normal, hq2x super,
hq3x normal, hq3x super,
hq4x normal, hq4x super.
It can also generate arbitrary scaled resources using nearest-neighbor scaling, but this isn't an output format used in the actual game - it is useful in the web-based level editor, however.

If using hqx, we will choose the best-fit hqx textures for the device screen. If the screen is significantly larger we'll use 4x and then resample those up. If hqx is disabled, we just use the 1x textures and scale them up using nearest neighbor on the client. That's the plan, at least.

I got clipping rules and physics rules fully added to the level editor. They can be specified in the block type editor, and overridden for individual map blocks as needed.

I wrote the beginnings of the engine in MOAI/Lua. There is a prune function that eliminates any assets not depended on by any level currently downloaded and there is a fill function that downloads any missing assets from our server. The idea will be to package levels(areas - we actually call the domains internally) in a set of zip files. One zip file contains all the shared level data and common assets and another zip file contains all the assets needed for that level in the appropriate graphics format. Assets go into a common store, so if the same block (with the same palette) is used in multiple levels, it overwrites the existing block and doesn't take more space.

I also made a texture loader that takes the currently active domain and loads every unique block texture needed into a texture list.

I also made a rudimentary music engine, which is nothing more than a nice way to call the Untz sound routines MOAI already provides. My engine divides sound up into three separate ideas. Background, foreground, and effects. Background music is looped and may be paused or resumed. Foreground music plays once, pausing the background music automatically, and resuming the background music after the foreground music has completed. (think the "You got an item!" jingle in Zelda) There is both a blocking and non-blocking way to play foreground music. Sound effects play over the top of the music. I made it so only one sound effect can play at a time -the most recently triggered one cuts off any that are already playing. It would have been far too difficult (and expensive in terms of processing power) to emulate the Ricoh chip's limitations exactly, so unfortunately music and sound effects will both have all their channels audible at once. (on a NES, usually the noise or square wave channels of the music would go mute while a sound effect was playing, since there were only 4 channels available in the system - two square waves, one triangle wave, and one noise generator, so you'd normally hear the bass line or drums still playing but the melody would cut out during the sound effect.)

I also made an engine test where a bunch of blocks get tiled onto the screen and smoothly scroll around while music is playing. I'm reading touch input and if a certain area is touched I play a sound effect.

We are composing our music and SFX in a chiptune tracker (FamiTracker) and will be converting it to ogg format for use on the devices. And if I didn't mention it above, all the graphics are png files with alpha transparency.

Our level format ended up being quite complex to understand and generate, but I think it's really efficient in terms of storage and processing required to interpret it.

The level editor itself uses a higher level format which I implemented using MySQL, but once we publish the level, it gets massaged into a format more suitable for an 8-bit console.

My maps are basically an array of width by height with each location containing a conceptual "stack of plates." A flat map would only have one plate in each grid location. A map using overlay techniques or over-under areas (i.e., a bridge you can walk over but also walk underneath), or areas that are revealed/hidden based on triggers (i.e., the inside of a building whose roof cuts away when you step into it) are expressed using different Z layers. So you can think of this as a regular array for X and Y with a sparse array for Z.

I end up with the following chunks for each domain:

map (this has a header which specifies the width, and then a list of 16 bit "plate" numbers, row by row with each row being the width which was given in the header)

plates (a plate has a cell, a z coordinate, a script, a context, and a reference to the next plate in the same (x,y) location)

cells (a cell has a palette offset, four chr ids, entry and exit rules and clipping rules. in other words, a cell is a visual and physical description of a 16x16 pixel "block" on the map)

chr (defines which tile id from our master tile list corresponds to each of the 256 available chr ids)

palettes (each palette is a set of three colors chosen from the master system palette; there can only be four background palettes active at once, so this is a master list for this level whereas the palette offset mentioned above is just a number 0 through 3)

blocks (this is a list of all the potential palette id and tile number combinations that exist in this domain. the texture engine uses this to preload all the appropriate graphics out of the assets folder)

There are a few other chunks but they are far less interesting. One called settings holds some overall info about the domain. One called revisions will help the auto-updater know which version of each asset is expected by this copy of the level data. One called idents translates script and context names (global) into a condensed numeric form which is used locally in the definition of plates.

I'm still missing chunks to define sprites (overlay objects, npc's, etc.) but you can expect them to use a similar technique of organizing their graphics, to utilize data from the same palette chunk, and to also have scripts and contexts. i.e., blocks and sprites will "speak the same language" in the system.

If anyone actually followed this and felt like they understood, kudos to you ;)

To sum up, we're excited! Only a little more glue work and the engine should be displaying the actual level which we designed in our level editor. We've already demonstrated our clipping algorithm in the web-based editor, so I just need to port that code over to the engine and we should have clipping.

Movement rules are going to be a painful thing to get right. We decided to do half-block movement like Dragon Quest V. When I say tile I mean 8x8 pixel. When I say block I mean 16x16. So, your footprint is more than one tile, but you can straddle two blocks. In order to move in a given direction, the movement rules on all the blocks your footprint touches will have to agree that you're allowed to move that way and also agree that movement is possible between themselves. (i.e., if there was a vertical fence existing in between two tiles, and you were standing directly south of it, walking north would seem possible since it's possible to walk north on the west side of the fence and also to walk north on the east side of the fence, but if we actually let you walk north, because your footprint is two tiles wide, the fence would be cutting down the middle of your body. Not good. So, we additionally have to check that the two target tiles are allowed to walk into each other.)

Sorry for the lack of pics this post.

[DeveloperX]

That is a very interesting level format I must say. I'm looking forward to seeing more on your project. Sounds like it is moving along at a decent pace. Keep up the good work. :)
_________________
Principal Software Architect
Rambling Indie Games, LLC

See my professional portfolio

[jeffd1830]

This is a reply to the question much earlier by BadMrBox which I inadvertently neglected to answer.

So, how will the cooperative mode work on Legends of Fairwind?

We have quite a system worked out. I will explain it from a player's perspective first, without going into all the implementation details.

You'll be able to add friends by username and hopefully add "networks" like groups, regions (i.e., everyone in my state.)

When you enter a town with a tavern, you can recruit party members. Someone who has purchased a horse and wagon will be a party leader to which other players can join.

Once a party has been formed, whoever sets out in the wagon first gets control of a party. So you won't play simultaneously, but you will be "borrowing" the other person's character to assist you in combat. You will have limited ability to control the other characters - basically you can make combat decisions for them and can expend items they designated as in their pouch (i.e., combat usable), but cannot pillage their private inventory.

When you re-enter an area like a town, you will part ways from the wagon temporarily. This allows players to explore individually and allows another player to take a turn controlling the wagon if they decide to leave first.

When you come back to the game after another player has borrowed you, you will get a recap of the events that occurred, and what gains you have made in terms of exp and gold, etc., and how you got to where you are now on the map. It is possible to adventure solo as well (and may be required in certain areas, i.e. places the wagon cannot travel to), but some areas may require a party.

Now, from a technical point of view, there is a lot more going on behind the scenes than this. For one, we never have a point where you aren't allowed to play. When someone else is borrowing your character, you can still play solo, and the wagon will be indicated to be at the town or location from whence they departed. You basically can do anything but you won't be allowed to rejoin the wagon unless you leave yourself in equal or better condition than when they received the "copy of you" that went with them. This is handled in various story ways, like the wagon leader telling you: "Go rest at the inn, and we will leave in the morning." (translation: Your HP or MP are lower than they were when the copy of you left, so you need to fill them up that way there's no logical problem in the timeline.)

There are a lot of inventory issues and sync issues we have worked out for this, but from a player's point of view it should seem pretty smooth and won't feel too different from a traditional JRPG. When you return to the wagon to continue traveling, the other player's progress will be presented in a way that seems kind of like a cut-scene. When there is any storytelling that is essential for each player to experience, we can find a clever way to divide the party up so that each person has to play it separately.

I based my idea of having a wagon off of Dragon Quest VIII for PS2. In that game, the wagon is more of a storytelling device and also contains an "alchemy pot" which is interesting (and we won't have anything like that, or have no plans for such yet.) Interestingly though, I went back and played DQIII and IV for NES since then and realized that the wagon originated in those games and was used more closely for the purpose we are using it for than the one in DQ8. In those games, it gives you the ability to have more people in your party (more than 3) and specifically to recruit monsters into your party. So, I feel like our use of the wagon is along the right lines of thinking to match the JRPG mentality.

We will also have more wagons and horses to choose from which will provide benefits to the party, so it is an item you can upgrade as you go along rather than just something you get once.

I hope this was a clear enough answer! Let me know if you have any questions.

[tcaudilllg]

Nice looking game.

The perceptual differences between the low bpp and high bpp scenes would be something a cognitive scientist could take an interest in.