Jump to content

  • Log In with Google      Sign In   
  • Create Account

epicpunnum

Member Since 11 Oct 2012
Offline Last Active Dec 02 2014 11:40 PM

#5092874 A Few General Questions...

Posted by epicpunnum on 09 September 2013 - 09:11 PM

Hello, and welcome to GD.net!

So as it is now, what you are shooting for may be a bit out of reach. I can't speak to your skill level, but from what I read, I'd say you're just starting out?

We're using Yo-yo Games' Game Maker program. I know this is usually used to create casual games, but I'm confident that it will allow us to implement all the gameplay elements we need for R. I'm less certain about how well we can actually produce a product that can be played on different systems. Ideally, I'd like to see this game on both PC and PS3, but resolution problems are currently a cause for concern.

GameMaker isn't a bad tool. It's fairly basic and clunky, but you can rapidly prototype and test your game. I used it for roughly 4-5 years, and I very much enjoyed it. However, it is a restrictive tool. You won't get amazing performance, but it will be good. That being said, I don't believe PS3 development is part of GameMaker, as with most consoles. This, I'd say is what you should be concerned about least, especially because porting to any console is a huge investment. This is because you need a development kit, or at the very least a $1200 debug PS3 to actually run and test your game on the platform before they accept it and put it onto the network (which they also have a certification process before any of that as well). You can read more about it here: http://www.gamasutra.com/php-bin/news_index.php?story=17707

 

PC is always a viable and easy option for publishing, so for now I would recommend that you stick to that.

 

 

Right now we're coding the game in 1280x720. But what happens when this is played on different screens? Our graphics are all pixel-by-pixel drawn sprites; expanding them by anything other than 2x is going to ( I think? ) look horrible and distorted. I'd rather not expand the view distance on the windows, but would that be necessary? What happens if someone plays this on a standard-definition television? I keep thinking about these questions and having no answers makes me realize just how little I know about what I'm getting into.

So what you're experiencing is a screen resizing issue, and in GameMaker, there's not all too much to be done with that. If you go into the global game options, there's an option along the lines of "interpolate colors between pixels," which changes your scaling algorithm slightly so that around the edges it's a bit blurrier and less distorted. Definitely do that if you're not doing pixel art.

Global game options also allow you to choose how your camera fills the screen, so if you're concerned about different aspect ratios consider this.

You may be able to find some DLL's that provide a better scaling algorithm, or use a 3D DLL and use it's scaling algorithm, but I can't really guarantee either.
OR if you're feeling ambitious, you can also create multiple sizes of your Sprites, and, assuming you can get the screen size, use the best fitting Sprite to fit your current screen. This attempt could reduce your distortion from scaling, but uses more memory and a bit of GML. So if you are comfortable managing duplicate sprites, having a larger game file, and using some GML, you could also look into that.


Again, it's been a bit since I've used GameMaker, but hopefully I've put you on the right track. smile.png
And don't forget about the GMC! They're a pretty good community, and much more dedicated and up-to-date with Game Maker than this site, so if we can't really help you, you should definitely ask this there.

Cheers!




#5064811 Screen Particles Help

Posted by epicpunnum on 25 May 2013 - 12:01 PM

Likely yes. To my knowledge, a lot of today's 3D games use 2-Dimensional particles in conjunction with a technique called "billboarding" (there's even a recent article that covers it a bit located here, but it may help to also follow the earlier articles he's made as well). What that means is that no matter what direction the object is being seen from, it will always show the same image. To my knowledge, this is implemented by making a square (based on your library it may be made using 2 triangles), applying a particle texture to it (I've attached an example one), apply billboarding, and then program something to make the rendered particle move and fade in/out.

​I'm assuming you've worked on 2-dimensional games already. It's really the same concept as that, except using a technique that make the image face you constantly. I'm sure there are other ways of doing it as well, but this is one of the basic ways of doing that.

Hopefully that clarifies it a bit :)

Attached Thumbnails

  • Untitled-1.png



#5063392 Names for soldier ranks?

Posted by epicpunnum on 20 May 2013 - 10:10 PM

One path you may want to put thought into is names of third-party factions, as it might give you a more "criminal" vibe that you seem to be looking for. Maybe look into terms used in something like drug traffickers or mafia members.


Possible Street Level Entities:

>Mercenaries/Mercs

>Hitmen/Sharpshooters

>Guards/Security
>Dealers/Slingers

>Falcons

>Associates

>Capos

 

Possible Leader Level Entities:

>Suppliers

>Cheifs

>Executives/Execs

>Lords/Kingpins

>Boss & Underboss

 

Hopefully that helps :)

http://en.wikipedia.org/wiki/Drug_cartel
http://www.askmen.com/money/mafioso_150/176_mafia.html




#5055658 Adding content in a story-driven game

Posted by epicpunnum on 21 April 2013 - 10:46 PM

I am constructing a barebones engine for my game, and because of its structure, it it very easy to create and implement new features, even after the game has been finalized and published. The specifics of doing this isn't too hard, but what I'm struggling with is the best way to present it.

