Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Ludus

Member Since 16 Feb 2013
Offline Last Active Jul 16 2014 01:42 AM

#5093900 Gameplay or story first?

Posted by Ludus on 13 September 2013 - 05:47 PM

I feel that it is always easier to design the gameplay first, and then the story afterwards. It is very difficult to create gameplay mechanics around an existing story, which is perhaps why so many game adaptations of movies or literature don't do so well. By designing the gameplay first, you can incorporate those gameplay elements into the story as you create it. Take for instance, just about all RPGs in which the main focus of the gameplay is combat. The story is created in such a way to incorporate many battles and epic boss fights against characters integral to the story line, and these battles can serve as major plot points. These stories often have a lot of conflict in order to maximize the combat gameplay.




#5092342 Need astronomy help

Posted by Ludus on 07 September 2013 - 02:50 PM

The closest 30,000 stars to what exactly? I assume from Earth since that image is a 360 panoramic mosaic of the Milky Way as seen from Earth. In this case, I recommend downloading Google Earth and using the "Sky" view. This will give you a spherical map of the night sky seen from Earth. It will also give you the names of the stars and other celestial bodies, and clicking on these names will give you their distance from Earth.

 

Or even better since you're only asking for the nearest 30,000 stars, check out the Chrome Experiment 100,000 Stars, which is a star map of the nearest 100,000 stars that you can explore in 3D.




#5078031 Radio in a post-apocalyptic world

Posted by Ludus on 15 July 2013 - 09:28 PM

Perhaps this resource will be of use to you: https://en.wikipedia.org/wiki/Amateur_radio




#5075799 How to Program SDL More Efficiently?

Posted by Ludus on 06 July 2013 - 03:45 PM

It doesn't appear that you're converting the format of the surface image to the format of the screen. Not doing so will slow down your program since it will have to convert the image to the screen's format every time it's blitted. When you load your image, use SDL_DisplayFormat (SDL_DisplayFormatAlpha for images with a transparency layer) to return a conversion of the image, then free the original image.

 

Something like this:

Surf_Optimized = SDL_DisplayFormat(Surf_Original); //convert the original image to the format of the screen
SDL_FreeSurface(Surf_Original); //free the original image



#5074958 learned c++, now what?

Posted by Ludus on 03 July 2013 - 01:04 AM

You may also want to look at Tim Jones' tutorials at www.sdltutorials.com.

The "SDL Game Framework Series" will take you through some of the basics of using SDL, and then to the creation of a simple game of Tic-Tac-Toe. After that, the tutorials focus on creating the minimal elements needed to create a 2D platformer, which seems to be what you're after.




#5074542 In regards to a protagonist's weapon

Posted by Ludus on 01 July 2013 - 02:33 PM

What is the setting of your game, in regards to time and theme? Is it a futuristic sci-fi or science fantasy game? A gritty, turn of the century WWI-like theme? Or is it set in the 17th-18th century, when muskets were becoming more popular yet blades were still used at close range?




#5068592 2d workflow for side scroller

Posted by Ludus on 10 June 2013 - 01:02 AM

In Dust: An Elysian Tail, the levels are made up of "pieces" of art (e.g. a piece of a road, a piece of a tree, etc.). These pieces have fuzzy edges and, when put together with the level editor, blend seamlessly together. So no, the ground is not tiled and is not drawn as one piece of art. You can find a bit of information about how Dean Dodrill created the levels in Dust here: http://www.gamasutra.com/view/feature/180520/postmortem_humble_hearts_dust_.php




#5068587 Characters Facial Expressions

Posted by Ludus on 10 June 2013 - 12:34 AM

The problem with "separate movable" facial features is that human expressions are filled with a bunch of nuances. If you try creating expressions in this mechanical way, then you'll end up with mechanical expressions that would look quite off. A quizzical expression is more than a single raised eye-brow. It can include a contortion of the lips, a squinting of the eyes, a tilt of the head. Perhaps the best use of "movable" parts would be to make the eyes blink so the portrait does not appear completely static - but that's probably it. It would be much better to have an artist draw each expression individually. This will also allow the artist to inject personality into the expressions for different characters (everyone doesn't use the same canned expressions - there are differences in the way people express the same emotion).




#5068310 How to run an effective playtesting session?

Posted by Ludus on 08 June 2013 - 04:12 PM

Ask "would you buy it" or "how much would you pay" or "would you recommend to your friend/kid brother/grandmother" instead. That's what I meant by "focused" questions. Also: "rate the controls," "rate the graphics," "rate the story" -- all more focused (thus better) than "rate the game."

 

Good point. It's worth mentioning that the wording you use in these kinds of questionnaires is crucial. It will greatly influence the way the tester interprets the question. For example, saying "rate the graphics" is probably a bad idea since the word "graphics" is somewhat ambiguous. It could be interpreted as resolution, textures, use of shaders, or just generally how graphically advanced the game looks. But perhaps that's not what what you meant by graphics - perhaps you wanted the tester to rate how visually appealing the game is, which would include the art style of the game. A better wording may be "rate the visuals". Careful wording of the questionnaire is key to getting the data you want.




#5068151 How to run an effective playtesting session?

Posted by Ludus on 07 June 2013 - 09:33 PM

If you haven't already, I recommend checking out the video by Extra Credits on this very topic.




#5068096 Memory Management

Posted by Ludus on 07 June 2013 - 03:51 PM

In other words, you have to deal with ownership. I suggest you look into smart pointers, shared_ptr and weak_ptr.

 

I'll look into those. Thanks.




#5068081 Memory Management

Posted by Ludus on 07 June 2013 - 03:19 PM

I decided to use the following code to add an object to the list, rather than adding it using the object's constructor:

 

ObjectList.push_back(new CObject(0, 0, 1)); 
 

 

Thanks for all the feedback.




#5067243 Fourth wall (breaking)

Posted by Ludus on 03 June 2013 - 06:58 PM

If it's done well (and often for comedic effect in a lighthearted game) then it can be good. If it's a serious game that aims to completely immerse the player into its world, then no - it usually isn't a good thing.




#5066077 Is the game loop suppose to run when the user is in the main menu?

Posted by Ludus on 30 May 2013 - 02:29 AM

Perhaps this is already how you have things set up, but I'll try to explain a way of managing the loops of each state in your game.

 

Each of your states should have its own functions for each part of the loop (input, logic, render). So you have your main menu state which has its own input, logic, and render functions, and your gameplay state also has its own input, logic, and render functions.

Now, your program should have a main loop that always runs until the user quits the program. This loop is likely one of the first things your program executes. This main loop also has input, logic, and render functions. However, all of these functions call the state manager to execute the respective loop function of whichever state is active.

 

It should work something like this:

 

Start of Main Loop

Input-> calls the Input function of the active state

Logic-> calls the Logic function of the active state

Render-> calls the Render function of the active state

End of Main Loop

 

As you can see, if a state is not active its loop functions will not be called. While the main menu state is active, the gameplay state loop functions will not be called, and vice versa. The main loop is the loop that always runs, and it simply calls the loop functions of whichever state is active.




#5061637 how these are implemented ?

Posted by Ludus on 13 May 2013 - 06:18 PM

It would first involve doing a sort of collision detection to check if the edge is within grabbing range (in some games this is only done if the "climbing" button or direction is held). If the check is successful, the character would go into a "climbing state" (disabling actions that could be performed in the walking/jumping state) and snap onto the ledge based on its position. During this climbing state the character would be restricted to a few actions such as pulling himself up, dropping down, or moving along the edge. Animations would be handled similar to any other kind of action that involves an animation.

 

Short answer: it's done through collision detection and character states.






PARTNERS