jbadams

I think the general term for what you're describing is "augmented reality" -- or more specifically in this case "spatial augmented reality" (or "video mapping").  I don't know of any implementations that rival your described game, but it's definitely something people are working on, and there are already some fairly impressive things out there.  The technology probably isn't quite there for exactly what you're describing yet, but it's an interesting idea.

 

Although it doesn't share this type of input -- or for that matter necessarily use computers at all -- you might also be interested in the "real life shooter" Patient 0, where players proceed through a series of professional lit and designed sound-stages populated by actors in screen-quality make-up.

 

If your goal is to get games made -- you want completed, reasonably bug-free software made without spending more time than necessary -- then you should take advantage of existing frameworks or engines rather than expending the time and effort to build your own version.  Slick2d would be an excellent choice for a Java programmer; I'd save jMonkeyEngine till you want to try 3d.

Unless your needs are particularly unusual or you're making a very simple game an existing framework will usually result in a better quality project being completed sooner.


If you want to learn about the underlying technology then work at a lower level - OpenGL might be more appropriate for this.


It sounds to me like you want to focus on completing games rather than lower-level knowledge, but use whatever is appropriate for your goals.

Hope that helps! :-)
(Posted from mobile.)

Programming is essential for anyone getting to making games

That isn't necessarily true --  there are a growing number of packages that allow you to create games using visual editors and simplified scripting systems, and they're becoming more and more capable of producing good quality games that are able to be sold.  You won't be able to make commercial AAA-quality games this way, but you can definitely make great games that match the quality produced by indie and even professional mobile or browser-game developers.  In point #2 of my post on "4 reasons you aren't a successful indie developer" I list a number of commercially successful indie games created with Game Maker and similar tools, and there are actually quite a few more examples.

 

Programming is a great way to make games, and for certain types of games and target platforms it can be your only reasonable option -- but it isn't for everyone, and there are capable alternatives out there that are getting better all the time.

 

Pre-emptive nitpick: Yes, in the majority of these systems the visual logic editors or simplified scripting systems used are technically still programming, but they're a lot more approachable and less intimidating for those who are less inclined to program, and usually don't involve the same process of learning sometimes arcane syntax and having to type and test large sections of code.

Phil, if you want to program then go ahead and program -- the thing that was annoying people was when you apparently gave up on some particular problem and then came back with exactly the same question some time later -- by all means continue with your goal of programming, but if you get stuck you need to stick with it and solve your problem, or if you really need to take a break come back to the same topic rather than just starting over a few weeks later.

 

To be good at programming you need to persist and work through your difficulties.

 

 

You have great enthusiasm, and you're obviously very driven to succeed at programming -- these are great attributes -- you just need to persist through difficulties, and to work hard to understand the advice you're given rather than simply abandoning topics.

 

 

If you want to program then don't ask for permission, just go about your programming.

Maybe try having a read through the topic "what programmers want from a designer" -- a lot of the advice also applies to other team members such as artists, composers, etc.

It doesn't sound like you really want or need to learn to program properly if you're just trying to create some fairly simple games, so I'd suggest an authorware package such as Construct 2 or Game Maker, which allow you to create games using visual editors and simplified scripting languages rather than having to go through the full process of programming from scratch.  Some people think of these packages as kids toys or something that can't be used for serious development, but they have been used for commercially successful indie and hobbyist games in the past and there's no real reason you couldn't do the same.

 

However, if you really want to program I'd suggest a simple language and library such as Lua/Love2d.  Lua is commonly used as a scripting language even in professional development, and is a very approachable but capable language.

 

 

I'd suggest you stay away from C++ -- it's the language of choice for high-budget AAA development, but it's a lot more complex than your other options without offering you significant advantages for simple games.

 

 

Hope that helps! 

The basic idea sounds reasonable, but it's hard to judge whether or not it would actually be fun simply from the description -- perhaps you could try creating a simple prototype (perhaps using a package such as Construct 2 or Game Maker) or even just a video mock-up of how a gameplay session might go.  This would also allow you to try out different ideas and get a good feel for what is and isn't fun in the game.  

 

what could make it easier to read/understand the game mechanics I had in mind to others

You might try breaking down your description into different sections describing things such as "controls", "gameplay", "objective", "enemies", etc. rather than having everything together.  It can also be helpful to do a brief description of how a short session of play might proceed, or perhaps even create a storyboard or mock-up video to help describe it.   

Furthermore, I'd rather not learn a completely new framework which I intend to leave later.

This is a common thought process amongst beginners, but it can be a bit of a trap.  If you get a job as a professional programmer you will usually not have a choice in the matter: you will be told to use a particular language/engine/API and expected to learn it and become productive quickly.  An important skill to develop is the ability to learn and effectively use different technologies, and for most people this will be far more beneficial in the long run than simply getting experience with a specific engine that may or may not be used at your future place of employment.

 

By all means pick engines that you feel will yield good results and be useful to you in the long term, but don't let the fact that an engine might not be useful later hold you back.

On top of what the others have said, I would just like to add that it might be a good idea to get rid of the WIP pieces.

I just wanted to second this.  See the second point in this article: a portfolio should show your best work, not necessarily everything you're working on. 

