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!


markr

Member Since 23 Mar 2004
Offline Last Active May 09 2014 04:40 AM

#5119349 A diffrent type of rts.

Posted by markr on 26 December 2013 - 02:13 PM

Did you play the 1996 Bullfrog game "Genewars" ?
 

http://en.wikipedia.org/wiki/Genewars

 

It had some similar ideas.

 

If it's still feasible, get a copy :)




#5102943 Javascript - access data of a file local to the document

Posted by markr on 20 October 2013 - 03:13 PM

You need to "notionally" do network access to get these data for images. But the images might come from the browser's cache if they're already available. You can encourage or enforce caching through a combination of web server headers and a cache-manifest file. Or you can just preload your images when your game starts so they're already available.

 

Once you have an Image object in memory, and you're holding a reference to it, it's not going to go away and you can use it without a problem. But when a player comes back to play the game again (in the same browser session or a different one), the assets need to come either from the server or the browser cache.




#5102619 Javascript - access data of a file local to the document

Posted by markr on 19 October 2013 - 08:00 AM

Image elements don't work on that level. You can't ask the Image object for its binary data. You can in principle extract the pixel data from an image, which might be an idea for loading maps or other assets.

 

If you want to do file IO for arbitrary (non-image) files, use XMLHttpRequest.




#5098550 Using global variables - really so bad?

Posted by markr on 03 October 2013 - 01:54 PM

Really having a few globals hanging around is not so bad, especially if they are in their own namespace and there aren't *too many*.

 

So if you have a few "big objects" which you want global instances lying around, then use globals, it's not really a problem.

 

The problem really starts when:

 

* The maintenance programmer can't tell which variables are globals / members / locals etc, easily

* There is so much unstructured global state that it becomes easy to get "stale data" bugs.




#5098362 Would multiple std::vectors be too slow?

Posted by markr on 02 October 2013 - 04:06 PM

It is extremely unlikely to be a problem.

 

You need to think about macro rather than micro. Use the simplest scheme that you think might work.

 

The key is to avoid anything which is greater than O(N) on a regular basis (e.g. each frame). Even the N^2 "every object against every other object" is not really so bad provided the number of objects doesn't get too big.

 

It's really possible to iterate a lot of vectors - really, lots - each frame, without problems.




#5098333 Maps or level editors

Posted by markr on 02 October 2013 - 01:54 PM

A mixture of the things you said.

 

In the past I've used all these approaches. I'd recommend that you don't spend time building your own editor, if possible.

 

* Use a text-editor to edit a text-file, and have the game load it as a tilemap of some kind

* Use an existing tilemap editor (designed for games)

* Use a graphics bitmap editor (e.g. Gimp) and edit a bitmap; load it as a tilemap, background, collision map or something like that.

* Use an existing vector-editor (Inkscape, Flash) and convert or load the files in your game

 

In some cases it might be helpful to convert data into a different format for use at runtime.

 

Object placement and definition of logic e.g. "this button opens that door" can be tricky to do with standardised tools, you might need to knock up an object-placement editor, which could easily be inside the game itself (you run the game in a special mode, perhaps use a command-line option)




#5096788 Code review for my first game ?

Posted by markr on 25 September 2013 - 03:17 PM

You have several typoes or spelling mistakes in code or comments, these are confusing or annoying to a maintainer but not really a problem (most notably SCREEN_WITDH)

 

There are a lot of global variables, some of which are not very descriptive or helpful, e.g. event / gameEvent. You might reduce the global variables by combining some of them into structs and/or putting them into arrays or some other container. It's also possible that some of them don't need to be global at all, and can be passed as parameters instead and/or held in a local somewhere.

 

Your variable and function names are not very descriptive and a maintenance programmer will need to refer to their declaration comments a lot. "state" might be better as "board_state", then we know what it's the state of. (conceptually, every variable is a state of something). Some function names don't start with a verb, for example "position" or "score".

 

"using namespace std" - I could possibly get into a Holy War over this, but I prefer not to use this nowadays.

 

Function position() ... this function needs the most work.

1. It is trying to do at least two things at once - determine the mouse click target and draw things on the screen. Logically, I'd try to separate these two operations

2. It does many rectangle-tests for the mouse-position, it looks like these could easily be refactored into an array or something else.

3. There is a great deal of repeated code

 

I suggest you might refactor position() into several stages, possibly different functions:

a. Determine whether the mouse-button has been clicked on a square, and which one

b. Check whether the square is a legal move (i.e. not already taken)

c. Draw the mark in the box

 

Obviously I can't see what's in your background image, but I suspect that the board has a regular grid, so you might be able to use a bit of arithmetic to work out the boxes' coordinates programmatically and not have to hard-code the locations of 9 squares.

 

However, if your tic-tac-toe grid is highly irregular, you could make an array of structs to store their coords thus:

 

struct myrect { int x1,y1,x2,y2; };

