markr

I think you should ask yourself:

 

* Which game(s) have performance problems? On which devices?

* What do the profiling data tell you about the location of the problem(s)? Hopefully you can get a native profiler on all your target devices.

* What is the best way of fixing the specific problems?

 

If the answer to all of those points to a STL custom allocator being the BEST way of fixing the problem, then do it. Otherwise don't.

You can't refer to an element which doesn't exist yet.

 

Consider having all non-trivial init code (and certainly all DOM code) in a function which executes on page load.

The Wikipedia page:

 

http://en.wikipedia.org/wiki/UFO:_Enemy_Unknown

 

Contains a detailed description of (and screenshots) the two areas of gameplay (Geoscape and Battlescape). Neither of them is a RTS, but it's quite easy to see how it could work with one.

 

Mark

1. What are the informations I need or to learn to create such editor?

 

Really, nothing that you wouldn't need to create the game.

 

Some features of a "good" editor, such as "Undo", are potentially complicated to implement. You should not implement them unless absolutely necessary.

 

Consider using a third party editor, and writing converters, plugins or other tools instead. It will probably be easier / quicker, and you'll have more time to make the game.

 

2. What are the steps in creating the editor? I appreciate even such small, general/not expanded steps.

 

Well, chiefly you need to implement a level save as well as load. Otherwise, it's just an extension of your game. I usually build the editor into the game (if necessary) or just use conversion tools with third party editors.

 

Approaches can be combined - you might use an in-game editor e.g. for monster placement, but an external editor for map creation.

 

3. Is the game size will become bigger if I use an editor than the game that didn't use one?

 

Do you mean the .exe file size? No, not really. You don't care anyway, as your assets will probably be 100x bigger than your exe files. You could also disable building the editor in production-builds, if you really care.

 

4. Do I have to mess with the compiler?

 

If you can compile the game, you can compile the editor. At least, unless the game is running exclusively on a platform which is not suited to level editing (e.g. console, smartphone)

 

(I am somewhat confuse with these two)
5. How can I make the created game MADE with the editor DO its instructions sequentially?

 

You'd need some kind of scripting or trigger system.

 

