Elysian Shadows

Hi guys, Its been a while since I last logged in. I hope everybody is great.
Recently I have been developing an android game. The game is much like Blizzard's Hearthstone (Turn based Card game thingy with my own RPG style element). Also I have been pretty rusty in game engine design. So far I have been able to decouple almost every component of my game, But It looks like its going out of hand now.
I just need some expert advice on my game design. (I am not a pro in game design, I just learn from here and there).

So I have following setup:--

GameWorld----// the main game world spawns a thread for update render cycle
---------RenderableManager----// manages all my renderable objects like images etc.
---------TouchManager------//Manages my touch events
---------EventManager-----//Manages various events like casting a spells or adding a renderable object to rendermanager

Also have
Player---------game player
-------propertyManager-----// for managing various properties of a player.. like making a player control by CPU
-------SpellManager-----// Manages all spells of a player
-------ItemManager-----//Manages all items of a given player

//------All Items can have various stats
-----StatsManager---// To manage various stats objects of an item.
/* currently not using a DB for storing item spell , player data so using Static pool of object */
----SpellPool--
----ObjectPool----
-----ItemPool---
------SpellSetPool----
etc.
So what Should do Next? Should I create a small DB for all my Object and make an interface for my GameWorld to interact with it? Or Should I just uses thos static objects? Or should I consider designing a game Editor thingy? (of Which I have no idea). Thanks in advance. cheers.

Falco !!!!!

hellknight wrote:Falco !!!!!

Well, fuck. I've been called out... now I have to respond...

Your post is really too open-ended for me to offer particularly useful advice. I am not sure what your ambitions for your project are or what the scope of your grand, evil scheme is. This makes it hard for me to conceptualize a context and direction to push you towards...

Are you able to physically render terrain, levels, or maps yet? Can you see the world that your game takes place in? If so, how are you representing and modifying this map? Do you have some tool to generate it for you? Are you hardcoding it? Are you manually modifying text files?

It is going to be very hard to develop an engine (or a good game) without tools to generate data for the engine. You don't necessarily need to roll your own editor or toolkit (you can use another tool and write your own map exporter plugin or just read their map format into the engine), but you should probably go ahead and figure out which tools you are going to use to create your worlds (and ultimately game).

And I would never recommend actually using a database for a game. It's a huge dependency and slower lookup times for what exactly? You can say you're using a cute little database? Just use a std::map or associative container to associate an item/spell name with an object or data structure. It's faster, and it's simpler.

edit: Just realized you're probably using Java. Use a hashtable, not a std::map.

Falco Girgis wrote: And I would never recommend actually using a database for a game. It's a huge dependency and slower lookup times for what exactly? You can say you're using a cute little database? Just use a std::map or associative container to associate an item/spell name with an object or data structure. It's faster, and it's simpler.

For most indie projects, yes. I highly doubt any modern commercial RPG is NOT using a database though. It really depends on the size of the project. When you have millions of rows of data to search through it's going to be a hell of a lot faster to find the row you need in a properly indexed database than it is in any other method of storage I know of.

For this reason, I wouldn't dissuade someone from learning to use a database to store data, even for a small project. The knowledge will inevitably be useful in the future.

dandymcgee wrote:When you have millions of rows of data to search through it's going to be a hell of a lot faster to find the row you need in a properly indexed database than it is in any other method of storage I know of.

You entire argument is using database terms. No shit using a database would be faster to search for random "rows." You have the freedom to structure your data however the hell you like. If you are indexing your items in a preset fashion, you can sure as hell create something that is 10x faster than a database search with something like a hash-map.

DBs are usually reserved for online games like MMOs to manage the sheer volumes of data and allow for essentially random access from a multitude of clients. Sure, some modern offline/console games probably use them to manage the shitload of content, but for an offline smartphone app, I don't think that is necessary or even gaining anything.

