[btotherizzo]

ok, let me start with a slight rant. i know i'm new and i'll get flamed but it has to be said. why are the engines out there using 640x480 screensizes and 256-color palettes? does anyone actually still own a monitor whose max resolution is 640x480? if you do please go to best buy tonight and for $100 you can get a 1024x768 if not better. i bought 2 19" hi-def widescreens from office depot a month ago for under $500. anyways why do so many engines start at the bottom of the graphics ladder instead of pushing the envelope of what technology is available. just a question i'd like to pose.

ok enough with my rant, here's my real subject matter. my engine idea(s) and i'd like everyones opinions on them. first off there are two styles: a side view (like mario bros) action rpg that would combine elements of a fighting game (have moves that can be pulled off) with elements of a puzzle solving rpg (each board will have many "exits" each leading to different boards and based on levels, char. stats and quests completed you can't reach certain exits). the second style would be standard overhead ... not really my favorite choice but it's still there.

whichever engine is chosen, the gameplay will be an mmorpg so everyone can play together. also the game will be tied into a web interface that will allow people to purchase armor or weapons, etc. and update their character online. also because its an online engine, i'd like add a server program that people can create and broadcast their own maps for others to play on.

now for graphics, here's where your opinions matter most because lets face it, without good graphics i believe you're just wasting your time. two graphic ideas: the first, everything is a vector graphic (more than likely svg's since they're open source). vectors have pros and cons; pro - zoomable w/o loss of quality, would allow for cool zoom-ins on critical hits etc. con - because vectors aren't pixel based complex gradients, shadowing or handpainted styles aren't really doable, you're limited to a very cartoony cel shaded look which is cool just limited. because of limits i'd proly add some filters to the engine like motion blurs for action and depth of field blurs for the paralaxing layers. these filters would be applied at runtime. the second graphics idea would use something similar to the "icl" (icon library) file format, a file that stores other files in it. this other idea is pixel based and would have many versions of the same sprite based on color depth and image size, so the user could customize the game to his monitors max resolution. does he have a better graphics card, then use the 256x256 spriteset with the rgba (32bit) color palette; if you don't then use the 24x24 tileset with 16 colors (lame but sometimes neccesary). the pixel based format will probably use png's since they're open source. this will allow complex gradients and shadowing, but no zooming (i don't like when pixels zoom).

both graphics engines will be hi-def compatible at it's max resolutions. also because there will be paralaxing layers and some peoples video cards need to be updated and can't handle many paralaxing layers, certain layers can be toggled on or off. on the side scroller engine (again, my personal favorite) there will be a weather layer (fog, snow, rain, etc), foreground layer, main walking layer, a background, and a stationary background. that's 6 layers that can be toggled for performance sake.

ok let me know what you guys think and because this will be a large undertaking i'd like some helpers in the near future.

[Ninkazu]

Let me ask you this first - do you know how to program? Have you ever made a game?

If the answers are both no or the second is yes but only with an RPG maker, then you need to rethink your project lest you become seriously disappointed with yourself.

[btotherizzo]

i have a book on programming games for linux and i've gone through all the exercises, and have some basic direct x programming knowlege. if i use the vectors idea, i was actually thinking of using flash, the multiplayer stuff would be hard because flash doesn't act as fast to xml sockets as other programming languages say c++. right now its alot of theory and psuedocode, and i'm trying to get peoples opinions.

[Nodtveidt]

[Rainer Deyke]

About screen modes: I have used mostly 640x480@32bpp in the past. The (relatively) low resolution makes art production easier and keeps memory usage down. I don't believe that low-res art necessarily looks better than competently-done high-res art, but high-res art requires more work, and eventually you reach a point of diminishing returns. Most games with high-res art use shortcuts such as photos, cartoon style art, scanned art, or the ultimate shortcut, 3D. Because of this, low-res games often look better than high-res games. I try to avoid these shortcuts in favor of a hand-pixeled art style. Pixel art is beautiful, but it is prohibitively expensive to produce at high resolutions.

8bpp, on the other hand, is just crazy. I use 32bpp so that I never have to worry about palettes. It's quite likely that I could be able to fit my games in an 8bpp palette, but why bother? 32bpp art isn't any harder to produce than 8bpp art. There is no rule that you have to use any more colors in 32bpp art than in 8bpp art.

In three of my current game projects I have gone up to 800x600x32bpp (with support for 1600x1200x32bpp using scale2x). This is mostly to keep the on-screen text smooth. Low-res text tends to be somewhere in the range from ugly to unreadable.

About your game project(s): You're dreaming. These are the types of projects that only beginners attempt, because experienced programmers know better. Start small, write some sort of mini-game, finish it completely, and then come back.

[BadMrBox]

[RedSlash]

[Bjorn]

Well I'm also skeptic, but I'd just suggest to start with the fun stuff. After all, while you might not finish your first incarnation, at least you'll have had fun working on it. Also, I'd choose something you can show off to your friends or on this board. For me this would be the layered SVG based map engine. For rendering SVG using OpenGL there is a library called Amanith. It also has Python bindings, which should make prototyping that much easier than directly starting off in C/C++.

[btotherizzo]

see im still not sure which route to go and that's why i was asking ...
anyways let me clear up a couple of things.
the "decentralized server" concept was interpreted incorrectly. every decentralized server model has a central server involved in some way or another, albeit invisibly at times. i think my model will have a central server that other servers will log into so it can keep track. these decentralized servers will be like complete other worlds in the universe.
also on verctors, yes you can make them complex but it increases the filesize ... a 256x256 32-bit png can be under 20k, while attempting to make the same look purely vectorized with lots of itty-bitty shapes can weigh in at 50k (again depending on complexity) ... this is why most vector art for flash games, that actully use vector art and not a bitmap, is usually 4 colors and 4 colors alone.
on the pixel-based idea, yes i would probably start with the highest resolution sprite and render downward, that would make things easier. having multiple versions of the same sprite is primarily so that the user can choose how he wants the game to look based on his available hardware. sort of like how a windows icon has many versions of the same icon in a single file.

[RedSlash]

[Bjorn]

[RedSlash]

[btotherizzo]

i was talking more about a hand painted watercolor kinda look ... very hard to achieve with vectors (or needing lots and lots of them) as opposed to say using "painter" which is much easier and would probably be a smaller filesize.

anyways i have given some more thought to the overall project and jotted down some notes:
- vector vs. pixels (haven't yet decided)
- overhead style (i know i was talking side-scroller, maybe i'll come back to that)
- secret of mana-ish battle system that will blend a fighter game that has moves and a limit break system
- will have a physics engine where you can "push" enemies a cretain distance with certain attacks as they can do the same to you
- everything will act as a sprite on the battlefield, and will react when enemies (or your guy) is knocked into them, like trees, piles of barrels, boarded up mine entrances, etc.
- multiplayer ... so watch your back cause it's gonna be a friendly fire free for all.

more details to come ...

[RedSlash]

[tcaudilllg]

I'm starting to like this idea. In particular, I've had a few gameplay ideas along the lines you mentioned. I'd like to see an engine that could make those ideas real.