New engine?

[shortymant]

Hello, some may remember me. Me and a group of friends started a new engine for Pokemon a while back, but it got discontinued due to life complications for all of us. Well, things have slowed down for me and I started a new one a few days ago. I am making this thread to see what the regular users here would think of it (ie; worthless because of <reason> or great because of <reason>, etc.).

I will post very little information about the "inner workings" of the actual engine and game because I like to frequently go back and make it better (as I'm planning on with the maps... again :P), but however, will share what I am aiming for and how certain things will work.

(See attachment or remove spaces from this link : i41.tinypic . com/nlv6kp.png )

Basic map specifications

Spoiler:

==The PokeMapFile (.PMF)==

~Header~
char nVersion ---------------------- Version of the map file
short nHeader ---------------------- 0x31 is decrypted, 0x39 is encrypted
char szName[64] -------------------- Name of the map
unsigned short nHeaderSize --------- Size of header (sizeof(RWorldStruct) + 2)
unsigned long nMapDataSize --------- Size of map data
unsigned long nMapAssetsSize ------- Size of map assets data
unsigned short nChecksum ----------- Checksum of the map
unsigned int nNumOfTiles ----------- Number of tiles total
unsigned int nNumOfLights ---------- Number of lights total
unsigned int nNumOfObjects --------- Number of objects total
unsigned int nNumOfEvents ---------- Number of events total
bool bRains ------------------------ If it allows to rain
bool bNightTime -------------------- If it allows to go to night
bool bDayTime ---------------------- If it allows to go to day time
~End Header~

~Map Assets~
unsigned int nTileID
<unsigned short nImgSize>
<.JPG Data>
~End Map Assets~

~Map Data~
unsigned int nTileID;
int nType;
<<Depends on TileID>>
~End Map Data~


Since it would be a complete ***** to create a new system, all the tiles used in the map, are in the actual map
binary. No big deal since most are less than 1KB. Note that the tiles are actually stripped from the tilesheet and
placed in the map, not the entire tilesheet. Also, there is no encryption for map's. At least, not yet.

Here's some source. ;)

Spoiler:

bool RWorld::Read( const char* szFileName )
{
ZeroMemory( m_pWorldInfo, sizeof(RWorldInfo) );
if( m_pMapData )
{
delete m_pMapData;
m_pMapData = NULL;
}
m_bDestroyed = false;

RFile* pFile = new RFile();

if( !pFile->Open( szFileName, RFOT_READBINARY ) )
{
CLog_Write( "Error opening map file (%s)\n", szFileName );
return false;
}

long nSize = pFile->SetupFileData();
m_pMapData = (void*)malloc( nSize + 1 );
memcpy( m_pMapData, pFile->GetBuffer(), nSize );

//
//Read Map Header
m_pWorldInfo->nVersion = pFile->ReadChar();
m_pWorldInfo->nHeader = pFile->ReadShort();
strcpy( m_pWorldInfo->szName, pFile->ReadString(32) );
m_pWorldInfo->nHeaderSize = pFile->ReadUShort();
m_pWorldInfo->nMapDataSize = pFile->ReadULong();
m_pWorldInfo->nMapAssetSize = pFile->ReadULong();
m_pWorldInfo->nChecksum = pFile->ReadUShort();
m_pWorldInfo->nNumOfTiles = pFile->ReadUInt();
m_pWorldInfo->nNumOfLights = pFile->ReadUShort();
m_pWorldInfo->nNumOfObjects = pFile->ReadUInt();
m_pWorldInfo->nNumOfEvents = pFile->ReadUShort();
m_pWorldInfo->nSizeX = pFile->ReadInt();
m_pWorldInfo->nSizeY = pFile->ReadInt();
m_pWorldInfo->bRains = pFile->ReadChar() == 1 ? true : false;
m_pWorldInfo->bNight = pFile->ReadChar() == 1 ? true : false;
m_pWorldInfo->bDay = pFile->ReadChar() == 1 ? true : false;

unsigned short nMapHdrCurrSize = m_pWorldInfo->nHeaderSize;

if( nMapHdrCurrSize != sizeof(RWorldInfo) || m_pWorldInfo->nChecksum != RCreateMapChecksum( m_pWorldInfo ) )
{
CLog_Write( "Invalid map (%s)\n", szFileName );
return false;
}

pFile->Skip( 10 );

//
//Map Assets
for( unsigned int i = 0; i < m_pWorldInfo->nMapAssetSize; i++ )
{
RWorldAsset* pAsset = new RWorldAsset();

pAsset->nID = pFile->ReadUInt();
pAsset->nSize = pFile->ReadUShort();
pAsset->pBuff = pFile->ReadBlob( nSize );

if( FAILED( D3DXCreateTextureFromFileInMemory( RMain::GetInstance()->GetDXDevice(), &pAsset->pBuff, nSize, &pAsset->pTex ) ) )
CLog_Write( "Error reading asset from map (%s)\n", szFileName );
else
m_Assets.push_back( pAsset );
}

pFile->Skip( 10 );

//
//Map Data
for( unsigned int i = 0; i < m_pWorldInfo->nMapDataSize; i++ )
{
}

return true;
}

Current status:

Spoiler:

-Basic window initialization
-Basic DirectX initialization
-90% of the map parsing done
-60% of the RSprite/RSpriteMgr and RWorld/RWorldMgr classes done

-Able to create a window, parse XML files and load a (very, very) basic map

Basic idea of what will be implemented:

Spoiler:

-Multiplayer (using IOCP for networking, P2P for some and MySQL for database)
-Starting point that consists of logging in, create/customize player and roaming around
-Basic usable state (as in, PokeCenter/Shop, battle, inventory, etc.)
-Fog and lighting enabled for maps
-Quick and easy editing due to XML support

Things I'm still debating on:

Spoiler:

-LUA support
-Single Player

Open Source? Of course. Estimated time to complete the engine would be about another 1 - 3 weeks. However, I still have most of my old Pokemon game sources so the actual game shouldn't take too long.

Any who, thoughts? Suggestions?

 

[Awkward Squirtle]

Are you going to make a map editor? Editing maps via XML would be, as you put it, a complete *****.
Secondly, JPG? Seriously? Also, there's no point storing assets with the map; if you want to make a dozen maps with the same assets, you'll have tons of unnecessary copies.
Third, have fun with what looks like major overuse of pointers. You're creating a file object, then never closing it or freeing its memory. Just make it a standard non-pointer variable.
Finally, maybe it's just me, but I can't stand Hungarian notation. BRB washing my eyes out with bleach.

It looks promising, but trust me, I don't think it will be 'another 1-3 weeks' before it's done.

 

[shortymant]

Are you going to make a map editor? Editing maps via XML would be, as you put it, a complete *****.

Of course there will be a map editor. But I should say that only certain data will be in a XML file, as in the data for Squirtle, NPC dialogs, etc.

Secondly, JPG? Seriously?

It seems to be the favorite in Picolli's graphics folder so it's what I'll be using.

Also, there's no point storing assets with the map; if you want to make a dozen maps with the same assets, you'll have tons of unnecessary copies.

No, it's not the best method, but it works for now - which is what I want.
It's the same with how I'm determining whether a tile is solid, I hate the method I am currently using but I will be switching to a better method before any revision is released. I have a certain way of going at things, and that's to get the base working flawlessly before going back and polishing the mantel.

Third, have fun with what looks like major overuse of pointers. You're creating a file object, then never closing it or freeing its memory. Just make it a standard non-pointer variable.

Again, temporarily. I know when to delete pointers. :P I've had horrible memory leaks in the past when I was creating server emulators, I've learned from my mistakes. :P However, most places already have those, as you can see, I started on my re-write but of course, never finished:

void RWorld::Destroy()
{
    if( m_pMapData )
    {
        delete m_pMapData;
        m_pMapData = NULL;
    }

    if( m_pWorldInfo )
    {
        delete m_pWorldInfo;
        m_pWorldInfo = NULL;
    }

    //vec

    m_bDestroyed = true;
}

Finally, maybe it's just me, but I can't stand Hungarian notation. BRB washing my eyes out with bleach.

It's what I grew accustomed to and many others I used to work with, but not much to be said about this since it's merely opinion.

It looks promising, but trust me, I don't think it will be 'another 1-3 weeks' before it's done.

1-3 for the engine in a usable state :) 1-2 is kind of pushing it though.

 

