About Store Forum Documentation Contact
Donations:
225$/mo



Post Reply 
Updating EE1.0
Author Message
aceio76 Offline
Silver Supporter

Post: #16
RE: Updating EE1.0
(09-23-2013 10:21 AM)Esenthel Wrote:  When it comes to accessing resources via Visual Studio, all you need to do is press Ctrl+MMB on element to get its ID and then Ctrl+V in the visual studio, I don't see any problems with that smile

Respectfully, of course you don't see any problem with that grin You aren't the one who has to convert and rewrite code and be set back due to the severe change in process, haha. Plus, you are also the designer, and designers tend to be in-love with their own designs, we're just customers that may pay for what you provide. smile

One of my large struggles is that I have dozens of config text files, and in them are references to actual file paths of obj, gfx, particles, sound and some other custom files I created. This will *not* be a simple change to utilize the UID of these files, not to mention the files are less "human readable" with UIDs to those files instead of full file paths. Then, the config files themselves get encrypted if part of the data folder, also not desired in this case.

(09-23-2013 10:21 AM)Esenthel Wrote:  Make use of Object parameters - drag and drop other project elements to the parameters in the object editor, then you can access project elements from obj params by findParam through its name.

I would actually rewrite *parts* of my code to accommodate use of the UIDs to take advantage of this, but for the other files like what I mentioned above, I really need to stay with the plain file path and not use UIDs.

(09-23-2013 10:21 AM)Esenthel Wrote:  The goal here is to not require developers to use other tools, but make all of the required functionality to be available by the engine, making everything tightly integrated.

This is really the part that scares me the most. In theory, it's a good idea, but in practice, it's a whole different story.

Large companies nowadays are outsourcing different parts of their organization so that they can focus on their *core* business. They outsource their IT, their accounts payable, etc. since outsourcing to other companies that do *those* things as their core business focus would tend to do those jobs extremely well, better than what they can do themselves.

To bring that back to our conversation here, I fear that the Esenthel Engine is trying to do so many other things that hasn't been part of what made it great in previous versions. Hence, the toolset has become a collection of rudimentary tools, and while time is spent creating those rudimentary tools, the core engine itself has not been getting any focus.

This then brings to mind what some of the folks I've spoken to have asked in the past: why not utilize existing tools from other developers/companies/teams who focus on those types of tools (and might be able to do a better job since it's their focus) and work the core EE platform to leverage those tools?

I know there are plenty of counter-arguments to the statement above versus the "single platform that does as many of the functions possible", but it boils down to one thing: Can you as a single developer create those integrated tools as well as those pre-existing tools and still have time to focus on the core engine, and not lose existing customers in the process?

I think these are all valid points to be brought up. I'd rather have these questions raised now than later when things may be too late.
09-23-2013 02:46 PM
Visit this user's website Find all posts by this user Quote this message in a reply
Alexsee Offline
Member

Post: #17
RE: Updating EE1.0
(09-23-2013 02:46 PM)aceio76 Wrote:  Respectfully, of course you don't see any problem with that grin You aren't the one who has to convert and rewrite code and be set back due to the severe change in process, haha. Plus, you are also the designer, and designers tend to be in-love with their own designs, we're just customers that may pay for what you provide. smile

One of my large struggles is that I have dozens of config text files, and in them are references to actual file paths of obj, gfx, particles, sound and some other custom files I created. This will *not* be a simple change to utilize the UID of these files, not to mention the files are less "human readable" with UIDs to those files instead of full file paths. Then, the config files themselves get encrypted if part of the data folder, also not desired in this case.

From a less experienced perspective, the above maps directly onto my conclusions and projected use scenario.
09-23-2013 03:02 PM
Find all posts by this user Quote this message in a reply
fuzzylr Offline
Member

Post: #18
RE: Updating EE1.0
I think it is important here to remember something when moving forward. When a process changes and you encourage (caught force) people to change. I think it is important to consider upgrade paths for folks who have both small and large projects. Although as an indie you may not have billable hours you do have Dev hours and to rack up a considerable more amount of hours to port to the (new) way of doing business is not always appealing. You need to consider making the upgrade enticing to the people who would be using it and this is for both large and small projects.

