Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 11 May 2010
Offline Last Active Sep 20 2014 03:38 AM

Posts I've Made

In Topic: My Ludum dare entry for feedback

30 August 2014 - 12:29 PM

hmm i thought the grabbing part would be clear since it was in the initial tutorial. 

I know the goal is kind of unclear, but I kind of want that to the an "exploration" part of the game; to find out how to win.


I will look into how to make the tutorial more clear.

In Topic: C++ files organisation

23 July 2014 - 05:23 AM

Wow that is a lot of feedback :P. Thanks a lot.


I will think about this more before converting my projects.



1) Includes may have to still be relative i.e #include "../../player/LeftHand.h" which may get a little bit messy and a pain if you decide to move the project structure.


I would suggest to not include files relative to the location of the source file or whatever, that is just asking for trouble in my opinion. Always include files from a base relative directory (e.g. project root, or more likely the "include" folder) and the problem disappears.



So instead of relative includes, what would be a good way if I don't want a centralized include folder ?

I have this problem recently when I was reorganizing my files and I need to update quite a few of the includes.

In Topic: c++ Lua wrapper help

12 July 2014 - 12:14 PM

Some shameless advertising :P


I wrote a tutorial with my limited knowledge. Maybe it will help you http://zwodahs.github.io/tutorial/lua/. If you don't want to read the tutorial, you can just check out my code from https://github.com/ZwodahS/lua-examples. 

Let me know if there are anything missing =). 

I looked at a few of the wrappers and didn't like them. Writing your own wrapper isn't that hard and you get full control over them. =)

In Topic: So I got another random idea

08 July 2014 - 08:00 AM

So I implemented it and changed something. The web version is at http://mazehack.herokuapp.com/


I have changed the entire game, such that when you move, you get to the next "decision" point instead of just moving straight. This means that turns will not stop the programs, only junctions will stop the program.


I also removed the variable speed, so that moving through each square takes the same amount of time.


Then I played the game for a while, I realized I am drawing graphs to represent the information I have. It became a graph traversal game, which is not what I want. I want the need to deduce the structure of the maze based on the information that you gained, but it seems like I don't really have to do that.


I shall leave the game as it is now. There might be something here that I am missing.

I am quite sure that I am not getting the idea across clear enough, so play the game and see what I mean.

In Topic: So I got another random idea

07 July 2014 - 09:49 PM

Solving the maze completely -- that is, exhaustively exploring the maze and returning the the origin -- is a fairly interesting CS150-level challenge that could be solved with a program using stacks or recursion. So, I don't know if its much of an interesting game -- there's no challenge in getting back since you simply do the inverse of what you did to get where you ended your exploration, and exploring for its own sake seems kind of tedious -- what's the goal? What's the reward for exploring more exhaustively?


Mazes as a challenge towards a greater goal can be interesting (This is the archetypal dungeon in most any adventure or role-playing game, sometimes sans other challenges), but because a maze alone is abstract, they tend to be fairly shallow as far as any kind of interesting gameplay goes.

Maybe I wasn't clear :P


When playing the game, you don't know how the maze looks. You are trying to deduce how the maze likes based on what is feedback to you.

It is NOT about trying to solve the game. There is no solution. You are placed in the same position every time, and you tries to get to various locations in the maze. 

The maze will confuse your feedback by say, making a short path seems long by increasing the time it takes for you to move through it, so you might think that the path is 6 tiles long when it is only in fact 2. 


I am not saying this is a good idea for a game, but definitely feel that you mis understood the game from what you said.