Falco Girgis wrote: DBs are usually reserved for online games like MMOs to manage the sheer volumes of data and allow for essentially random access from a multitude of clients. Sure, some modern offline/console games probably use them to manage the shitload of content

I was obviously assuming online client-server architecture.. which was probably not 100% appropriate considering the likely scope of his project.

Falco Girgis wrote:but for an offline smartphone app, I don't think that is necessary or even gaining anything.

Well.. you're gaining knowledge. :P

Are you able to physically render terrain, levels, or maps yet? Can you see the world that your game takes place in? If so, how are you representing and modifying this map? Do you have some tool to generate it for you? Are you hardcoding it? Are you manually modifying text files?

I guess i wont be needing any map , as player starts in arena everytime and fights other player (CPU) in turn based manner (like I said it is a card based pvp kinda thingy). after winnning or loosing player may get Gold or Exp. then use that currency to purchase items from vendor.(Sounds like a really boring game :P)
So what I thought may be I can save tons of items in DB and create random CPU AI challenging player with increasing difficulty. Since My game seems to be really slow paced, I hope I can afford to lookup into a splite DB (or should I stick to static pool of objects?)
Other thing I am worried about that I am using a sort of "Composite Pattern" (which requires tons of manager classes , as you can see from my setup)
And at last my game has stupid programmer art.. (LOL.. i mean ugly as hell ...
)

For the scope of your project, stop thinking databases. They are not needed. Games rely on the file system for their components, because database maintenance isn't worth the overhead, as you don't have enough data and it doesn't change often enough to justify it, and it doesn't need analytics run on it. Seriously. Stop it. Just use the filesystem, store your data in in some logical fashion. That's what you need to do next, so you can start saving/loading/interacting with data.

For the scope of your project, stop thinking databases. They are not needed. Games rely on the file system for their components, because database maintenance isn't worth the overhead, as you don't have enough data and it doesn't change often enough to justify it, and it doesn't need analytics run on it. Seriously. Stop it. Just use the filesystem, store your data in in some logical fashion. That's what you need to do next, so you can start saving/loading/interacting with data.

Aye Aye captain !!!

On a side note.... is it me or Java is annoying as hell?? i mean I just hate the concept that I cant delete objects myself and I have to wait for the stupid GC every time. pfffffff........

I completely agree with Marauder with regards to an embedded DB.

hellknight wrote:Other thing I am worried about that I am using a sort of "Composite Pattern" (which requires tons of manager classes , as you can see from my setup)

There is nothing wrong with that. We use the shit out of that design pattern.

Is it normal to code most of the part of a game logic until you start to create artwork, spirte, backgrounds for your game and then it sucks cause you are a programmer not a designer. and then you start hating the world .... :P
....

hellknight wrote:Is it normal to code most of the part of a game logic until you start to create artwork, spirte, backgrounds for your game and then it sucks cause you are a programmer not a designer. and then you start hating the world .... :P
....

Trust me, Falco can relate more than you know.

hellknight wrote:Is it normal to code most of the part of a game logic until you start to create artwork, spirte, backgrounds for your game and then it sucks cause you are a programmer not a designer. and then you start hating the world .... :P
....

I don't know if it's because I'm a die-hard programmer and don't care that much about art in games, but I've never had problems with programmer art. Besides, there is always plenty of free (or not-so-free-but-used-anyway (for non-commercial use, of course)) art on the internet...

bbguimaraes wrote:

hellknight wrote:Is it normal to code most of the part of a game logic until you start to create artwork, spirte, backgrounds for your game and then it sucks cause you are a programmer not a designer. and then you start hating the world .... :P
....

I don't know if it's because I'm a die-hard programmer and don't care that much about art in games, but I've never had problems with programmer art. Besides, there is always plenty of free (or not-so-free-but-used-anyway (for non-commercial use, of course)) art on the internet...

yesterday I found a game called dwarf fortress or something like that................ i don't know how to play it.... lol :P