Primary tabs

Comments by User

Saturday, June 11, 2011 - 05:22

The following ideas are really good:

 

 

  • missiles that reflect off of walls
    • Nice, will give at least one power a more unique feel.
  • Add collisions between entities
    • Note, one of the monsters could teleport. It should be updated, to choose a good location as well.
  • patrol options for npcs and monsters
    • This could either be predefined or slightly more random. I don't know which one is the best.
  • monsters alert nearby allies when alerted

 

 

I had some issues on my mind as well (Warning some issues can drasticly change the gameplay)

 

  • To avoid spamming of the same attack, allow a recharge on powers.
  • Refactor status effects so they use a seperate class. This will make the engine more powerfull. Possibly some code could be shared with inventory. (e.g. using inheritance.)
  • Monster randomisation. (To improve replayability)
  • Putting monsters in teams to allow having allies.
    • Build in summon powers
  • Improved resistance / weakness system.

I hope to start in a few weeks with implementing some of these.

 

Saturday, June 11, 2011 - 03:37

I have got some thoughts about modding support in flare. For this article I use two mods.

  • Core, which is the basic flare game

  • Red World, which is a user made mod. In this mod, the goblins do not have a green skin but a red one.

Directories

The most simple solution is using directories for mods.

  • /usr/share/games/flare/core/

  • /usr/share/games/flare/red world/

Advantages

  • This is a working mod implementation, without needing to code a lot.

Disadvantages

  • It is not very data-friendly.

Mod Inheritance

I suppose that you are familiar with inheritance. If not, you can have a look at wikipedia, but remember it is quite technical. I suggest a similar approach with mods. Suppose that we say, 'red world' is a sub-mod of 'core'. If we look for a resource and it is not in the sub-mod it will look in it's parent mod.

If flare searches for minotaur.png it will first try:

/usr/share/games/flare/red world/monsters/minotaur.png

Not suprisingly, it will not find it there, so it will look in its parents mod 'core':

/usr/share/games/flare/core/monsters/minotaur.png

Advantages

  • It is easy to change an existing mod.

Disadvantages

  • Mods can have only one successor. This will probably be good enough in most cases.

  • In some cases, things are added in the parent mod with the same name as a resource in the clients mod. In this case you'll get problems. This could be solved to specify at each resource if it is a new resource or an overwritten one.

Other considerations

Namespaces

Sometimes it might be better to be able to directly name the mod where a resource can be found. In this case you could write something like.

core::minotaur.png

instead of

minotaur.png

Dependencies

It should be checked if the parent mod required by the mod is available. Otherwise it should give an error message. It would be nice if a link could be provided where you can download it.

Another consideration, is storing version numbers of mods.

Mod distribution

The easiest way to distribute a mod is in a .zip file (or any other compression method).

Maybe there should be a wiki article with a list of mods.

Multiple mods

One thing that is surely fun, is running several mods simultaneously. However there are new opportunities for conflicting files. The easiest way to solve this is ranking all mods in importance.

Override and / or new keywords

If red-world and core have both an item 397, you can have two situations.

  • Red-world updates the item with a new one. (override) 
  • Core has an update and added item 397. (new)

We could let the program guess, but if we require the program to give the keyword override when we want to override, and otherwise take a new one, we will avoid a lot of wrongly handled conflicts.

Thursday, June 2, 2011 - 03:28

Except for the trees, they look quite nice.

One trick that I often use to draw such difficult objects is:

  1. Find a picture of it
  2. Place the picture on a seperate layer. (In the right scaling)
  3. Make the layer above the picture 30% transparent.
  4. Make your drawing above the original picture.
  5. Throw away the picture.
  6. Reset the transparency to 0%
  7. You're done.
Wednesday, June 1, 2011 - 11:31

Nice UI

(There is only one problem. You forgot the submit button.)

I have another suggestion: For description what format is expected (Like "Max 200 MB") use a tooltip-text (with the title atrribute). This will avoid the long page even more.

 

Friday, May 27, 2011 - 12:15

I am missing the following things:

  • A download button. I can't try a game when I can't find a download button. (Even if it's just alpha). And if I can't try it, I can't help. (Not saying that I will, that depends on the gameplay edc)
  • For art, it might be usefull to browse through the 17 pages of 3D stuff in OGA. Bookmark everything that might be usefull. This will help you later on.
  • I know it is hard, but lighting and bloom will greatly improve the looks of your game. I don't know what functionalilty OGRE gives, but you should look at it. Maybe there are easy settings. (I remember that using fog in OpenGL was quite easy)

I hope I have giev you some usefull advise

Wokste

Tuesday, May 24, 2011 - 12:02

I dont know if this is the best place to post this, but looking at the site I had the following inpressions.

  • TKODO reads easy as TODO, which gives a bad impression. I would change it in tKoD
  • Some screenshots would be nice. Maybe also in the title.
  • Tell why this game is worth playing at the first page (together with a big shiny download button).
  • The banner is far too high and does not show the name of the game. I like the creature coming out of the screen. (It would even be cooler when it has red, glowing eyes.)

I hope this will help improving your website, and happy development.

Tuesday, May 24, 2011 - 04:37

Spell Said: I doubt that those portable devices have enough CPU power to software render with SDL.

I think another question would be, at the time they have enough CPU power, (and that time will come), would they also support OpenGL. I think they would be foolish not to support it.

I have also had a thought about OpenGL

Some advantages of OpenGL are

  • Increased frame-rate (Somewhere I read, double or tripple, but it should be checked)
  • Support for Lighting / Giving tiles a color-tint
  • Rotation is easy, although I cannot think of a place where that will be usefull.

Some advantages of SDL are

  • Clint probably does not have that much experience with OpenGL
  • Requirement to rewrite whole parts of code. I expect this will take two weeks or so. For textures http://lonesock.net/soil.html might help.
  • Many Hand-held devices support SDL but not yet OpenGL

So, in my opinion OpenGL will be an improvement, but one that will take some time to implement. Also, I am sure FLARE should eventually work with OpenGL.

 

Monday, May 23, 2011 - 11:36

What motivates people to tennis, play online games or work in the garden?

It is fun for them, and so is coding for me. I also like to program things in the right way (I mean my way) and whenever I like. This means, not worrying about deadlines, but also not waiting for others to do their parts. That usually brings you down to a one-mans project.

Friday, May 20, 2011 - 05:12

Text messages like "Game saved to slot 1" keep on the screen and can sometimes in combat give strange results. My suggestion would be disabling them after 15 seconds and when combat starts.

It might be worth keeping track of some statistics like:

  • The number of times you saved (before completing the game)
  • Time played.
  • Kills.

This allows users to try to do things in the best way possible. I can remember that when we played tomb raider, we tried to save it the least amount of times to improve one meaningless number in our saves.

Friday, May 13, 2011 - 14:59

> I'm pretty sure that if you wanted to achieve the first perspective, you would have to have an orthographic camera that looks down at exactly 45 degrees and then stretch your aspect ratio vertically by a factor of 1.414 (that's a wild guess though).

That will give you: y' = y + z*0.707

I would go for : y' = y + z*0.5 (You can scale z by 0.707 as well to achieve this effect.)

Pages