progress

all the talk around the remake

Moderator: Deathifier

gene foster
Tank commander
Posts: 10
Joined: Mon May 07, 2001 1:01 am
Location: Council ID USA

progress

Postby gene foster » Fri Apr 16, 2004 10:40 pm

I havent checked the web site for quite a while. I am sure glad to see it still active and making great progress on the clone. sorry I am not much help but my programing skills are small and I felt It would be better for me to bow out and let the pros do their thing. I am still available to help if there is something useful for me to do regards gene
no mater what you want to do there will always be someone who will tell you what, how, when, where and that you are doing it wrong. regards gene

Deathifier
Noble
Posts: 344
Joined: Thu May 24, 2001 1:01 am
Location: Sydney, NSW, Australia
Contact:

Re: progress

Postby Deathifier » Sun Apr 18, 2004 5:09 pm

Ah well there hasn't been much progress really, unless someone is working in secret without telling me...

If someone is working on anything EFS 2 related could you please let me know?

- Deathifier

Lothgoradin
Space Legionnaire
Posts: 108
Joined: Mon Sep 02, 2002 1:01 am
Location: Montana

Re: progress

Postby Lothgoradin » Thu May 06, 2004 7:24 am

The most I am doing, or was, is trying to plan out a Dat file tree without the Data. You know, some houses would build something similar to the other houses, but it wouldnt be the same.

IE: Right now, the Us has the M1A1 Abrams...There is nothing on the ground that can defeat it, not even itself, short of artillery. However, the M47s and 48s are roughly the equivalent of the russian tanks build around the same time, but they looked very different. A different tech and unit tree for each house would ork with the story, being as they are basically just different nations.

The goal is to have each house as well as league, church, etc; build from their own trees while still being similar. Also to have specialty units able to built such as the Hawkwood Pheonix Guard.

The main problem I am having is making the game multiplayer capable (of course, a must) Due to having many units available, and many techs available (a number high enough to make it virtually limitless IE: 1000 tech slots - only 200 or 250 are used initially, but it would make it so that any mods are not limited by tech or unit slots) With this kind of flexibility, i figure a save file being larger than is feasable for a email attachment, at least with the hotmail I am using :(
Any Ideas on this would be welcome.
I am trying to get a blueprint together for my own use. The one Death posted is good, but not quite completely comprehensive. At least for my wants - No offense Death

The other thing that would be making it big is the fact that I would like to have a 3D map set up for the galaxy and the systems. Which would allow for a multiple planets per system, and would allow for blockades and justify high ship movement. That and the fact that I want to make it modable so I am putting lots of options in the Dat files.

One of these days I am going to transfer all my information from the paper to the computer and put it on my site.(I would give you the link but at the moment it's just a collection of random pictures and about three paragraphs of typing on a completely different subject of course.)

Matt: If I could get your Hyperion unit formula to assist I would greatly appreciate it.

Darkmage Rising

User avatar
Macroz
Space Legionnaire
Posts: 132
Joined: Wed Feb 20, 2002 2:01 am
Location: Finland
Contact:

Re: progress

Postby Macroz » Thu May 06, 2004 8:51 pm

I've spent last two days trying to specify a data model for the unit part. My first attempt is here.

I just don't buy individual tech trees. There is no reason why somebody couldn't copy the tech if it can be stolen.

I haven't thought much about the data size, I'm sure it will be manageable when the game is done. I'm not sure what you are going to transfer, because I can't think of why the number of technologies would affect the size. I'd love to see what you have planned.

gene foster
Tank commander
Posts: 10
Joined: Mon May 07, 2001 1:01 am
Location: Council ID USA

Re: progress

Postby gene foster » Fri May 07, 2004 11:44 pm

what programing languages are you using regards gene
no mater what you want to do there will always be someone who will tell you what, how, when, where and that you are doing it wrong. regards gene

Deathifier
Noble
Posts: 344
Joined: Thu May 24, 2001 1:01 am
Location: Sydney, NSW, Australia
Contact:

Re: progress

Postby Deathifier » Sat May 08, 2004 6:36 am

Macroz: Thats one huge diagram :)
Any chance you can make a higher level one so its easier to get the general idea at a glance?


The Darkmage: At a rough guess the size of the save game will be determined more by the sheer amount of stuff unit-wise in the game.
Everything else takes up a constant amount of space, except maybe the AI and whatever it needs to function.


gene foster: Probably C++

- Deathifier

User avatar
Macroz
Space Legionnaire
Posts: 132
Joined: Wed Feb 20, 2002 2:01 am
Location: Finland
Contact:

Re: progress

Postby Macroz » Tue May 11, 2004 10:12 pm

Here is a new version of the model. It's been split into several pages for easy viewing. It's an image map so I suggest clicking on nodes :D .

Looney
Fighter pilot
Posts: 31
Joined: Wed Mar 31, 2004 1:01 am
Location: Vernon
Contact:

Re: progress

Postby Looney » Thu May 13, 2004 1:34 am

Wow... Thats awesome Macroz! Good Work! :)
Some people think good graphics make a good game. Good people think good graphics only make a good game better.