myrect rects[9] = {

  {30,25,210,165} , ...

 

}

 

Or whatever the correct syntax is!




#5095245 Question about programming in team, and svn...

Posted by markr on 19 September 2013 - 01:55 PM

The tinkerer problem cannot be solved technically, it's something which has to be done culturally within the team.

 

Not only is "tinkering" highly annoying for other developers who have to tolerate merge conflicts, it's actively a problem because tinkering creates bugs.

 

Only when you have a culture of "if it ain't broke, don't fix it", can the tinkering be prevented.

 

I prefer the matra "Even if it is broke, still don't fix it until we have a bug report which has been triaged and scheduled into the release you're actually working on". Occasionally people fix bugs by accident though :)




#5095029 Question about programming in team, and svn...

Posted by markr on 18 September 2013 - 03:15 PM

In general, some level of collaboration is necessary to avoid doing the same thing.

 

If several people are working on the same file, normally they'll be doing unrelated things.

 

Whoever commits first, "wins" and the other person has to do a merge. Doing the merge is not normally particuarly difficult, but it can easily go wrong.

 

One of the biggest problems is if you have another developer who is a "tinkerer" and randomly changes stuff (e.g: comments, whitespace, random refactoring) not related to his tasks. This creates unnecessary merge work and gives other developers pain.

 

If you have such a developer on your project, and you are unable to convince him so stop such behaviour, your project manager should be involved.




#5095020 MMO Network Layer Architecture

Posted by markr on 18 September 2013 - 02:57 PM

I think you are really trying to "put the cart before the horse". If you're *really* making a MMO, then the funding you have for content-creation should mean that you can afford to hire some experts for the network parts.

 

On the other hand, if you're making a smaller online multiplayer game (which is fine, too!) then you really don't need to worry about "the C10k problem". Pretty much any approach will definitely work.

 

Personally I can't really see a situation where any amateur-developed game is likely to hit the limitations of networking, unless you've made some incredibly bad decisions on the protocol design - which is something you should really think about early on.

 

There are a lot of hard things about network game programming, and the things you've mentioned are not part of them.




#5094946 Python 2D game engine

Posted by markr on 18 September 2013 - 08:58 AM

Pygame all the way, for a beginner.

PySDL2 and Pyglet are good and gaining traction, but I would really recommend pygame if you are starting out.

None of those are game engines. That's not to say they're bad libraries though.

 

Personally I suspect that you don't really need a "game engine", especially for simple 2d games. If you find a suitable engine, great. If you don't, it's not a disaster either, your game might work just as well with a custom-written one especially if it's simple.




#5093982 External Javascript file not working

Posted by markr on 14 September 2013 - 05:53 AM

You have misspelt "Javascript", as "javacript". I don't know if this matters.

 

Personally I'd try loading the page with the debug console open and watch the requests to your http server. You should see the request for the .js file.

 

If you get a 404 error or something, then you'll be able to see what the problem is.

 

I would also recommend that you don't use the old, deprecated "DOM0" "onload" or "onclick", and instead use DOM events. I normally do something like:

 

window.addEventListener("load", my_main_function);

 

Somewhere in my main script.

 

The big advantage is that you can have do this in several different places and have them all happen, but there is only one onload attribute.




#5093784 How do I implement gravity after walking off a tile?

Posted by markr on 13 September 2013 - 08:46 AM

The way gravity normally works in game (and incidentally, real life), is that it is *always* pulling objects down. If they happen to be on a solid platform, the platform is continuously pushing the object back up, so it can't fall. Assuming you use Euler Integration (if you don't know, you probably are.), you're storing a velocity vector of the object, then if you get a collision with a solid thing like the ground, you'll want to modify the velocity to remove the component which is going into the ground (in practice, this is something like: if (velocity.y < 0) velocity.y = 0; ) Mark


#5088200 collisions? n^2 checks?

Posted by markr on 22 August 2013 - 03:46 PM

Keep it simple, if the checks aren't too many for 100 objects, it's fine. Obviously this depends on hardware speed and the difficulty of the check.

 

Normally you don't actually want to test 100 objects against all others, some collisions are "deliberately ignored", for example, you might group them into "player objects", "enemy objects", "player missiles" and "enemy missiles". It's likely that only some combinations of these groups need to be tested, so you can dramatically cut down the checking by only checking "interesting" types against each other.

 

If most of the objects aren't doing anything interesting (e.g. they're outside the screen AND not moving) then you could also ignore them somehow.

 

There are a variety of optimisations which are not as "cool" as world-partitioning or something else clever (e.g. some kind of spatial index), which are much easier to implement and work nearly as well for relatively small numbers of objects. Keep it simple.




#5087795 YAML vs JSON vs XML?

Posted by markr on 21 August 2013 - 07:31 AM

Remember the various securitypitfallsof parsing XML from an untrusted source. If you're not doing that, then you're fine though.






PARTNERS