It's important to make one thing clear. Just because it's "New" doesn't make it better in all instances. Clearly there are 3+ people who caught this thread and are chiming in. You may have more who are not responding. The general issue is they have large projects and tool sets that don't convert easily and would sent them back on a large scale to move to 2.0. That being said maybe setting a path to ease that pain might lead to more people willing jump on 2.0 as a serious development solution for their existing projects.

Respectfully,

Sean

Fuzzy
Student|Westwood
Project V. Studios | Game Dev
(This post was last modified: 09-23-2013 06:22 PM by fuzzylr.)
09-23-2013 06:14 PM
Find all posts by this user Quote this message in a reply
fatcoder Offline
Member

Post: #19
RE: Updating EE1.0
Not sure if a clear upgrade path would actually help. As fuzzylr said, new isn't always better and in this instance I find 1.0 to be superior. Most people who have worked with 1.0 for a while, seem to want to stick with it.

1.0 gives the developer the flexibility to work with their project however they choose. Picking and choosing tools from EE and mixing them with 3rd party tools to create a unique work flow that works for them. The trouble is, 2.0 is railroading everyone into how to develop their projects.

I'm in a similar situation to aceio76. With many assets that fit together uniquely that makes changing to 2.0 near impossible. Even if it were possible, I'm not sure I'd want to as I'm really happy with the way my project is designed.

For example, I use hundreds of asset files that having nothing to do with EE, such as config files, script files, language files, and others that are all interpreted by my project, not by EE. Therefore EE doesn't know how to handle them, so I have my own workflow and tool chain that works for both that stuff and my EE asset files too.

Just like aceio76, a lot of my files refer to specific paths or to other assets by filename. It has to be this way to make it easy to understand and work with these files. I can't open a script and see references to dozens of UID's with no idea what each one is. Not to mention, this stuff is designed to be readable by the end user too for modding capabilities.

Esenthel Wrote:Typically in codes you will access only few resources, as most of the references to other resources is handled by the engine codes (it's data driven, for example to access an object, you just need to get its ID, no need to get ID of all its sub-parts like mesh, phys body, materials, textures, because they're loaded by the object).

Make use of Object parameters - drag and drop other project elements to the parameters in the object editor, then you can access project elements from obj params by findParam through its name.

On a final note, EE relies very heavily on its object system, which may work for smaller projects with a fixed set of object types. However, in a project where object types can change and the end user can modify objects, this doesn't work. Therefore you need config files and (non-compiled) scripts to allow objects to be changed outside of the executable.

A much better system, is just to use a single object type in EE, then build your objects from "components" which can be defined in scripts and the assets can be specified in a config file.
09-24-2013 12:47 AM
Find all posts by this user Quote this message in a reply
fuzzylr Offline
Member

Post: #20
RE: Updating EE1.0
(09-24-2013 04:08 AM)Scarlet Thread Wrote:  You should never purchase an engine with the intention of using "what it might become" for your game. You should be confident that you can make your games based on what an engine currently is. So if you did that you could just continue using EE1 as is and shouldn't need to upgrade aside from bug fixes.....

sounds harsh maybe but i've learned this the hard way myself.

I Disagree with this. To say this means your settling. I respect your view here but the fact of the matter is that no engine is ever truly complete even for such a young engine such as EE. To say you could produce any game you needed or met your needs without future patching for features or improvement is just unrealistic in my point of view. I'm tired of settling for half baked ideas and incomplete concepts and then the developer changes directions run an awesome product into the ground and drives away it's profit base is a bit self defeating in my humble opinion.

Let me say this. As introverts we take pride in the things we build. In some respects it represents a piece of our pride or accomplishment. A reasonable request from an active customer developing with that software is a potential improvement to your work. It can also be a waste of time. Since EE is a more of a programmers engine your best source for improvement will be generated from your community / user base. I feel like in my humble opinion this is your best source for being as successful as you can while you continue to build your vision. This form or list of complain or criticism does not have to be a negative. It might just make him a rich man or it might force him to get a regular 9 to 5.

Here is why I stick around and watch and am active on the forums. 2.0 is not bad. It's a little gimmicky IMO. 1.0 had a lot of potential. I hear this everywhere I go and from people who have used it. I'm not saying it was perfect. I am here because the base package gives you a lot of bang for your buck. The more cookie cutter it's made out to be the more your long term customers are finding it more difficult to make the switch. I am here because I am hoping that EE will merge 1.0 and 2.0. Drop the cookie cutter feel from 2.0 combined with 2.0 bonuses with 1.0 flexibility.