[Dragonite Ernston]

Any chance this will support 3D graphics?

*runs*

 

[TeRex]

What language will you be making this in? I think this is pointless because with poccil's kit out there who will use this?

 

[Deadrocks]

Is there like a laymans version of your first post? :D

 

[IceGod64]

This seems like it'll be something to look into for sure.
I don't really have much to say on it atm though, I'm not a programmer...

 

[shortymant]

@Akward Squirtle, you paragraph on memory allocations just made me think of how STL containers (such as vector) cleared objects when calling erase or clear. I have to thank you on that, I honestly completely forgot that they just delete the pointer, not the actual object, thus never being free'd and thus, again, causing a memory leak. Thank you. :) (Well, it does call the deconstructor, but the actual object is still floating their. :p)

Any chance this will support 3D graphics?

*runs*

No 3D support whatsoever. Sorry. :(

What language will you be making this in? I think this is pointless because with poccil's kit out there who will use this?

C++ is what it's being coded in, using DirectX as it's graphics API.

Is there like a laymans version of your first post? :D

I may post up binary's (compiled EXE's) during it's initial testing, but the earliest would be probably 7 days from now as I'm visiting my parents soon for Thanksgiving.

This seems like it'll be something to look into for sure.
I don't really have much to say on it atm though, I'm not a programmer...

