Messages

1

SFML projects / Re: moonman (v0.1 windows alpha)

« on: August 28, 2012, 04:09:56 am »

I love it!  Great work!

I'm wondering if you could explain some of your technique with rendering?  I'd love to learn more about what you do here; it runs so smoothly!

Overall, great job and I'm looking forward to see more from you.

2

SFML projects / Re: Endaeva - A Universe-Sandbox RPG!

« on: June 30, 2012, 10:54:26 pm »

Endaeva is going to shift into more of a hobby project from now on most likely.  I love the concepts in it and the idea of the game, but their doesn't seem to be too much interest.  That's okay, but it always means it won't really be financially viable, so for now I'll likely be putting it on the backburner while I try to figure out where to go next.

If you think that is what is best. I personally think that what StormWingDelta said is on track. Its not so much that there is no interest, but there was not enough incentive to invest in something that was a year from delivery. If you had a playable demo and a web site - tools that will help you market and promote the product - I think the results of the Kickstarter would be much different. I also participated in the 'Edge of Space' KickStarter which had some concepts similar to yours (metroid style sand box). I don't think their game will be half what you originally proposed in your first Kickstarter video and yet they easily made their goal and then some.

Financial success of any product isn't about ideas or public interest it is about good marketing. The best marketing comes from a happy customer base.

Though I will say there is nothing wrong with evaluating your game once it has met your current design goals, determining that it is not fun enough and going back to the drawing board to improve game play. I am concerned that if you are not even finished with version 1.0 and you are already planning a bigger badder 2.0.

IMO you should consider the big picture.. You said your goal was to make a game 'You wanted to play' but now you are saying you won't make the game unless you fully know in advance that it will be a financial success... I believe that if you focus on the former, you won't need to worry about the later. Also, even if version 1.0 only sells 1000 copies, version 2.0 might sell a million. It is much easier to make a version 2.0 of a completed version 1.0.

Just some things to think about when you have more time to work on Endaeva...

-Steven

Well, in all honesty, what I have now is pretty fun.  It just needs to be "perfect" before I let people play it.  You're right, it really is an issue of poor marketing on my part. 

To clarify on this "2.0" concept, most of my code uses complex inheritance, virtual methods, and solid OO principals.  But some aspects of it do not, such as the state manager and rendering pipe.  What I'm talking about with recoding is making a more solid state manager, universe manager, and rendering pipe.  And for multiplayer, I need a devise a system that can handle physics for more than one player using an authoritative server scheme (in case I want to have secure, official servers eventually), which is not an easy thing to do.  It's why you see most games lacking any complex physical interaction. This likely means I will need to make heavy mods to Box2d or possibly code my own, less robust (but more focused) physics engine. 

I've always operated on a "prototype first, debug later" basis, instead of the "engineer first, code later" concept.  I've prototyped, debugged, and I actually like the results, and if the Kickstarter was successful I would build off of it, but seeing as where it is at, I feel I can turn this disappointment around by staying more true to my core game vision.  That means adding even more to the game.  I will post an update on Kickstarter when there is a short amount of time left explaining the direction I'm going, I've got it pretty much figured out at this point.

I appreciate the thoughts and assistance in this process, it really makes developing much less stressful.

I will eventually launch another kickstarter for the improved version of this project.  That one will definitely learn from the mistakes of this funding period.  It will have a free demo available, a website up and running, and a more "personal" video talking about my story with more solid gameplay.  When I get to that stage again, it is going to be very different than this attempt. 

Until then, I'll likely be posting updates on this thread and another one I started on tigsource forums. 

3

SFML projects / Re: Endaeva - A Universe-Sandbox RPG!

« on: June 28, 2012, 10:41:18 pm »

http://x10hosting.com/

I've ran across a nice host that lets you do pretty much anything you want within reason.  The above link should at least help.  As long as you know HTML and/or PHP code you should be fine.   Also they are free so that should help if you're running out of money. One less thing to pay for all they ask is that you log in every month or so.  

Hey, thanks a bunch for that.  I'll have to brush up on my PHP skills but I think I could make something like that work.  Much appreciated.

That is terrible news Tom. I know how stressful things can get when one is facing a financial crunch. I pray you are able to find a great job where you can use your skills as a software developer.

