Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


Waterlimon

Member Since 28 May 2011
Offline Last Active Today, 01:01 PM

Posts I've Made

In Topic: is there a name for this type of data structure?

16 December 2014 - 11:50 AM

How about you call it the "manager pattern"?

 

You could have playerManager, cloudManager, treeManager... And you could use a "Manager" base class so you can have a list of generic manager classes and update them all at once in the managerManager.


In Topic: The Game Environment: Not just Graphics

16 December 2014 - 11:24 AM

I think consistency is more important than utilizing all the senses to the maximum extent possible.

 

In my experience, playing something like dwarf fortress is more immersive than a visually stunning game.

 

 

Like a book, the more your brain has to work to imagine the world, the less surprises there will be and thus less potential immersion breakers. Plus when you have to imagine much of the world/atmosphere yourself, you will be more focused to the content and this also increases immersion (and youll actually remember the general atmosphere/immersiveness better than if it was just a result of external input)

 

If you want the game world to be perfect, let the player imagine it, the mind will simply assert its perfectness with no basis at all.


In Topic: Limit Theory update #21

15 December 2014 - 10:32 AM

Ahh, I meant he! I wasnt aware that he wrote the music himself though, pretty impressive!

 

You can never be sure, maybe its procedurally generated... laugh.png


In Topic: Displaying fleets on the galactic map (warp)

15 December 2014 - 09:51 AM

When the fleet is stationed at a planet, the user wants the fleet associated with the planet and planet associated with the fleet:

Fleet <=> Planet

 

This is trivial by displaying them together. If you have a global list of fleets, make sure you can easily discover the planet its on and same for list of planets (again trivial).

 

When a transfer is planned, the user wants the following:

Source <=> Fleet <=> Destination

 

The source needs to be known given the fleet because the user can cancel the transfer still and this changes the state of the source as well as the destination.

 

When a transfer is in progress, the user wants to know:

Fleet <=> Destination

 

The source is irrelevant because whether the transfer exists or not is irrelevant to its state in the present and in the future because you cant cancel transfers in progress (the destination is relevant because its state will be changed when the transfer is complete)

 

So I would say that during planning, you could display something like

 

[RealPlanet (source)] -> RealFleet -> [VirtualPlanet (destination)]

near the source planet (so when you look at the source planet, you see that the real fleet that exists there is about to transfer to the destination planet (the virtualplanet could be a stylized representation of that planet, a pair of coordinates, a planet name, a button you can hover over to show the actual destination planet wherever it is...)

and

[VirtualPlanet (source)] -> VirtualFleet -> [RealPlanet (destination)]

near the destination planet to show that you have planned a transfer there, with virtual 'links' to the fleet and source planet in case you need to change something

 

During transfer you would remove the stuff near the source planet and remove the [VirtualPlanet (source)] from near the destination planet, only leaving the VirtualFleet symbol thingy.

 

Visually it could be like

 

(earth) Fleet1> -> [(Moon)]

[(earth) Fleet1>] -> (Moon)

 

looking at source (earth) and destination (moon) respectively. Basically everything that is located somewhere else is made 'virtual' (represented by [brackets] here)

 

Visually it would make sense to direct these incoming and outcoming fleet indicators such that they point toward the dest/src planet if possible, because the user probably maintains some kind of spatial map of the world in their head and uses this spatial map to remember what is going on where, so the spatial information is important in both quickly remembering where the fleet was going (without reading the details) as well as why ('oh yeah I have this massive celestial clash going on with that pirate faction in the top right corner of the universe, so this fleet must be going there') (this would allow you to even hide the source/dest details if the screen is too cluttered since the directional information should help the user remember that information to some extent)


In Topic: New steps to take to improve my programming skills

13 December 2014 - 02:21 PM

What you need is:

-API to create window and other OS interaction like I/O (win32 is lowest level youll get I guess on windows, but I suggest some nicer API to wrap the functionality so its not so ugly, like GLFW or something like SFML for simple games, SDL is popular too I think)

-Buttons and interaction with them using either some UI library, or by coding your own using a graphics API (OpenGL, DirectX) + input using the above mentioned OS interaction API

 

This is assuming C++

 

If you were to use a graphics API (or the higher level libraries like SFML, SDL) to make your own UI, you would create a window, then possibly initialize some sort of graphics device/context/whatever and use the functionality provided to draw some boxes in a loop and then do some basic programming to code the interaction based on mouse/keyboard input from some other API.

 

Dont know how you would initialize an UI library, but using one should make it much easier to input/output textual/numerical information (which is very tricky to code yourself)

 

Using C++ cross platform means that you implement OS specific code separately for each platform. Cross platform libraries do this so you dont have to (but if you dont use cross platform libraries you might have to lets say implement the same functionality using lib A for windows and lib B for mac)

You would then compile a separate executable for each platform (and the correct platform specific code will be compiled because it was set up that way).

 

I wouldnt worry about cross platform for now. Just find a library/API for your language of choice that can get buttons on the screen (+whatever APIs you need to support it) and that should be enough (Im assuming it also allows effective manipulation of those buttons through code...)


PARTNERS