User avatar
Macroz
Space Legionnaire
Posts: 132
Joined: Wed Feb 20, 2002 2:01 am
Location: Finland
Contact:

Re: progress

Postby Macroz » Thu May 13, 2004 10:14 pm

Thanks but that still needs a lot of work. I'll try modelling some units during the weekend. I can already see that I put some things in the wrong place etc.

Hutton
Infantery
Posts: 1
Joined: Sat Sep 23, 2000 1:01 am

Re: progress

Postby Hutton » Thu May 13, 2004 11:24 pm

Hotmail can only send 1Megabyte attachments, but it can recieve larger ones.

Would it be possable to design the game to send the savegame files itself?

Tango
Infantery
Posts: 3
Joined: Fri Apr 30, 2004 1:01 am

Re: progress

Postby Tango » Fri May 14, 2004 9:32 pm

Hello all:

Sorry to budge. I posted earlier in another thread about building an EFS remake. I didn't know there was effort already put in to make this happen. Sorry if I try to rebuild the wheel.

Last time I posted, I said I was writting an HLD for the EFS remake. The following is what I have so far. Let me know what you think.

Cheers.

Tango.

This document communicates design ideas for the EFS Remake (EFSR). It consists of two sections. The game section describes various mechanics of the game, while the software section describes the underlying software to implement these mechanics. It should be adequate to communicate all essential ideas of the game and the software. Updates will be made over time to achieve this goal.

Game

This section of the document describes the EFSR from the perspective of the player. It consists of the following sections:

 Overview: lay out the design philosophies of EFSR.
 Player Role: begins detailed description of EFSR by looking at the player’s roles in the game
 Overall Game Mechanics: provide an example of actions executed by a typical player of EFSR in a game turn
 Resourcing: describes how resources are produced and spent within the game, as well as the GUI involved to produce and to spend resources.
 Diplomacy: describes how treaties are made and their status monitored.
 Task Force Organisation: describes how units are organized into task forces and how units are moved from one planet to another.
 Battle Mechanics: describes how to resolve the situation when two hostile task forces met each other in a system
 Religion and Morale: This would be particularly important to a church sect player. It describes how religion influences the game flow and how it can be manipulated by the church sects.
 Research: This section describes how technology is researched.
 Spy Operations: This section describes how espionage and assassination is conducted.

Overview

The original EFS, though shows many signs of promise, fell short of its potential. The EFSR attempts to fix these problems by deviating from the original EFS design. The new design philosophies of the EFSR is described as follow:

Stream-lined Game Mechanics
Playing the Original EFS requires massive micro-management of units. For example, in order to acquire the ability to produce new units, one must first build an engineer. The engineer must be moved to a blank square and build a building. As the number of unit producing building increases, the player is forced to micro-manage an ever-increasing number of engineers to increase his/her production. This quickly becomes a chore. The problem of micro-management is aggregated by the fact that there is no queue for any of the production buildings. As such, to build a large army, the user is required to go to a building, select a unit to build. As new units are being produced, the player repeats the process to build over and over again.

In order to streamline the play mechanics to alleviate micro-management, the EFSR will incorporate the following design elements:

 The separation between map on battle and production: In the original EFS, producing units and fighting for territories both take place on the map. This forces the player to navigate the map when production needs to be done. To streamline the game mechanics, the EFSR will separate the unit production process from the map. Maps will only be used during battle resolution, while production will be handled by separate menus. An example would the system adopted by Master of Orion. In Master of Orion, planets generate a certain number of production points, and points are allocated toward unit building, defence, and research via slide bars. Battles are fought in a separate space map, complete removed from the production of planets. Though the author does not mean to do away with resources all together, but the idea of making menus for production and map for battles is a design decision for the EFSR.

 Using graphs to show trends, to help manage production: Grades will be used to visualise the well being of the player’s empire. The original EFS has a power/progress graph that displays the comparative strength of the empires. Graphs that show more detailed aspects of an empire would have been more important. For example, the graph showing the amount of a particular resource over time would be useful to manage that resource.

 Unit organised into task forces: Unlike the original EFS, which organises units unto tasks of 20 units, the EFSR will organise units into task forces. A task force can be thought of as a stack of bigger size. When two opposing task forces occupy the same planet, a combat occurs and is resolved by battle.

