Canardia
-
Posts
4,127 -
Joined
-
Last visited
Content Type
Blogs
Forums
Store
Gallery
Videos
Blog Comments posted by Canardia
-
-
I'm looking into having a printed manual produced, in addition to the online docs.
If it can be printed, it can be printed into a PDF file too, that's good enough for offline reading.
-
Will the documentation be in offline searchable format, like chm?
-
My approach would be to get the game testable and playable as first priority. The assets and game logic can be very simple in the first release, but it's important that you get people to try and and give feedback, because they help you getting things right, so you don't waste any time on doing things wrong for long time, and then have to undo everything.
The people might even offer you some assets when they see what kind of game it is, and what kind of assets would fit in.
Start with versioin 0.0.0.0, then raise the 4th last number for every bug fix, and the 3rd number for every new feature, 2nd number for new minor release, and 1st number for new major releases.
It could be like this:
GameA 0.0.0.0: Testing if the game works at all, and simple player controller walking around.
GameA 0.0.0.1: Bug fix with player getting stuck somewhere.
GameA 0.0.1.0: Added crafting of simple items found on the ground.
GameA 0.0.1.1: Fixed some bug with crafted items not being saved correctly.
GameA 0.0.1.2: Fixed a bug with items not respawning.
GameA 0.0.2.0: Added skill advancements in crafting.
GameA 0.0.3.0: Added melee fighting and melee skills advancement.
GameA 0.1.0.0: Added multiplayer networking.
GameA 1.0.0.0: Game is finished and available for public download via PayPal.
-
Yes, beta beta beta! Even alpha will do, or tech preview, anything goes!
-
Got a feature list of the first release? I guess you must have such list for testing each feature anyway
Or maybe publish and keep updated the feature list with a status if it's tested and if it has bugs to be fixed, shouldn't be any additional work. That's what all Linux and GNU developers do too.
-
I want to compile LE3 as full 64-bit version with 64-bit doubles. However I'm not sure if Newton is available as source code, and if not, then I might need to use Bullet which comes as source code and can use 64-bit doubles also.
-
A prefab or script allows that, without requiring that I hard-code a bunch of special requests into the core engine.
Yes of course it should be done using existing engine commands, and not part of the core engine .lib, but it could be still bundled with the engine, for example as a seperate .lib or C++ file, which the user can use if he wants. For example I find the oildrum and firepit scripts very useful, because they have sounds, particles and everything ready to drag and drop.
Like in LE 2.5, there is also a smoke emitter, which uses its own shader and texture. An explosion would probably need a shader too, sounds, textures, breakable physics logic, and damage indication to other objects. In addition to those difficult to implement things, the user could add some camera shaking, consequences of the damage to living objects, sound reflections (echo).
-
I don't think explosion code belongs in the engine, but a script would certainly be appropriate.
I would think a game engine should provide as many as possible features which are needed to make games, especially if those features are used often in various games. Rarely used features can be of course left out, but still give the users a possibility to implement them themselves.
-
As always, make games, not engines. Every game needs its own framework though, but let's not call them engines, but rather game frameworks. Game engine sounds like a general purpose framework, which they are not.
-
Will there be a limited collector's edition box also, or maybe source edition?
With a crawler toy or robot toy, or the famous Leadwerks coffee mug.
-
Yeah, you're right. I'll kick myself in the *** to get it done.
-
Let's see who's will be better, competition is always good
Monkey has also a similar approach, but it's not enough C++ specific for my needs and it has garbage (collection).
-
I used XP 32 as long I could, but then my PC broke and I had to buy a new one which had 16GB RAM. So I had to switch to Win 7 64 to use all RAM. I think in 5 years I will be still using Win 7 64. Never really needed DX10/11, but it's a nice bonus to have.
-
A per-entity undo would be also cool. Sometimes you made something wrong with one entity, but you want to keep the rest how it is.
-
1
-
-
Tighten up the graphics a little bit!
-
The program should look first in it's own directory for the .ini files, then in the %userprofile%, and then maybe even in %allusersprofile%, then in %windir%, if it's still not found, then it should start up with it's default settings and create a new .ini file in the folder it asks from the user (program's directory, user directory, all users, windir).
-
That's what the user's home folder is used for. Many programs save their settings in the %userprofile% directory. You can see there directories which start with a ".", like .gimp, .git, .bash, etc... (yes, on Windows 7, although this is Linux/Unix standard).
-
The article gamecreator posted describes quite well what the benefits of both approaches are, especially the user comments. I often rearrange harddisks and computers, so for me mobility of programs is most important, because I don't want to reinstall each application each time I move them around, usually even losing data and settings by the uninstall/reinstall. Also the fact that .ini files work on each OS, is a huge benefit when targeting multiple OS in everyting you do.
-
Some installers create registry settings, but it's not necessary as you only need to create a desktop icon (if even that), and a start menu/programs folder/item, and a .ini file to store the settings of the app.
-
For all settings.
-
Windows supports also .ini files, so use them.
-
Registry entries are bad, and not needed at all. They are also not available on real OS, so just use some .ini file instead.
-
Is it possible to have 7-Zip LZMA2 Ultra compression for the files in the installer? Maybe in the settings somewhere a command line where you can enter whatever packer command line you want?
-
Is there a possibility to have somekind of ../Common/*.cpp folder for common source files, so you don't have to copy the same source code into each different platform folder?
Editor Documentation
in Development Blog
A blog by Josh in General
Posted
Heck, it must be good enough, because even huge professional companies like Yamaha deliver their electronic documentations as PDF, they do it for example for their Music Workstations, and I'm quite happy with Foxit Reader: fast browsing and searching, convenient page layouts and zooming, and bookmarks. And the printed books in several languages which come with the Workstations are exactly the same as the PDFs.