6. How can I put assets/ resources (e.g. sprites) together so that the created game will have that file but not letting know the player see what the raw content is in that directory (e.g. use Photo Viewer to see what's the resources look like or use Media Players to play the files).

 

It is easy for a determined attacker to extract your assets. Don't bother trying to protect them with any means which makes the game development harder or builds more complicated, etc.

 

7. Lastly, What are the other concerns that I have to mind?

 

You need to be very concerned about the amount of effort you spend building tools. Do your level editors really need all these features?

 

Can you use a third party editor unmodified? (NB: It might not be a game-specific editor; I've used notepad.exe before now)

Can you adapt a third party editor? Plugin for a third party editor

Can you write conversion tools instead? A conversion tool is likely to be 100x simpler to write than a fully fledged editor.

 

In general, in my opinion, the order of preference should be:

 

1. Third party editor unmodified (NB: your game needs to load the assets in the same format the third party editor saves it)

2. Third party editor with conversion tools.

3. Third party editor with modifications / plugins

4. Custom editor.

 

You don't need to use the same approach for all of your game data. You might have, for example, level design and object-placement, which are related but not synonymous.

 

Also, things such as scripts and triggers might be quite customised, but these could be added e.g. by a steering file to an existing level, with placeholders. If you can add tags into your world-data, then you can write a .txt file which contains descriptions (in some format) of what the tags do. Etc.

 

Don't sweat over tools. They are not as important as the final product.

The same way you'd create a non-browser-based game. There is nothing fundamentally different.

 

Of course you need to be clear about what platforms / devices you're targetting, and what their capabilities are. This is exactly like creating any other game.

Yes, they typically are.

The main motivations are quicker load times and more convenience of distribution.

Suppose you have 10,000 files. This is a fairly low number of individual objects, even for a game without much content.

On a desktop OS, your on-access AV program must scan every file. This is usually very time consuming.

You'll probably distribute your game as an archive (e.g. zip) anyway. So it doesn't make any difference. Your packer may be less efficient than zip. or more, but it doesn't really matter.

The overhead of having large numbers of files in the OS filesystem is quite significant, particularly when you remember that EVERYONE has on-access AV scanners!

Development convenience can be provided by having dev-builds search the filesystem first (and the resources.zip second) for files.

---

There is no security / reverse engineering benefit, because it is just as easy for a cracker to modify your big zip file as it would be if they were individual files. If you want to discourage casual reverse-engineering (or graphics ripping etc), then rename your .zip file to .zpi or something

Something like ArrayList is typical.  This will work well provided you don't have TOO many things.

Presumably you're iterating the list to carry out logic on each monster or whatever (e.g. an overridden method called tick() which does not do anything on the base class).

This works fine until you have a HUGE amount of things.

Then you'd need to make some kind of active/inactive system.

Suppose you have several lists - one for each "zone" on the map. Each monster can be on their own zone list, as well as on an "active" list. Once the player goes sufficient far away, monsters can be "frozen" - removed from the active list.

Once the player goes nearer, you can "reactivate" the zone that was "frozen".

It is of course, additional maintenance to do and quite easy to get wrong. If you allow monsters to move between zones, you need to take care of ensuring that they appear only on the zone-list of the zone they're currently in.

So I'd say, YAGNI, and do the simplest thing which could possibly work.

---

If you're like to have, say, 1M monsters in your game, you will probably need this optimisation.

Depending on whether the game is "naturally" split into zones, levels etc, you may not need this optimisation.

For example, if your dungeon has "floors" which monsters can't easily (or perhaps, at all) travel between, you only need to consider the current floor's worth of monsters. This way you might avoid the problem.

In general, either:

* The software render draws it directly into video card memory with DMA.  This is possible to set up in various platform-specific ways in some cases- the SDL library might do this for you, for example.

OR

* The software renderer draws it into system-ram, then copies the data

Both methods have advantages. System-ram is typically faster to write to (and particularly, to read from, for instance, if you're doing blending) than video card memory, but then the copy operation takes extra time.

If you're writing into video memory it's usually possible to use hardware page-flipping to avoid tearing or displaying partially drawn frames.

Your mileage may vary.

Have a look at the SDL library for platform-specific details of how software rendering typically works.

Optimisation needs to include the optimisation of the programmer's time. If log or pow makes most sense to write, then write it until the profiler tells you not do.

If your site loads over HTTP, not HTTPS, you have no guarantee (or rather the end-user has no guarantee), that some man-in-the-middle has not modified your Javascript code in the wire, and changed it to secretly send the password to their own server.

A HTTP-loaded site can't rely on its own Javascript code being delivered without malicious modifications.

Such modifications are easily achieved, for example, by the owners of a wifi access point who can route requests through a transparent proxy.

HTTPS does not JUST encrypt things. It also guards against the very real threat of man-in-the-middle attacks, and stops content being modified on the wire. There can be no real web security without this threat mitigated.

Just use HTTPS, anything else is worthless.

If you MUST use HTTP, you may as well use plaintext passwords (or encrypt them using rot13, for all the good it would do).

There is just NO advantage of using DLLs nowadays; at least not for a (simple) game.

Sure, you could claim that you save a few K of memory (but .exe files are demand-loaded anyway, aren't they - in Linux they are, what about Windows?), but I think that's pretty irrelevant.

If your game exe is, say 10M (of code+initialised data, not including linking data and debug stuff which doesn't need to be in memory anyway), and you have 100M of data (which is pretty smalll really), then you might save 2M by making an unused part of your game engine a DLL.

It really is a pointless, premature optimisation, for no particularly good reason.

Use DLLs if you HAVE to, and not otherwise.