The problem is, in order for a new user to search and find it they'd have to either get lucky or know the specific search terms to find it...

Better documentation is sorely needed for Construct. However, as someone who has written tutorials and Wiki pages it is a long sometimes boring process to write simple documentation. It would take several weeks of full-time work to make an all-inclusive tutorial and I doubt either the developers or any users are up to that.

There are definite holes in the documentation and many answers to the missing information is on the forum. What we REALLY need people to start doing is to write a short wiki when they make an example. Also, don't answer someone's question with information that is not on the wiki! (Just about all of us are guilty of this) For example, the timeline object has several good examples on the forum but no wiki article. Instead of posting an example and explanation on the forum people need to put it on the wiki instead.

One thing that is clear is the info on the forum is hard to find and not the best place for knowledge.

SO I think the two big things we need to get the documentation better:

1. More people need to sign up and start adding to the wiki.

2. People need to stop answering questions on the forum unless they have added that info to the wiki.

Edit: I wonder if having a Construct game contest where part of the requirement is to submit documentation on a behavior, action, or object used in the game would be of interest. The focus would be on info not currently on wiki. Problem is people love to make games, but dislike writing docs so some incentive would be needed.

Nice work for two days with Construct (although the name isn't necessarily my top choice .

My big gripe with this game is the controls. It is awkward to jump around and try to land on blocks, you often end up falling off and dying on spikes. It would be nice if the deceleration was set a lot higher or some other mechanism was used to make moving easier.

The only reason the game is difficult is because it is hard to move the way you want and that isn't a good thing. Everything else was quite nice.

I'm using .99.84 and it doesn't do anything for me at all so this definitely sounds like a bug.

When using your syntax (putting the Sprite name in) it doesn't do anything, when putting a 1 or 2 for sprite name it crashes.

I tried to find the source to the ImageManipulator but it isn't available so I can't do much more to help. I've posted it to the tracker.

I've always been interested in text-based games myself. I think you can make a good text-based game in Construct and I think a few folks here (maybe cow-trix) have made one already.

IMO Construct doesn't have the best support for text related processing and you may find it easier to use Python to parse commands and interact with other characters.

The main thing is to define the world and all of the rooms that the player can move through. Due to complexity the rooms should not be layouts but instead maybe groups or a state. The state machine plugin may be very handy in this type of game.

Text games also heavily involve the use of items. You will need a good inventory system and a method to interact with the items using arrays or hashtables. You will need puzzles and a way for someone to use the items.

So lots and lots of text parsing and processing.

What KrushBrother says is true, it should look just as good tiled.

were still debating on what to do regarding this.

There is really nothing to debate, it should be a no-brainer to go back and fix it. I have a strong suspicion that the large backgrounds ARE the source of the problem. So instead of wasting countless hours with bugs you can't reliably duplicate spend that time instead doing the game right.

Another option is to reduce the resolution on the game and graphics and see what that buys you.

At the very least your game will have a significantly smaller disk and memory footprint and if you still have bugs then people might be willing to help ( I don't see many people willing to wait through the long load times to troubleshoot the game as-is).

Other than the backgrounds, I didn't see anything glaringly wrong in your events. It seems like it will be a cool game!

Isn't there a bug in accessing the Z dimension for the array object?

As far as examples for arrays go. I use arrays in several places in Part 4 and Part 5 in the adventure tutorial. It shows how to loop through and read and write from X, and Y based on loopindex. I thought I ran into a bug when accessing Z, but maybe that was fixed.

I got a chance to look at the .cap file and it is quite a mess. It took nearly 3 mins before it would start in the debugger! At this pace it isn't even practical for me to try to troubleshoot. However, here are some things you can do to drastically reduce the size of your game (on disk and in memory):

1. Don't make the backgrounds paintings!! You should instead have smaller sprites or tiled background objects for different parts of the background. This alone will reduce the size of the game dramatically.

2. I don't know if you are doing this, but don't import the same graphic twice. Once you import it once then copy it into the other layouts where it may be needed.

The game isn't nearly big enough or complex enough to warrant a 15MB .cap. Once you fix your backgrounds then your game should only be 1-2 MB and perhaps your problems will go away as well!

Nope, you're not missing anything. It would be a nice feature to have.

It's not really a nuisance, to me at least, since I now keep a couple of empty events on hand for things like these. You only have to do it once and then you don't need to make dummy conditions anymore for the rest of your project.

Ok, I figured it out.

The keycode is the index into the keyTable[] array on the following page:

https://construct.svn.sourceforge.net/s ... d/Main.cpp

So:

ControlTableEntry keyTable[] = {

{VK_LBUTTON, "Left mouse button"},

{VK_MBUTTON, "Middle mouse button"},

{VK_RBUTTON, "Right mouse button"},

{VK_TAB, "Tab"},

{VK_RETURN, "Enter"},

{VK_SHIFT, "Shift"},

{VK_LSHIFT, "Shift (left)"},

{VK_RSHIFT, "Shift (right)"},

{VK_CONTROL, "Control"},

{VK_LCONTROL, "Control (left)"},

{VK_RCONTROL, "Control (right)"},

{VK_MENU, "Alt"},

{VK_LMENU, "Alt (left)"},

{VK_RMENU, "Alt (right)"},

{VK_PAUSE, "Pause"},

{VK_ESCAPE, "Escape"},

{VK_SPACE, "Space"},

{VK_HOME, "Home"},

{VK_END, "End"},

{VK_UP, "Up arrow"},

{VK_DOWN, "Down arrow"},

{VK_LEFT, "Left arrow"},

{VK_RIGHT, "Right arrow"},

{VK_INSERT, "Insert"},

{VK_DELETE, "Delete"},

So if you wanted the space key you would do a:

if MouseKeyboard.KeyDown(16):

do your stuff

For readability, you will probably want to just statically define the mapping in a start of layout event.

Cheers!

Another Python user!

You may have discovered a bug in the Python support for this feature:

I've been looking at this for the past 30 mins and haven't quite figured out what is wrong but have some ideas:

The implementation of the MouseKeyBoard plugin is here:

https://construct.svn.sourceforge.net/s ... d/Main.cpp

If you look at the actual functions when you normally add an event:

ADDPARAMCOMBO("Key", "Key to check if down.", keysCombo);
	ADDCND("Key is down?", "Keyboard", "%o Key %0 is down", &ExtObject::cKeyDown, "KeyDown", 0);
[/code:10k3mnnh]

That registers this callback function:
[code:10k3mnnh]long ExtObject::cKeyDown(LPVAL params)
{
	return KeyIsDown(keyTable[params[0].GetInt()].vk);
}
[/code:10k3mnnh]

This returns the value for the virtual keys:
[url=http://www.kbdedit.com/manual/low_level_vk_list.html]http://www.kbdedit.com/manual/low_level_vk_list.html[/url]

So it appears that all you should have to do is feed in the key name which would be "Left arrow".  That of course, doesn't work and feeding in key codes doesn't make sense since it won't be found in the lookup table.

So I guess we need to find the Python implementation code and see what is going wrong.  I don't know where it is so maybe Ashley or ROjohound may have some ideas.

i WANT to create an action that says on collision between BULLET and MONSTER add 1 to kill count.

There is a system action that allows you to modify global variables.

Welcome to the forum!!

if monster private variable "hit count" is greater or equal to 5, than destroy monster and go to next layout. However, it goes to the next layout after destroying one monster.

It sounds like your events are working exactly how you programmed them based on your first sentence! If you want to make it go to the next layout after killing all monsters then use a global variable or a player private variable to keep track of how many monsters killed (killCount). If you have 5 total monsters then have an event:

Event: global('killCount') >= 5:

Action: goto next layout

also is 3D possible with construct?

If you want a full blown 3D game you should try something other than Construct. However, you can have 3D elements in your game such as 3D box and look at some of the Mode7 examples on the forum.