My game is a 2D puzzle/horror game that has a large focus on story. As such, there is a natural progression of mechanics and difficulty; it may start with a simple button and door, and more to remote control puzzles, and finally work with challenging momentum physics puzzles that require more reaction time. Therefore, there may be mechanics that are slowly introduced and fit into the story.

However, what do I do after the game is done? Currently, I plan on improving replay value of my game by offering later updates in the form of a sub-game I'm currently calling "The Tower." In it, the player is subjected to a supply of new maps at random and with each update, more maps will be added, turning it into a game of "how many can you solve/survive?"

But let's say that I end up introducing a mechanic that's entirely foreign to the main story game. After playing the story, the player may be familiar with traps, buttons, doors, toggle switches, spikes, spawners, teleporters, and enemies. But what if when I make an update to expand on what can be done ingame, I create a new game mechanic? For the sake of explanation, let's say it's a window, which can only be smashed with an object moving fast enough. The player would have no knowledge of this; it may even seem like scenery for some, and they may never make the connection that it's an important mechanic.

 

In the story it could have time to be introduced, but if this mechanic is introduced after the story has been finalized, then it would make no sense to go back and change the story. And because changing the story is out of the question, that would leave just simply slapping it into "The Tower" sub-game, where it would be randomly show up without explanation or exposition.

So what I'm asking is: In a game where the story has been finalized, but the potential to add more content exists, what are ways to properly introduce new mechanics without simply telling them every time? What are ways to add new mechanics and puzzles into a story-driven puzzle game?

Thanks for taking your time to read this :)




#5036244 pseudocode!

Posted by epicpunnum on 24 February 2013 - 08:09 PM

As this is filed under C++, I'd assume for this case a C-like syntax would be ideal. Personally, like cr88192, I prefer such a syntax as well, especially as C-based laguages have a lot of ground in today's world, encompassing C, C++, C# and Java (not to mention that there are a few other languages that have somewhat similar structures and syntax).

Just for a general idea, psuedocode can have any loosely defined structure. If you wish to adhere more to the language you're using, it could show up as

void performMorningRoutine(){
  wakeUp()
  shower()
  getDressed()
  eat(breakfast)
}

 

In many cases of psuedocode, the actual implementation is ignored, and instead just has a loose design, opting for comments in some places

void eat( food ){
  if ( hasFood )
    while (hungy){
      //decide how to eat your food and eat it.

    }
}

 

In most cases, it's just to give you an idea of the structure you need to follow for an algorithm.
Honestly though, as long as your structure follows some sort of structure that programmers can get, you should be fine. If there's one language you're using specifically, using it's syntax loosely is probably preferred as long as it promotes readability.




#5030607 Pause functionality in game works only once

Posted by epicpunnum on 09 February 2013 - 10:31 PM

Feel free to correct me if I'm wrong (still learning C++, having learned Java, and some C#), but I believe this is what it is...

In C-based languages, void is simply nothingness, as I'm sure you know. Commonly (thought not seen in Java much - at least I don't to use it) void is an unnecessary parameter in functions if used as above. This is merely just a matter of taste from what I know.
Therefore, this:

void run (void){
  //Filler code
}

should compile the same as this:

void run (){
  //Filler code
}

 

Really the only thing that the extra void does is fill in the parameter parenthesis, and make it a bit clearer to the programmer that the function has no intent to take arguments. However, depending on your level of comments & documentation, it may be completely unnecessary. tldr: Don't worry about it.

There may be some subtleties between them, but nothing very significant.


EDIT: Looking at your loop, I'd recommend doing what slicer4ever suggested. That could very likely be the root of your problem. Granted I can't see all of your custom methods (eg: your update() and all that jazz), but looking at it, it doesn't seem like you're doing all too much with your milliseconds variable, rather than using it in one method. Instead of invoking Thread.sleep(), you might be better enclosing your drawing code within an if statement that checks the time.
To give you an idea, take this basic structure:

public void run(){
  //basic game loop
  while (isRunning){
    //calculate time since last loop
    long milliseconds = System.currentTimeMillis() - lastTick;
    
    //This would be the change here
    //replace (1000/framesPersecond) if you prefer ticks in ms
    if (framesPerSecond> 0 && milliseconds > (1000/framesPerSecond)){
      //GAME LOGIC & DRAWING

      lastTick = System.currentTimeMillis(); //moved into the if statement
    }
  }
}

I believe that a structure more like this would save yourself the time of your interpreter having to call a method outside of your class. It also should be a bit more accurate and constant for your game, as the sleep() and wait() methods can be a bit off at times, or have occasionally failed.
An article here could explain the inaccuracy a bit more than I could.




#5014931 [JAVA] Image & AudioClip

Posted by epicpunnum on 27 December 2012 - 06:35 PM

Java is a high-level programming language, and therefore does a lot of management for you in its virtual machine (JVM). One such thing is a garbage-collecting system. Once the JVM's garbage collector detects that your variable isn't being used anymore, it frees up that area in memory. So your short answer for that is no.
If you're concerned about using space however, you can model your objects in a way that removes references when they're "destroyed," prompting the garbage collector to remove them. If you know you're going to have multiples of that same class being displayed, it may also be a good idea to make your Images and AudioClips static, so you only need to instantiate one, rather than create a new one for every instance.


