Hello Everybody,
I'm working on a new game about a girl named Clarine and her versatile mech which she is able to ride.
I just began working on it, and I thought that maybe having a thread to post progress to, would be an incentive to keep it going.
Rom for the project so far:
http://www.zlashstudios.com/files/clarine_test.7z
I'm also developing at the same time an small tool for the sprites' animations. I want to release it as soon as its a little bit more mature.
Looks like a good start!
I like the walking look of the robot, very cool!
Really nice animation!
But as the robot uses all 8 sprites at certain lines, I wonder how severe the flickering may become if there are to be other objects such as enemies (unless it's a space invader style game where you only shoot enemies that are hovering above you). Maybe the game will switch to a smaller character in "battle stages"?
Very nice. Two things that I noticed:
1) I like how you built Clarine's meta-sprite. By using disjoint PPU sprites, you increased her palette.
2) Your moving mech has really nice motion. But I noticed that you use more than 50% of the PPU sprites to draw it (at least, it seems that way in FCEUX's hex viewer on CPU page $02). That seems like a lot of sprites, given that the hardware only gives us 64.
I can imagine in my head a neat "thud" sound as the mech's foot touches the ground while walking.
Excellent work! I look forward to watching your game evolve.
Do you have a plot yet? Why does Clarine need a mech? What is she going to accomplish?
2. It actually uses only 21 sprites (still a lot though), as shown in the VRAM viewer of No$Nes:
The sprites crossed-out by a red diagonal lines are actually not shown (with large y-coordinates) so they could be used for something else in the real product.
(I know that No$ is not accurate (and I know
how inaccurate it can be), but I find many of its debugging features very handy, especially the sprite viewer. It helped me a lot in fixing say, animation glitches like erratically reading from beyond a LUT for the animation frames.)
The game is mainly an excuse to test and put to use the animation tool and library I'm making, so it will probably end as an small and short demo (And not necessarily fun).
Also, I'm not thinking about adding enemies, it will be focused mainly on exploration of the world by Clarine (maybe also to find different things scattered around the place?) , and discovering the different forms the mech can take to reach diferent parts of the world (i.e: Flying mode, submarine, drill, etc)
I know that the 8 sprites per scanline limit will become soon a PITA™, but I'm consciously ignoring it until it becomes a real problem in my game, so I can focus on going on.
clueless wrote:
(at least, it seems that way in FCEUX's hex viewer on CPU page $02).
I'm building the sprites' data at $500
Cool to see another homebrew in progress
Sorry for the slightly off-topic question, but why do so many people post their projects in a 7zip format? Why not use the more universal/common .zip? (Isn't it more common?) I haven't bothered to install some of these games because of that. I know it wouldn't be hard for me to install 7zip, but I'm lazy like that.
cartlemmy wrote:
Sorry for the slightly off-topic question, but why do so many people post their projects in a 7zip format?
I guess, it is because 7zip is better, free, and the format also supported by other popular modern compression tools (WinZip, WinRar).
Shiru wrote:
...it is because 7zip is better.
But sometimes 'better' doesn't matter when it doesn't have the most reach. If more people can access a .zip file than a .7z without downloading a new extraction tool then why not use .zip? Is using the 'best' compression tool worth alienating potential users of your software? Perhaps 7zip is more common that I think, in that case I my point is moot. Sorry for the rant, it is just something that befuddles me.
I just think that the techy community at large knows of 7zip so its a bit expected that someone would have it on a forum like this. I was actually wondering the same thing a few days ago and thats about all I could come up with.
Shiru wrote:
cartlemmy wrote:
Sorry for the slightly off-topic question, but why do so many people post their projects in a 7zip format?
I guess, it is because 7zip is better, free, and the format also supported by other popular modern compression tools (WinZip, WinRar).
Better than what? It surely packs better but that hardly matters for NES ROMs. Windows and OS X (I guess most Linux distros too?) handle ZIP by default, not so with 7zip. I downloaded op's previous game, Nanaca Crash for OS X some time ago, but I couldn't bother finding a tool to extract it, so I simply deleted it.
Long story short, I agree with cartlemmy, ZIP is the better choice in most cases.
Is 'better' was the only word in my post?
Yes, if you want to release something for really wide and not very techy auditory, you'd better to use zip to avoid questions 'what is 7zip' etc. Don't see any major problem for other cases, 7zip is around here since 1999, and now it is supported widely enough and available in many OSes. Even some modern emulators has built-in support, like FCEUX. I don't know for other countries and people, but for me and most of my fellows it is the only installed compression tool.
Since I didn't have WinRar on my new laptop yet, and didn't know it supported this, I had to find a tool to do it. Three failed to work, and one finally did but I had to find the right app of the 3 it gave me. It compressed nicely, at only 2K, but it still isn't that big and was a HUGE hassle without having winrar on my system. ZIP is good enough and more common, I'd suggest using it, but do however you wish.
Thanks for the input, I was just making sure there wasn't anything I was missing. I feel informed now
A few years ago I made 7-Zip my default archive program, and considering that it's free, while WinRar and WinZip are not, I'd say that was a good choice. It doesn't compress to RAR, but it does compress to both ZIP and 7Z, and decompresses anything I've tried so far.
7-zip is a very, very good choice. As for ZIP, as far as I know the Windows internal feature is very, very crappy (the XP one at least) and it couldn't handle all ZIP files well, so you probably end up installing 7-zip or those WinXXX anyway.
cartlemmy wrote:
Shiru wrote:
...it is because 7zip is better.
But sometimes 'better' doesn't matter when it doesn't have the most reach. If more people can access a .zip file than a .7z without downloading a new extraction tool then why not use .zip? Is using the 'best' compression tool worth alienating potential users of your software? Perhaps 7zip is more common that I think, in that case I my point is moot. Sorry for the rant, it is just something that befuddles me.
Think of it this way, it could be a SIT, LHA or GZ file. I think 7z is overrated especially for tiny data archives, but it's become the defacto standard for ROM distribution, so you may want to just break down and install the decompression tool.
Xious wrote:
...but it's become the defacto standard for ROM distribution.
That is a good reason to install it, and exactly the kind of input I was look for. I will keep that in mind when I post stuff up. I think I will post my stuff in .7z, .zip, and heck even my own favorite .tar.gz then let people choose which to download
And sorry for hijacking this thread, I brok down and installed 7z (which was quick and painless in Ubuntu) so I could try the rom. It's pretty darn cool, I really like the segmented animation.
A WINRAR IS YOU? No, a 7-Zip is you.*
cartlemmy wrote:
If more people can access a .zip file than a .7z without downloading a new extraction tool then why not use .zip?
Zip always compresses each file individually, while 7z is more efficient when files are similar. If you have five files, all of which are nearly identical, then 7z can take advantage of redundancy between files. For example, NTSC and PAL versions of a game will usually differ little.
And think about it this way: more people can access a
retraux PC game for Windows (e.g. Eversion, La-Mulana, Cave Story) using only software that comes with a PC than an NES game. More people have Windows, Mac OS X + Wine, or Linux + Wine than have Windows + an NES emulator, Mac OS X + an NES emulator, or Linux + an NES emulator. This is especially true considering that Fedora ships Wine but refuses to ship any NES emulators out of fear of
Nintendo v. Red Hat.
As for .gz, most GUI tools that can handle .zip can handle .gz. Surely every tool on Mac OS X, Ubuntu, and everything not made by Microsoft can.
* See this ED article for context. Offtopic: does anyone sell the oversized orange newsboy cap like the one Tommy Himi wears?
I'm really sorry about the 7z issue but I use it for all my packaging needs as its free, good, and has a non bloated tool that can open almost anything I throw at it.
And because I like it, I will keep on using it for the following uploads.
And now, another update:
Now the player code can also animate the tile indexes of the sprites, so now nicer animations can be built.
I updated the walk cycle animation to reflect the new changes.
http://www.zlashstudios.com/files/clarine_test_2.7z
The mech looks a bit odd when told to walk and and forth for short distances.
That is, make it walk to the right 8 pixels. Then push left for 8 pixels. The screen will scroll back to the left a little, but the mech's leg motion will still be as if its walking to the right.
The walking does indeed look better, but the legs look really weird when it first gets up.
As the animation is only played forwards, it should not be able to move backwards (when you move to the left, the forward animation continues to play). That's why it looks that its doing some kind of moonwalk when you continuously move it to the left. That problem should not exist when I correctly play the animation backwards when walking to the left, but playing the animation backwards is not currently supported.
tokumaru wrote:
The walking does indeed look better, but the legs look really weird when it first gets up.
Yes, I should have added that as I changed the tile data layout I broke the standing up animation, and because the animation format changed I have to do the stand-up animation again, so I didn't bothered to fix it.
I'm not sure whether I like the new version. While the cockpit is now animated, the turning looks a bit too choppy in action. Personally I prefer the non-animated one in the previous version. Maybe if 1. there are more frames to the animation (sacrificing more CHR space), or 2. have the mecha move/animate faster, or 3. have the cockpit bog up and down by one or two pixels during the animation it could look really nice.
I also think that the cockpit should move up+down a few pixels while the mech moves. Seems more realistic.
You mentioned that you're developing an animation tool.
What does it output? Asm code, binary data or something in-between?
What kind of data does it hold in memory (sprite lists, connection points, hit-boxes, etc... )?
What platform does it run on (pc, mac, bsd, linux, solaris)?
What language did you implement it in?
Thanks for your opinions! I will try to make it more natural as the game development progresses.
The tool outputs a binary file that holds timestamps and interpolation values for the keyframes of the animation.
The structure in RAM which hold the current values for each sprite uses 2 bytes + 15 bytes per sprite used on the animation.
The ROM data as you might guess, its a lot bigger. For example the stand-up animation uses 259 bytes and the walking cycle needs 429 bytes.
Im doing the program in C++ using GTK+, so it should be easily compiled for every platform where GTK+ is available (I tried it on Windows and Fedora)
But its still very fragile, and a lot of the GUI options are not working, so I want to wait its just a little bit more ready before releasing it.
Screenies! We (or at least, I) want screen shots! Even to a work in progress.
Does your tool handle
Spherical Linear Interpolation or anything that oscilates along the path of a curve?
I'm coming into this thread pretty late so this is probably way off topic (trying to comb through and catch up on all the stuff I haven't had time to read in forever).
Anyway, I just wanted to say I tried out the ROM and LOVE the animation! That is solid as hell! Is the mech going to be able to jump? I guess I should ask what genre the game will end up being--I'm guessing platformer?
For now, it only uses linear interpolation between keyframes.
Screenshot:
About the genre, I'm still not sure about what it will end up being.
