Hi all. I’ve been going over a particular game in my head for two or three years now, working out various details of what I would like. Now I would like to see it become a reality. It won’t be a big production 3D Quake or EverQuest clone, or anything near that fancy. I am thinking of a 2D isometric tile game with some of the following features 1. Multiplayer online world, where people gather on various “maps” to socialize and play the game 2. A map editor, to allow people to design their own maps for uploading to the server or possibly hosting on their own server for others to join. 3. A basic image editor to allow making various objects, floor tiles, and walls to go into the maps, for true customization. 4. A script editor to allow storing variables based on the map and on each player, provide certain animations by swapping objects, and provide interactivity to the map. Now, the game engine itself will allow the view of the map to be turned to one of four views, 90 degrees from each other. Basically, it would allow you to view the map from north, south, east, and west. (Or North West, North East, South West, and South East, if you prefer) To do this with 2D objects, I plan to use multiple images for each object, floor tile, wall, etc. This means making a new file type, with a header in front describing the object (various stats, like can it be walked on, sat on, picked up, and some offsets) and some pointers describing the location of the first byte to each image, along with image height, and width. (Or size in bytes). Some objects that look the same from each of the four directions can re-use the same image for all positions. These include floor tiles with grass, or a table with four legs. In game, I may just load the one image and use pointers to point to that same image for all four directions. Some objects may look the same half the time, such as certain pillows, or perhaps a table that has two place settings. The images would alternate back and forth as you rotate the object. Then some objects, such as statues, or other more complex objects would require the use of four different images. Add to that, I want to add two layers for each image, for most objects. (Item, Floor, maybe wall? Perhaps not player.) Since layers are just separate images stacked on top of one another, this is just a matter of doubling the images. And for items that can be picked up, I may go with yet another image to use while item is in inventory. I figure the best place to start would be the object editor, which would have a very basic image editor built in, but also accept cut and paste operations to past from other image editors, and possibly import bmp and png, and then save the object into a single file. For now, I will use one object per file, though eventually I would like to add multiple objects into a single file using some sort of compression routine. I would like each image to be stored in RGBA format. (Red, Green, Blue, Alpha). If the proper use is as it used to be, which is to blit an alpha mask to the surface first, then blit the image, then when reading the file and creating the image objects in the memory, I would just use the RGB values to create the image and the A to create the alpha mask as a separate image. (Note that this has once again doubled the number of images needed for an object.) Now, I have written console apps in C++ many times, but have no experience working with windows GUI, or with Direct X. (I had always thought Direct X was for 3D, and that other routines were used in 2D games. From the information I’ve found on this site and others, I believe that to be a bad assumption now.) As such, I have no idea how to properly store this information in the files (I have heard bitmaps are written to file in reverse order?) and how to use that info to build the images in memory so that they can be blitted to the screen. Any help would be greatly appreciated. Also, I wouldn’t mind going open source on this, since many of the mechanics are well beyond my knowledge, and seeing this game become a reality is far more important to me than getting any kind of credit, or gaining money. The game would be free download and free to play anyway, and any kind of venture I may take with it to earn money in the future would be in renting server space for people to host their own maps. (This would of course be contingent on the game being popular which I have no guarantee of that.) So if anyone would like to contribute, please ask, and I'll sign up for a source forge account or something.

Oh, yea.. for those wondering why the double layers on images..

I would like to allow you to make objects that truly surround a player, by drawing one image to go behind the player, then another to go in front of the player. Many objects will use one or the other layer, depending on if the object should be drawn in front of or behind the player, and some objects would use both.

The game would draw the view port from the top across the screen row by row. (note: I have yet to figgure out the algorithm for determining drawing order from each of the four view directions.)

Each spot would get the floor tile first layer drawn, then the walls on both upper surfaces (upper right, and upper left), then floor second layer (so that some floor tiles can have built in tables, for example), then object first layer, then any player present, then object second layer, then any walls on lower right and lower left of the map coordinate. I am entertaining the idea of using one wall object per map coordinate, having two layers, one being the upper two walls, and the other being the lower two walls. How these walls will work with walls on adjoining map coordinates is still unclear.)

Also, for determining which image of an object to use, by applying an image number for each image of an object, 0 - 3, and applying the same numbers for the map view directions, add current map view direction to the orientation of the object, and modulo by 4 or by the number of images the object is using, would give the correct image number to use.

See, I told you I had worked out a few details.

[Edited by - Aakanaar on October 24, 2008 11:03:03 PM]

Quote:I am thinking of a 2D isometric tile game with some of the following features:
1. Multiplayer online world, where people gather on various “maps” to socialize and play the game
2. A map editor, to allow people to design their own maps for uploading to the server or possibly hosting on their own server for others to join.
3. A basic image editor to allow making various objects, floor tiles, and walls to go into the maps, for true customization.
4. A script editor to allow storing variables based on the map and on each player, provide certain animations by swapping objects, and provide interactivity to the map.