Think about the following:

• How fast is the player able to travel?  Are there ways they can travel faster if they just want to get somewhere quickly, or are they stuck with a single speed?
• Will there be any time limits or pressure to reach destinations quickly?
• Do you want the player to carefully explore zones, or is it more likely they'll only see some of the content?
• Do you have interesting content to fill the zone, or will there be a lot of "dead" space?

 

Players generally don't like "dead" or pointless space, so if there isn't a meaningful reason for zones to be large consider reducing the size.

 

You know how fast your players are able to travel.  Given those speeds, how far can they travel within any time limits you might be imposing?  By making them travel farther in a shorter time you increase pressure, especially if there's the chance of taking a sub-optimal or dead-end path.  By choosing distances in which they can easily reach destinations quickly you create a lower pressure situation more conducive to exploration and wandering.

 

 

Does that help at all?

Tumble
 
A simple puzzle game where the player uses wind to move one or more tumbleweeds onto fertile grounds so they may sow their seeds.  The game would have very simple controls and would best be played with an overhead or isometric view and would be well suited to mobile devices or browser platforms such as HTML5 or Flash.  This game could also easily be created or prototyped as a board game.
 
 
The game board
 
Tumble is played on a grid -- the ideal size would need to be determined through play-testing, or might possibly vary with larger sized maps (which would also contain additional tumbleweeds and obstacles) providing more difficult levels.  Cells of the game board are either fertile or infertile, and each cell may contain either one or zero game play tokens (tumbleweeds, obstacles, etc.).
 
At the beginning of each level there are a number of tumbleweeds on the board, all of which begin play in infertile cells.  The edges of the board are considered to be an obstacle -- no tokens may leave play by passing beyond the edges of the board.
 
 
Tokens
 
Tokens are any items placed on the board.  All tokens occupy exactly one map cell, and may be either stationary or mobile.

• Tumbleweeds:  may be either small, medium, or large, with larger tumbleweeds requiring progressively stronger wind to move the same distance.
• Bushes:  non-moving tokens which block the movement of tumbleweeds and reduce the strength of wind passing over their cell.
• Walls:  non-moving tokens which block the movement of tumbleweeds and stop wind.
• Special: to be described below.

Gameplay
 
Each turn, the player chooses one side of the board from which the wind will blow, and chooses to utilise a light, medium or heavy wind.  Wind passes from the selected side of the board the the opposite side across each row or column of cells, and may be reduced in strength or stopped completely by certain obstancles.
 
All tumbleweeds then move the appropriate distance based on the strength of wind:

	Weak Wind	Medium Wind	Strong Wind
Large Tumbleweed	no movement	no movement	small movement
Medium Tumbleweed	no movement	small movement	medium movement
Small Tumbleweed	small movement	medium movement	large movement

The ideal specific distances (in cells) of each movement would have to be discovered through prototyping, but reasonable initial values might be 1 cell for small movement, 2 cells for medium movement, and 3 cells for large movement.
 
Any tumbleweed which collides with a wall or the borders of the map is reduced one size category and "bounces off", carrying out the remainder of it's movement in the opposite direction.  Small tumbleweeds are destroyed (removing them from the board) in such a situation.
 
Collision with a bush "bounces" tumbleweeds as above, but does not result in damage. 
 
 
Objective
 
To pass a level, all tumbleweeds must end a turn on fertile ground, and there must be at least 1 surviving tumbleweed.
 
 
Scoring
 
Players will receive points based on the number and size of tumbleweeds which have survived and reached fertile ground.  1,000 points per large tumbleweed, 250 points per medium tumbleweed, and 100 points per small tumbleweed.  By awarding significantly more points for larger tumbleweeds, players will be encouraged to try to preserve the condition of tumbleweeds rather than simply blowing them around the level.  
 
Players will also receive bonus points if ALL tumbleweeds survive the level.  This discourages sacrificing small tumbleweeds unless the player deems it to really be necessary.
 
Some levels will also have a bonus objective (see below) which may offer the chance for additional points.
 
Each level will award bronze, silver, and gold medals at certain score thresholds to encourage replaying or careful planning to find optimal solutions.
 
 
Special Tokens & Bonus Objectives
 
Some levels will feature one or more bonus tokens, which will also come with a bonus objective worth a large amount of additional points.
 
For example, a level might feature a candle which is protected from wind on one or more sides by other obstacles, and offer the player an additional 5,000 points if the candle is still burning at level completion.  For the bonus objective to be achieved the player would have to avoid using wind (either at all, or above a certain strength, depending on the obstacles) from unprotected directions.
 
 
 
Obviously all of this would need play-testing and some areas (such as additional special tokens) need fleshing out.  You would also need challenging (but achievable) map layouts.

You could try LearnCpp.com.

Moving you to For Beginners.

If your interest is to create a neatly packaged bundle of files for some builds and also allow regular directory trees during develoment, there are great tools to do that.

One such library is PhysFS.

See this page for integrating PhysFS with Allegro 5. 

Lazy Foo has a tutorial on calculating frame rate you could check out.  The tutorials just prior to it cover timing functions and regulating frame rate if you need more clarification on the functions involved.

 

Does that help?