Diplomacy
Though much of the diplomatic relationships could be established in the original EFS, the options provided within the game is limited to various types of non-aggression pacts and one-time trades/gifts. The EFSR will build upon the original in this area, and provide various more options to encourage diplomatic plays among players:

 Trade treaties: The EFSR will provide ways for players to establish trade treaties, ie an agreement to trade a set amount of resources per turn with another player. The purpose of this to provide ways for players to trade among each other to overcome resource bottlenecks that hinders his/her production flow. This is much like the concept implemented by Settlers of Catan.
 Trade/give/demand technology: This is implemented in the original game, and will be continued in EFSR.
 Trade/give/demand votes: This is implemented in the original game, and will be continued in the EFSR.
 Trade/give/demand task forces: This will be implemented in the EFSR.

Espionage
The original EFS has spy units mainly assassinate enemy units. In the EFSR, spy units will be implemented more along the line of Master of Orion 3. They are sent to the enemy to accomplish missions at a certain location.

Battles
Now that production aspect of the game has been separated from the map, the purpose of the map is to resolve battles. The concepts of stacks are gone. Instead, units in a task force are divided into divisions before battle resolution. A Battle becomes an exercise of manoeuvring divisions into advantageous positions while attacking/defending against enemy divisions.

Non-House Players
The cloned EFS will allow human players to control other entities beside the house. The following are planned

 Church,
 Merchant Guild,
 Vau,
 Symbiots

The idea is that each of these entities will have an agenda/victory condition in this game. To achieve victory in a game of EFSR is to accomplish that victory condition for that entity.

User avatar
Macroz
Space Legionnaire
Posts: 132
Joined: Wed Feb 20, 2002 2:01 am
Location: Finland
Contact:

Re: progress

Postby Macroz » Sat May 15, 2004 8:11 pm

Nice to see people producing something. I'm sure there is room for many remakes. Perhaps, if the document gets any longer, you could make a PDF out of it? Have you read any of the FreeOrion discussions? I'm sure you'd find that interesting too.

I think there must be effective tools for controlling production and units. I'm not sure if simplifying production is needed. It feels to me that it would also diminish the meaning of the terrain and soon we might as well have abstracted planets like in MOO2. But that's not what I want.

Graphs are something I intend to do. After all, I approach the game as a visual database query system...

When two opposing task forces occupy the same planet, a combat occurs and is resolved by battle.
I don't quite get your battle system. MOO2-like planets and MOM-like tactical combat?

Tiberius
Assault Legionnaire
Posts: 76
Joined: Sun Mar 07, 2004 2:01 am
Location: San Diego
Contact:

Re: progress

Postby Tiberius » Mon May 17, 2004 1:24 am

Anyone know anything about Hexkit? I just found it and downloaded it. Looks like it might be workable as a plug in style code source. I'm not a programmer but from reading the information sheet it looks like an alterable hex based game engine with definable factions, rules, images and more.

Maybe one of the programmers out there can take a look at it and see if it's worth playing around with as a preset clone engine. From what it sounds like the source code is free for download.
Looks like it's either c or c++ for .net

Here's the link:

HexKit

User avatar
Macroz
Space Legionnaire
Posts: 132
Joined: Wed Feb 20, 2002 2:01 am
Location: Finland
Contact:

Re: progress

Postby Macroz » Mon May 17, 2004 7:39 am

From a quick look it seemed ok except it's missing a couple features. Multiple maps are needed for EFS as well as the "Create Items" and "Construct Terrain" and maybe more. The source is there and seems it's still actively developed.

Anybody want to give it a go? It's not enough for my crazy ideas but might be fun to test EFS rules in.

gene foster
Tank commander
Posts: 10
Joined: Mon May 07, 2001 1:01 am
Location: Council ID USA

Re: progress

Postby gene foster » Thu May 27, 2004 3:21 pm

If Star systems are to have multiple planets, then the space fighters should be able to move between the planets. This would provide and added twist to the game. Regards gene
no mater what you want to do there will always be someone who will tell you what, how, when, where and that you are doing it wrong. regards gene


Return to “EFS Clone”

Who is online

Users browsing this forum: No registered users and 12 guests