If you want more people using your product then make sure the advanced users have the features rich product they are use to while still providing the ease of use for the entry level users like me. Unity 3D has managed to pull this while still having Indie developers produce DirectX 11 games. I think there is a lot that could learned from this approach because if EE sticks to it's roots but provided an entry way for entry level programmers / Dev's. This is of course EE also reaches his target audience while maintain the code.

I say what I say because I hope to help shape the future of this engine. I feel like EE has the skills to add a lot of rich features to the engine and attract a lot of new business if he can compromise between 1.0 and 2.0. I will retreat to my corner. Thank you for your time.

Respectfully,

Sean R.

P.S.
I have the funds and resources to help unlock some of the pieces that Gregorz is taking donations for. However, I can't not say I am willing to commit any more resources to unlock tools I feel should already be in the engine. That being said my compromise to this is purposed above. I help contribute to unlocking more features if he can extend 2.0 functionality and remove the cookie cutter aspect of it.

Fuzzy
Student|Westwood
Project V. Studios | Game Dev
(This post was last modified: 09-24-2013 04:58 AM by fuzzylr.)
09-24-2013 04:51 AM
Find all posts by this user Quote this message in a reply
fuzzylr Offline
Member

Post: #21
RE: Updating EE1.0
Scarlet thread, I would agree with you on point of view that you should look at it from a single project point of view, but my past and my future is showing me something else. EE has the ability to one easily code out of a FPS but has the networking to code out for an MMO. The problem is not just starting the game. What happens when you attempt to implement Direct 11 and compatible graphics via openGL. A real developer will have a senior level engineer who could make those changes pending the company had source access. Why do you think all these major game producers are buildling engines. SOE is making an engine. Square Enix is making an engine or re-vamping their existing. The frostbite engine was born because of one reason or the other. That inflexibility in your engine will limit you in a great many ways. As a full fledged developer if I was jumping engines every time I built a game I would never be effective at anything I did because of all the instability. Stability gives you power to rapidly prototype and deploy your next game quickly by use of portability. Now, lets return back to EE. Since the change from 1.0 to 2.0 it is not easy for existing customer to rapidly be brought into the fold by this change and hence you have a split in community.

So as I understand stand your past has lead you to the conclusion that jumping engine might potentially resolve the issue that means your learning a new engine every time you make a game and there for costs you more money. So in retrospect you are loosing money on developing on a new system (learning curve), reporting bugs, finding work around and you have said costs involved. You incur these costs every time you jump. As the owner of 5 engines. I've wasted to much time being split and developing on all of them. I realize now my focus should be on the engine that can provide me the feature I want with the budget I have or i need to open my budget to accomplish my goals. Hence why I am attending school I am sitting back and watching events unfold. I actually have license from 3 engines no longer being made. Trust me I understand your pain. Ask yourself though. Do I keep picking faulty engines or applying faulty logic?

Now, EE is a great coders and is very good at what he does. I have spent a lot time looking at his code and I really have learned a lot about coding styles and some new ideas for coding practices. My goal is not take away from anyone on this form. Greg, if anything I want to say I like your product very much and wish to help. Our passion shows our loyalty and devotion is a great product. I want to see you successful and move forward. That's why I am here. I think EE has a bright future. I want to see all customers happy with tools they can use to develope on. It's not all going to be roses but nothing in life ever is.

Cheers,

Sean

Fuzzy
Student|Westwood
Project V. Studios | Game Dev
09-24-2013 05:17 PM
Find all posts by this user Quote this message in a reply
cmontiel Offline
Member

Post: #22
RE: Updating EE1.0
Today I tried to build android and ios apps with EE 1.0

Android: There is a new ndk (r9) , but I compiled with r8 because last time I found errors.

iOS: Downloaded new Xcode 5.0 (requires mountain lion), compiler llvmgcc42 has been removed and deprecated by Apple so now I can't build my game. Apple LLVM 5.0 throws errors with EE library.

Conclusion, EE 1.0 needs an urgent update for iOS and Android. Please esenthel don't forget old users. Some of us can't upgrade to EE 2.0 after almost 2 years of work as my case.

Thanks.
09-26-2013 01:10 AM
Find all posts by this user Quote this message in a reply
Post Reply