WildWeazel
Carthago Creanda Est
Did you mean to have a "not" in there somewhere?
About those attempts to make an opensource or indy civ3 clone
- Thread starter Kyriakos
- Start date
Did you mean to have a "not" in there somewhere?
I think it may be a good idea to read what I type before submitting it. It would actually make sense. Sometimes my brain is thinking something, and my fingers type something else...
I was thinking about it again. I hope my NW mod will be done mid 2015, so I need something to do after...
I'm considering starting again some game programming. But since graphics is not really my strong point, I'm thinking that I could use some simplification to focus on gameplay. So for example make a simple map (graphically speaking), where the square (or rather hexagons) would be "independant", with no transition (ex: grassland full green tile, desert = full sandy tile, if there is a mountain, it will just be lone mountain).
But on the other hand, allow more options (like muliple levels of irrigation/mines)
What do you think of such an approach? "simplified" graphic engine, but more option for gameplay?
I'm considering starting again some game programming. But since graphics is not really my strong point, I'm thinking that I could use some simplification to focus on gameplay. So for example make a simple map (graphically speaking), where the square (or rather hexagons) would be "independant", with no transition (ex: grassland full green tile, desert = full sandy tile, if there is a mountain, it will just be lone mountain).
But on the other hand, allow more options (like muliple levels of irrigation/mines)
What do you think of such an approach? "simplified" graphic engine, but more option for gameplay?
CivII has single tiles, and in theory they can look good. But they were made/used with 2d graphics in mind (no 3d is used in CivII, and if one uses a render of 3d stuff they immediately look out of place there). So in my view a single-tile set is difficult to work with the graphics we have, moreso the pcx ones 
1) Did I say something about reusing the pcx graphics we currently have?
2) It can work with the mountains, forest, irrigation mines, etc. Just by using the graphics for the "alone" version (like a single peek for each mountain).
Making better graphics with nice transition has little impact on the gameplay and could be done in an "expansion". My idea is to simplify the graphics to focus on gameplay.
I think it may be easier to get support with a solid gameplay but placeholder graphics, than with nice graphics but very shallow gameplay
2) It can work with the mountains, forest, irrigation mines, etc. Just by using the graphics for the "alone" version (like a single peek for each mountain).
Making better graphics with nice transition has little impact on the gameplay and could be done in an "expansion". My idea is to simplify the graphics to focus on gameplay.
I think it may be easier to get support with a solid gameplay but placeholder graphics, than with nice graphics but very shallow gameplay
I don't doubt that, and obviously i cannot program so it is not like i have to offer an alternative there. Merely noting that it will be hard to even have a promising preview with single-tile terrain graphics and other stuff around, such as mines/irrigation or cities. Units might work given they tend to be more pixel-like due to the vastly smaller size of the final unit next to the modelling original in the 3d program. Anyway, just throwing ideas around 
Not sure. Look at your city graphics. Will they change if they are using interdependent tiles, or tiles with blending?
Anywya, I'm thinking about a map with hexagone, and with "edge". the edge will be a small graphics painted over the two tiles, at the limit between the tiles.
It could be a river, or mountain range for example, or beaches/cliff when transition between coast / sea. And may be a kind of minimalist transition, just so it doesn't look to straight.
My main questions are
- Is it required to make as many transition tile as different possible terrain, or is there a better way?
- how would it work when there is a transition, and an edge terrain like a river?
I'll try to post some screens when back home, I did a few tests in the past to show the concept.
Also, I played at some point with a concept of height, where each tile could have a different height in addition to different terrain. But it makes things really complicated in term of map graphics, so i think it is not a good idea.
Anywya, I'm thinking about a map with hexagone, and with "edge". the edge will be a small graphics painted over the two tiles, at the limit between the tiles.
It could be a river, or mountain range for example, or beaches/cliff when transition between coast / sea. And may be a kind of minimalist transition, just so it doesn't look to straight.
My main questions are
- Is it required to make as many transition tile as different possible terrain, or is there a better way?
- how would it work when there is a transition, and an edge terrain like a river?
I'll try to post some screens when back home, I did a few tests in the past to show the concept.
Also, I played at some point with a concept of height, where each tile could have a different height in addition to different terrain. But it makes things really complicated in term of map graphics, so i think it is not a good idea.
I have to suppose that both from an aesthetic point of view, and programming elegance, it seems a better option to have an algorithm calculating/producing automatically the filler positions between the terrain tiles, instead of having to produce different fillers/sets for each tile
Surely that would look a lot better. If you can you may even include the option for a parameter/input of factor of this mixing of borders, so as to allow for variation while keeping things simple. Again something like a parameter from 1 to 5, etc, giving different 'randomised' filler pattern for each integer.
Surely that would look a lot better. If you can you may even include the option for a parameter/input of factor of this mixing of borders, so as to allow for variation while keeping things simple. Again something like a parameter from 1 to 5, etc, giving different 'randomised' filler pattern for each integer.
For randomization, I used a different system in my previous test. Basically, each type of graphics was linked to folder, where you could put as many images as you want, and the engine would randomly picked one.
So for exemple, if you made two different graphics for a beach when on the north side of a tile , you could just put them in "Graphics/terrain/coast/beach/N" and the engine handle the rest.
I'm not sure a fully procedural transition can work very well. But may be a concept of mask/transparency would work?
So for exemple, if you made two different graphics for a beach when on the north side of a tile , you could just put them in "Graphics/terrain/coast/beach/N" and the engine handle the rest.
I'm not sure a fully procedural transition can work very well. But may be a concept of mask/transparency would work?
Sadly i never worked out (up to now, at least) how the 'masked' or 'transparency' options work, either in the 3d-tied programs (some 'niftool' i used for trying to set shadows in CivIV) or the 2d editing programs (eg Gimp). I may look into that again in the future, though
I tried to find again on my computer some old screens. I found a few... but more importantly (in a negative way) I couldn't find my latest engine with the hexagons...
I think I still have the source code, it's the test graphics that I cannot find. No idea where I saved them after several years...
Balthasar
Wise Man
- Joined
- Mar 11, 2005
- Messages
- 3,293
Put that out of your mind. Hexagons don't allow movement in 8 directions, and all Civ3 units move in 8 directions. The only solution is to use squares. That doesn't mean that your terrain can't be interesting, however. Read on...
Or perhaps, it's not actually that difficult. Read this discussion about this graphic. The advantages that variable height terrain brings to gameplay is immeasurable: troops can conquer 'high' ground, submarines can dive deep, canyons can be traps, etc. etc.
Sim City 2000 (now abandonware, by the way - the original Sim City source code has now been released) used 2d iso terrain, combined with blocks stacked to create terrain (as seen here). The advantage of this approach was that it allowed tunnels and underground improvements including subways and water pipe systems (a toggle allowed gamers to "see" the underground improvements under the terrain.
SimCity 3000 improved on that system, coloring and texturing the terrain to look more realistic, and added the innovation that an 8-bit bitmap could be used, not to determine terrain type, but rather terrain height (a very good description of how this worked can be found here). This allowed real-world maps to be used - which would make our war-scenario makers very happy indeed, I imagine.
Then there's CivII: Test of Time (in my opinion the best Civ engine yet built), which could simulate extreme heights and depths by using co-joined maps. This allowed underground, underwater, above-the-clouds (aerial combat), space, and alien planet maps all in the same game. Honestly, if gameplay, rather than graphics, were my primary concern I'd still be playing ToT rather than C3C.
If I were designing this all myself, I'd combine all of these ideas together. A map might have dimensions of, for instance, x=150 y=180 z=20, made entirely of isometric cubes with dimensions of, say, 127x64x64 pixels. Like ToT, three or four maps could be 'stacked', and a toggle would allow players to "see" down to the map below it (straight through any map containing 'Air' or 'Space' tiles).
Each cube type would have assignable properties:
Land cubes could be grassland, plains, polar, tundra, desert, tropical, swampy, marshy, rocky, hard rock (e.g. Granite), or soft rock (e.g., limestone or sandstone). These terrains could be made to change with seasons or eras. Seasons would only be available in games using monthly or weekly turns; Climate Change could affect games using longer timescales (e.g., one turn=25 years).
Underground terrain cubes might be: hard or soft rock, hard soil, soft soil, or sand. Resources wouldn't be visible until directly encountered.
Water tile cubes could be affected by depth (shallow, deep, very deep) and also temperature ('icy' which would slow ships, or 'ice', which would be impassable to ships, but suddenly passable to light land units). Some might be assigned as 'ocean currents', which would allow watercraft to move incrementally faster in a specific direction.
I would start with that. But I wouldn't end with that....
It is quite obvious that hexagones don't have 8 directions, but 6. However, I realize that using 6 of the existing units directions is actually quite close to what you'd have with an hexagon. Except may for very long units such as a battleship.
About your example with Sim city: first it doesn't use different terrain type, and things such as cliff, etc. it's a relativley simple slope, where you always have one level height difference max between two squares. Look also at the bottom right of your image: it's ugly.
Maybe my engine would work better with a limitation like that. Ie. raise a tile by one level, simple effect. Raise it to level 2, then all the adjacent tile must raise to level 1.
In that case, it would be much easier to do the transition for nicer graphics.
My big concern was I didn't have an artist ready to work in "close interactive mod" to make the graphics I imagine could work with the engine quickly, so I could try and correct the engine, or the design.
So I was frustrating and de motivating
About your example with Sim city: first it doesn't use different terrain type, and things such as cliff, etc. it's a relativley simple slope, where you always have one level height difference max between two squares. Look also at the bottom right of your image: it's ugly.
Maybe my engine would work better with a limitation like that. Ie. raise a tile by one level, simple effect. Raise it to level 2, then all the adjacent tile must raise to level 1.
In that case, it would be much easier to do the transition for nicer graphics.
My big concern was I didn't have an artist ready to work in "close interactive mod" to make the graphics I imagine could work with the engine quickly, so I could try and correct the engine, or the design.
So I was frustrating and de motivating
Balthasar
Wise Man
- Joined
- Mar 11, 2005
- Messages
- 3,293
See? you've already found a problem all by yourself. Stick to the iso design, and you'll never have to defend a hexagon again.
That was my point: the terrain in SC2K was ugly, but the iso design was brilliant. The mugly problem was fixed by the time they got to SC3K, as you can see here.
That makes sense. Perhaps you work-in a single exception for Mountain terrain (assuming that selecting terrain type is still an option).
You and any of the other programmers wanting to explore this are welcome to contact me any time for art. If I can't do it, there are others who can, and will. It would be best if all of our programmers could work together, to make the graphics (and programming) load a bit easier. In the past, I've lobbied to keep the graphics as they are in C3C, but I think I see here an opportunity to still use most of our graphics and get variable height terrain (there must be a simpler term for that) too. So I'm in, if that's the goal. In the end, Antal's patches didn't work with my Civ Complete program, so I'm back at square one.
I still believe hexagon are better, since any direction is the same, you don't have to worry about side/corner (ie every tile is touching the adjacent tile the same way).
but anyway, very busy at the office for one month, and still my NTW mod to finish, so nothing serious to expect from me before at least Q2 next year
but anyway, very busy at the office for one month, and still my NTW mod to finish, so nothing serious to expect from me before at least Q2 next year
WildWeazel
Carthago Creanda Est
I think as far as artwork goes, build it and they will come. Any of us should be able to mock up something close enough for a crude placeholder, and our talented artists will come along behind to fill in the details. WIPs don't have to be pretty.
Here's an idea:
Let's start brainstorming then doing some actual work on the game we want.
Begin with a wish list; devise the functions (the logical rules of, e.g., unit behavior; ) organize the functions accordingly and link them logically.
After all code - no matter the language or methodology - is the electronic implementation of coherent, logical systems, both devisable and describable by language.
So, by ensuring a logically constructed design document, we ensure that we can hand out a document for programmers to work from.
Also, during the months it will take to construct such a design, we can simultaneously figure out who the programmers are going to be, what languages, methodologies, standards (Please, yes, standards! No C language arrays of pointers pointing to other arrays of pointers!) and off we go to the proverbial races.
-Oz
Let's start brainstorming then doing some actual work on the game we want.
Begin with a wish list; devise the functions (the logical rules of, e.g., unit behavior; ) organize the functions accordingly and link them logically.
After all code - no matter the language or methodology - is the electronic implementation of coherent, logical systems, both devisable and describable by language.
So, by ensuring a logically constructed design document, we ensure that we can hand out a document for programmers to work from.
Also, during the months it will take to construct such a design, we can simultaneously figure out who the programmers are going to be, what languages, methodologies, standards (Please, yes, standards! No C language arrays of pointers pointing to other arrays of pointers!) and off we go to the proverbial races.
-Oz
Similar threads