You don't need any knowledge of programming to give your opinion, it's merely just a little discussion thread to see if something like this could prove useful here.

I'm tied between the middle of the rope here. Using a language such as C++ and a graphics API such as DirectX could give endless opportunities (expansions, additions, etc.) to fan made Pokemon games. However, I know at the same time not many people can understand a language such as C++, or even a scripting language such as LUA, to be able to make modifications themselves.

Whether it proves useless here or not, I'll keep coding it until it's finished. But, if my work can't be used, then there is no point in wasting time and setting up areas to help users, setting up the finished product, etc..

 

[TeRex]

I'm tied between the middle of the rope here. Using a language such as C++ and a graphics API such as DirectX could give endless opportunities (expansions, additions, etc.) to fan made Pokemon games. However, I know at the same time not many people can understand a language such as C++, or even a scripting language such as LUA, to be able to make modifications themselves.

My thoughts Exactly, you seem to be making a professional type game engine for pokemon, Not only is this not the smartest idea but it just seems pointless. I don't mean to be the man who kills dreams, you have the right to ignore me by all means. however like you pointed out this is only a framework and i'm almost positive you wont be spending years coding a engine like RMXP that has one button click but behind the scenes all the proper code it add into a script somewhere. Most users here are kids between 12 - 20 alot of them cannot program/script in RGSS(Ruby) let alone even figure out RMXP, and this engine would expect them to know C++ which is a very complicated language 10x harder than Lua or even javascript(Which is a web programming language)But its very simple..... My point is that this is a good learning project for you but if your just doing this for fun I highly advise against it...

 

[The 100 Mega Shock]

If only one person takes the engine and uses it to make a game that performs better and is easier to work with than RPG Maker and can theoretically be ported to other computer systems (or further), I wouldn't call it a waste at all. There's always going to be somebody out there with the patience to learn how to program for an engine, the fact that lots of people will dive into ASM programming for things like GBA Pokémon games, Super Mario World or the Mega Drive Sonic hacks, or amateurs developing for more modern systems like the Unreal and Crytek engines should be a sign of that.

Also last I checked all the Essentials resources were stored as PNG and for good reason - it gives the best trade between image quality while still supporting full transparency and alpha blending effects.

 

[IceGod64]

If only one person takes the engine and uses it to make a game that performs better and is easier to work with than RPG Maker and can theoretically be ported to other computer systems (or further), I wouldn't call it a waste at all. There's always going to be somebody out there with the patience to learn how to program for an engine, the fact that lots of people will dive into ASM programming for things like GBA Pokémon games, Super Mario World or the Mega Drive Sonic hacks, or amateurs developing for more modern systems like the Unreal and Crytek engines should be a sign of that.

Also last I checked all the Essentials resources were stored as PNG and for good reason - it gives the best trade between image quality while still supporting full transparency and alpha blending effects.

If you want my opinion, this person said it.

Even if it doesn't end up getting all that used, it is a great idea and it could clean up a lot of the issues that RPG Maker XP has, since programming is far more flexible than scripting. Also, it would give users more options than just essentials this and essentials that. Options are a nice thing to have no matter how you look at it.

Also, I agree that PNG would be WAY better to use - it's not as compressed as JPG, but it has more power behind it.

There's my opinion. Though I've already got a project going on essentials, I always find myself toying with and new relevant software I come across, so you can be sure I'll at least try it myself.