That's good. You can dream big, but you must break up the project into small bits. Accomplish each bit; then weave them together. In my opinion, the list of items should be added after you already have a simple game built.

Quote:Now, I have written console apps in C++ many times, but have no experience working with windows GUI, or with Direct X. (I had always thought Direct X was for 3D, and that other routines were used in 2D games. From the information I’ve found on this site and others, I believe that to be a bad assumption now.) As such, I have no idea how to properly store this information in the files (I have heard bitmaps are written to file in reverse order?) and how to use that info to build the images in memory so that they can be blitted to the screen.

You can make 2D games in DirectX or OpenGL, but you can also use a 2D API that is much simpler to use. Examples of this include Allegro, SDL, or SFML. I strongly suggest making a basic 2D game first using one of the simpler APIs. If you code things nicely you can always upgrade.

For example, I wrote a 2D scrolling engine in python\pygame. I then rewrote the engine in C++ with SDL. Now I changed it to SDL with OpenGL. The point is that it is not that hard to "upgrade" to a better or more robust API later (other than the fact that you need to learn the more complex API). You just change which functions you call for graphics, but most of the underlying game mechanic code will not change.

So that is why I advise going with a simpler API first and just blit things to the screen. You asked about bitmap images. Basically, these are the building blocks for the graphical portion of the game. Usually you blit in reverse order: Blit the background first, then the middle, then the foreground.

To take the simple example of pacman:
1. Blit the maze.
2. Blit the pellets.
3. Blit the ghosts.
4. Blit Pacman.

If you already know all this you can move on, but if you've never made a simple 2D game you need to. The point is try to make a simple zelda-clone before you make the game you really want. Sorry there is no substitute for experience.

Ok.. well I am using Bloodshed C++, with Rededit for resource files, and MingW compiler (came with Bloodshed). I think Allegro is for DJGPP, I've heard of SDL in passing (am looking the site over more carefully now), and have never heard of SFML..

Which library would you recommend to use with Bloodshed?

And, again it is important to me to see this dream become a reality, so while I can code much of the non-graphical parts, would it be worth my time to try to document all the features and make an account on source forge or some other site to attract other programmers to help? Or would it be better to just put the idea back onto the back burner, to sit another two or three years while I try to get the experience needed?

I am thinking of just trying to do this project step by step, by starting with the object editor, first getting a pcx file that would be the main window to show, then adding in the buttons and other stuff, and the basic image editing controls and functionality.. and hopefully if I can tackle all of that, then be ready to start learning to work with the images in memory and saving them to a file using my own format.

Once I tackle that bit, then making the map editor next would allow me to learn how to work with tiling the images, and using offsets to make sure the images line up correctly.. and a walk around mode for testing.

Then I can start working on the server and client aspect, making it an actual game, then start adding in the scripting ability and script editor.

Each of these steps are ordered to allow me to start with basic steps and build onto each step, in what appears to me to be a progressive order from simple tasks to the more complex tasks. I hope.

Quote: Ok.. well I am using Bloodshed C++, with Rededit for resource files, and MingW compiler (came with Bloodshed). I think Allegro is for DJGPP, I've heard of SDL in passing (am looking the site over more carefully now), and have never heard of SFML..

Most people around here recommend either Code::Blocks or MSVC++ since Dev-C++ is no longer supported or actively developed. The 2D libraries that I listed can be used with Dev-C++, Code::Blocks, or MSVC++.

I would recommend SDL since that is what I use. I also use Code::Blocks. In any case if you decide to go the SDL route there is an awesome site for tutorials and how to set it up under pretty much any IDE: Lazy Foo Tutorials. Lesson #1 tells you how to set it up.

Quote: And, again it is important to me to see this dream become a reality, so while I can code much of the non-graphical parts, would it be worth my time to try to document all the features and make an account on source forge or some other site to attract other programmers to help? Or would it be better to just put the idea back onto the back burner, to sit another two or three years while I try to get the experience needed?

I don't know the answer to yr question. I think the best way to get help is to get the project going and establish that you are committed to it. Then more people may be willing to join the cause. Also, there is a help wanted forum here that you can solicit help.

Quote:I am thinking of just trying to do this project step by step

That is definitely the way to go. To give you a basic example: for one of my early projects I wanted to make donkey kong. First, I just blitted the background. Then I blitted mario to the screen. Then I acquired user input to move mario, then I animated mario, etc, etc. The basic gist is to keep building with small blocks, adding more features and content and functionality.

Also, have you read the Isometric & tile-based game resources for gameDev? If not you should check them out: go up top to resources, then click articles. Scroll to isometric. There is some good info there.