Keep us updated from time to time on Endaeva though even if the pace has to slow down for practical concerns it is good to see progress (don't show everything though, gotta save the best for launch;).

Well it's the state of the US right now I guess, so I'm not alone.  I suppose there is some solace in that.  Endaeva is going to shift into more of a hobby project from now on most likely.  I love the concepts in it and the idea of the game, but their doesn't seem to be too much interest.  That's okay, but it always means it won't really be financially viable, so for now I'll likely be putting it on the backburner while I try to figure out where to go next. 

Actually I've come up with some big plans for Endaeva, but they involve recoding many aspects of it.  I want to really make it a solid multiplayer based game, and I feel it needs some major coding overhauls to get it to where I want.  So, perhaps the lack of popularity is a good thing.  I can take more time, be more relaxed on the coding, and keep it truer to my vision.

4

SFML projects / Re: Endaeva - A Universe-Sandbox RPG!

« on: June 21, 2012, 02:48:21 am »

There are 10$/3month hosting around, for a simple web it should do :p

I'd like to add, the game name is amazing

I don't think you understand.  I have no money.  I'm about to sell everything I own if I cannot land a job somewhere, and this project will be suspended until I do.  I had no intention of doing a Kickstarter for this project because I wanted to complete it before revealing anything about it, but my financial situation deteriorated so rapidly I had no choice if I wanted to continue it.

So no web hosting for me, until I can find a way to survive.

5

SFML projects / Re: Endaeva - A Universe-Sandbox RPG!

« on: June 21, 2012, 01:30:30 am »

I just wanted to ask: Are you planing on creating a website?

Yes.  I just can't afford hosting at the moment.

6

SFML projects / Re: Endaeva - A Universe-Sandbox RPG!

« on: June 12, 2012, 12:57:15 am »

Man, you can't let anything hit your pride for this one!You did an awesome work so far, and it will be even way better and more polished.

I know a lack of proper feedback or even time to create an hype can be demotivating, and dont let the funding create too much stress in you, just do your best with your time.

I wish you all the best luck with it, and if i can help in something just contact me

Thanks man.  The difficulty with funding/reception hit me hard at first, but that won't stop me.  You're right; all that stuff really doesn't matter anyway.  What matters is just having fun making a game that can be enjoyed.

read the book "life's a pitch", we use it in uni and it can really open your eyes!
I did a quick google and this is it [ link ], in case you're interested and would like some more details.
Also, should you pick it up: don't read the second part. What that means.. you'll know when you get there

Looks pretty fascinating!  Thanks for the recommendation, I will add it to my reading list

Thanks.  My motivation has been hit pretty hard since I released and attempted funding.  I think I'm bad at going public with work, or something...it's frustrating.  I know people would enjoy what I'm making if I could just properly convey it.

Hello Tom,

Don't get discouraged. I think you have great potential as a game designer and can't wait to see your completed game. Even if you don't succeed in getting the project funded this time around, you can always try again in the future.

I'd also be willing to help with the project.

-Steven

Thank you, Steven.  Very true words.  Sometimes, those pesky emotions remove the logical reality in a situation.  I will keep your willingness to help in mind!


I appreciate the encouragement.  I took a break from trying to promote my work these past few days and added a cool lighting system.  It really adds alot to the feel of the game, take a look:

7

SFML projects / Re: Endaeva - A Universe-Sandbox RPG!

« on: June 11, 2012, 12:56:18 am »

Your project looks really incredible, it seems to me that the principle of "being wise and clever if you're an one man army" was applied to its fullest, i see a lot of potential, and i hope you succeed

Thanks.  My motivation has been hit pretty hard since I released and attempted funding.  I think I'm bad at going public with work, or something...it's frustrating.  I know people would enjoy what I'm making if I could just properly convey it.

8

SFML projects / Re: Endaeva - A Universe-Sandbox RPG!

« on: June 03, 2012, 12:34:43 am »

Looks pretty cool If you want more exposure for your kickstarter project, why not go to reddit? It helped with Grim Dawn, could help you a lot!

I'm not exactly sure what reddit is, but I will check it out!  Thanks for the feedback and suggest

9

SFML projects / Re: Endaeva - A Universe-Sandbox RPG!

« on: June 03, 2012, 12:33:49 am »

Ever since playing Daggerfall, I've always enjoyed the idea of playing a game with massive amounts of content. Although the game play isn't my usual preference, it definitely has my attention.

How do you intend to handle death/saving/loading etc?

Also, do the worlds just represent "backdrops" for the various "stages" or are there interesting things to explore in each world? They look like console RPG maps, but why would one want to dig through to the other side of a planet?

Hi,

Death is already implemented and pretty simple.  When the game saves, it creates a waypoint.  I have various ideas atm on handling saving, but for now, a waypoint is created by user input.  When you die, you respawn at that waypoint with your character fully healed.  The idea is that you must progress to where you were again, so the challenge is primarily the time needed to get there.

There aren't really stages per se...its a game universe.  Those are entire worlds, and they are VERY large.  At the center of each world is a portal to an alternate dimension, which I will talk about at a later time.  The world will have lots of content to explore, including random treasures, random enemy spawns, and more.  The main thing about exploring the worlds is the configuration of enemies. 

You want to find enemies that are more powerful than yourself, destroy them, and upgrade your own character.  There are natural boundaries such as gravity and thermal heat levels that hold you back so upgrades are needed.

Also, space is currently empty, but that will not be the case soon.  So, this universe will be filled by the time I release.

You asked about stages and backdrops and I want to emphasize, there are no stages nor backdrops.  Those worlds being shown are real representations of the world you're entering.  The effect is sort of like entering a planet from space, in 2d.  The shape of the world you see from space is the same shape of the world you enter, and the colors and images used to represent it indicate the terrain composition.  That is important for factors relating to enemy spawning....

As for loading, it's a simple menu where you select the world you want to load.  The game ties a character to a world, so it isn't very complicated.

10

SFML projects / Endaeva - A Universe-Sandbox RPG!

« on: June 02, 2012, 10:47:38 pm »

UPDATE 6/11/2012:
Gameplay video showing new lighting experiment:




__________________________________________________________

Description:

Endaeva is a tale of death, rebirth, and evolution.  It follows the progression of an alien race of creatures powered by the stars themselves.  You are one of those creatures, a newborn, pitted to survive and grow among the old iterations.  There is only one goal on your mind: become strong enough to be the first to journey towards the center of the largest glowing light in the sky.



This game is about possibilities without bounds.  Most games limit you to a linear world and a controlled path.  I wanted a game where there were no such restrictions.  Where I could fly into the air and not hit an invisible wall; indeed, where I could fly from the ground into space and beyond.  A game where the points of light in the sky were more than just points of light, but destinations to explore with intrigue.  Where nothing is off limits, not even the most dangerous of objects.  With this in mind, my game arose.

No one example can describe what I've already made and what I envision, but throughout my life I've been inspired by great classics such as Megaman X, Supermetroid, Digger, Castlevania, R-Type, Final Fantasy Series, Terranigma, and others.

Elements from many of those greats along with alot of my own unique ideas all come together in Endaeva.



If you like what you see, and would like to know more, I've began a kickstarter to raise funds for this game and get a feel for the interest of it:



--------------------------------------------------------

Here are some key, unique, interesting features:

Fully modular character system

Fully destructible, persistent universe, filled with worlds

Enemies that drop every component that they are, giving you the chance of acquiring it

Intriguing back-story.  Though my game is not story-centered, I still want to make it make sense.

Massive variety of gear to loot and acquire -- and in my game, more loot means more enemies!

Depth of an RPG, complexity of a simulation, all with the simplicity of a shooter

Unique character progression

The ability to seamless transition from the ground to the sky -- NO loading, NO starmaps!

Great depth in items to equip, include: Base body, arms, guns, boosters, wings, engines, physical shields, energy shields, swords, hammers, bipedal legs, hover systems, wheel systems, and MUCH more not yet developed but planned.

Variety of stats, including: 6 damage types with unique properties and armor to match each, recovery, regeneration, health, salvage ability, and more.

The ability to not worry about all those stats and still have fun!  

Gravity changes depending what world you're on, what location in the world you're on, and the environment.  Yes - you can get things in orbit on smaller bodies.  Yes, there is no gravity at the center of worlds.  Yes, if you dig a GIANT hole, you can enter an endless loop falling through each side .

And much more!

--------------------------------------------------------

Most importantly, I would love feedback on the video I've shared and opinions on the ideas I'm integrating into this game.

I am posting here first because I am using SFML as my graphics library, and I wanted to express my great appreciation for such a wonderful library, and I am proud to be using it in my game!

Thanks, and I'm looking forward to hearing your feedback!

Thomas Pereira

11

Graphics / Copying a texture from one RenderTexture to another

« on: March 19, 2012, 05:56:08 am »

The issue of precision was a non-issue.  Additionally I converted the system to manually transform instead of relying on the view transformations and, unfortunately for me, had the exact same result as allowing the views to handle the transformations.

I'm stumped, but as for the topic of this thread, copying the texture was not the issue since I achieved the same result with view transformations and manually applying transformations.  Which naturally is indicative that the texture copying I had implemented worked properly. So I suppose the matter is closed, since I imagine this is now an issue of transforms.


UPDATE:

Problem solved!  The issue was that float-precision is not saved on a per-pixel basis it seems.  So I would offset the image with float precision, and (I believe) it truncates it to integer precision.  This would cause some noticeable deviation from the properly transformed position after enough small-iteration translation.  I feel pretty dumb, because I made a stupid assumption to begin with.  Anyway, ensuring the deviation is always an integer value makes sure there is no discrepancies.  I apologize for making a thread to begin with, considering it's all been me talking to myself.  Hopefully this is helpful to someone.

12

Graphics / Copying a texture from one RenderTexture to another

« on: March 18, 2012, 09:35:26 pm »

Alright well I am officially stumped on this problem.  

After further experimentation, I seem to be copying the texture just fine.  If I wasn't, the texture would spiral downward or upward in size because of the rapid back and forth transfers.  This is not happening, and the image is stable.

When I offset the texture, however, the coordinates don't seem to match up.  And there is absolutely no pattern that I can recognize.  It doesn't seem to be a floating point issue, either, as I used whole numbers for all the values and it still has a precision issue.  Sigh.

UPDATE:  At close zooms, the offset seems to function properly.  At larger zooms, it functions properly only at certain values.  This is definitely indicative of a floating point error.  I'm just not sure where it originates from -- I can't seem to find any errors in that regard within my code.  

I'm changing all the values in SFML's transform code from floats to doubles to see if that fixes the problem...I'll update with the result.

13

Graphics / Copying a texture from one RenderTexture to another

« on: March 18, 2012, 07:03:24 pm »

I believe I found the issue.  I make the scaling variable, and I compared that variable to the result of this:

Code: [Select]


renderTexture[buffer].convertCoords(1, 1) - renderTexture[buffer].convertCoords(0, 0)

The conversion deviates from the variable at it's 100th and 1000th places, a significant deviation when you have large scaling factors being applied.  I'm investigating the issue further.

14

Graphics / Copying a texture from one RenderTexture to another

« on: March 18, 2012, 06:40:54 pm »

The texture ALREADY has all the transformations, you see?  So if I copy the texture over, it applies the transformations a second time.  I switched over to using the SFML transforms, and frankly, I'm not sure how to directly reverse the effects so that when the transforms are applied again a second time they are correct.  

An easier method would be to avoid the transformations all together and apply the texture without transformations.

So to answer your question, I'm transferring the texels + transformations, primarily because it's the only method I know of/can find for SFML.  The result being a transfer of texels + transformations + transformations, which I want to avoid, because it seems there is a loss of precision when using the internal conversions.

15

Graphics / Copying a texture from one RenderTexture to another

« on: March 18, 2012, 07:39:34 am »

Hello,

I feel bad about posting another question so soon, but again, after a whole lot of experimentation and an inability to find information on the topic, I find myself back here for help.

Let's say you have 2  identical RenderTextures, renderTexture and renderTexture[~b].  Both have the same transformations applied to them, let's say, for examples sake, 2.0f zoom factor.  When you draw a sprite with renderTexture's texture onto renderTexture[~b] with a sprite of origin 0,0 and position 0,0, it will draw the sprite at transformed scale (since zooming is the only transformation applied).

In order to combat that, let's say you setScale the sprite to 2.0f.  Logically this would seem to work, but when you offset the sprite it seems some precision is lost in the transformation.  I will post some example code to illustrate the problem:

Code: [Select]



//Example code showing the transference of the texture
//Keep in mind that each RenderTexture has a view applied which
//has a zoom of 2.0f
//buffer variable is a bool
//handleTexture variable is a pointer to ~b's texture
renderSprite.setOrigin(0, 0);

renderSprite.setScale(2.0f, 2.0f);

//Offset by 32 pixels
renderSprite.setPosition(32.0f, 0);
renderSprite.setRotation(0.0);
renderSprite.setTexture(*handleTexture, true);
renderTexure[buffer].draw(renderSprite);

                buffer = (buffer ? 0 : 1);



My gut tells me it may have to do with some floating point math truncation in the computation of the transformation, but I could just be doing something totally stupid and just need a fresh perspective to point it out.  Thank you!