#5006230 Feedback needed - 2D art

Posted by epicpunnum on 02 December 2012 - 01:35 AM

One thing that I feel makes the first one stronger than the others is the amount of detail put into it. There are leaves falling, grass flecks, and ferns visible. It makes it clear to anyone seeing that there is plenty to look at and admire. The snow and rain ones seem to fall flat in that, and so it comes off as lazier (not to say that you yourself are lazy).
For the rainy environment, try adding things that would contribute to the moody feel of it. Even something as adding vines or moss along the ledges is a good touch, and if it suits the level, maybe add statues or tombstones of some kind. Desaturating the colors of the rainy pallete might also pull together a darker feel. If you keep it at the brighter violets, it may come off more as bright and moonlit, which if it's raining wouldn't be the case. On the snow biome, add dead trees/shrubs, evergreens, and if you're feeling adventurous, maybe even a snowman or two.
The point is just make it seem like you're not walking on an endless expanse of nothing; people like having a lot to see.

As for the snow, I can say that snow has some general rules which you could follow:
  • When agitated, snow will begin to start forming peaks. However if otherwise left undisturbed, it will round off. Depending on where you are supposed to be in the snow evironment, you can adjust these.
  • On steep slopes, snow is almost always flat and thinly spread. If snow on a slope curves outward from its normal path, it cannot turn back. tldr: no bumps on steep slopes
  • Snow will rest on the highest objects naturally. If you plan on having trees or other structures, think about how you would draw them covered in snow without confusing the player as to what it is.
  • Any place in winter is almost constantly overcast with light gray clouds (become lighter the closer they get to the sun). There are still sunny days in winter, but if you want snowfall, expect gray skies.



#4994336 RogueLike Class Selection

Posted by epicpunnum on 26 October 2012 - 10:11 PM

I'm still not the best when it comes to Java, but here is my response as I would go about it:
If you wish to read something into the Java console (AKA: System), your best bet is to use Scanner (java.util.Scanner), which is a means of getting information from something containing Strings. An example of this could be as follows:
[source lang="java"]import java.util.Scanner; //remember to import Scannerpublic class Foo{ //Using a global array of Strings so it can be reused. //Need to change/add a job? Just edit the array private String[] jobs = new String[]{"ARCHER", "WARRIOR","MAGE","ASSASSIN"}; public static void main(String[] args){ System.out.println("Pick your Job:\n"); for (int i=1; i<=jobs.length; i++) //goes through each jobs and labels it System.out.println(i+jobs[i-1]); Scanner s = new Scanner(System.in); //Creates scanner for System.in (the console) String answer = s.nextLine(); //user inputs String here. for(String j: jobs) //for each loop. checks every name for matches if (answer.equalsIgnoreCase(j)) //put your Player creation code here or something. }}[/source]
As for your Panel during turn-based combat, I would make it store an Entity. Then, every Entity in your game could have its own moveset. Just give your Entity class a public method that would allow it to share it with your Panel, and viola!
Hopefully I was clear enough with that response. Doing code out for all that just to explain it to you would be an overhaul. :)


#4994335 How to Unsettle a Player

Posted by epicpunnum on 26 October 2012 - 09:44 PM

Hello world! For a game in development, I am given the following limitations:
  • The game itself is a side-scrolling puzzle game, and thus has a camera suited to that.
  • The game is presented without words, and so there will be no dialogue (grunts, wordless screams, breaths, etc. are okay)
  • Can produce animated cutscenes, but sparsely (will only be included while acquiring items/major story points)
Despite these, the genre is a horror game focused around various monstrosities; for the sake of this, just imagine there monstrosities as amorphous shadows. Throughout the game you will be entirely defenseless to them, and instead must run if need be. For this game however, I want to rely on more than just cheap jump-scares, as those require no finesse to achieve. Rather, I want the game to unsettle the player, make them nervous for what's to come, and be scared/conflicted at what they face.
So far, my ideas are as follows:
  • Have the enemies eventually begin to sob/act afraid of you towards the end, creating uncertainty over reality.
  • Have a rare breed of enemy that is invincible to anything. Can kill you instantly, but moves at a slow rate (think Slender or SCP).
  • Areas in which being seen creates a deadly chaos of enemies that must be escaped.
  • Creating an enemy type/boss that would be seen as controversial to attack (eg: innocent-looking children)
  • Bodies strewn about, sometimes housing an enemy type.
  • Rooms that come before important parts, left completely silent compared to the other rooms, making suspense.
  • Avoiding presenting the mysterious threat at the beginning of the game, until enough buildup.
  • Being unable to attack, forcing flight instead of fight.
  • Offering fewer save points, and giving lower non-recovering HP on player, to make death more of a fear. (debating)
I would like your input. Which of these seem good/how could I improve upon these ideas? Moreover, to keep the game fresh, rather than constantly puzzle-based, what other ways can I affect the player in such a way? Giving examples from other games and personal experience is highly recommended.
I check fairly frequently, so if you require anything on my part, I'll try to help clarify or explain!
Cheers Posted Image


PARTNERS