Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 24 Apr 2010
Offline Last Active Private

Posts I've Made

In Topic: [web] Updating Players - Tick / Time / Realtime

21 January 2011 - 04:21 PM

Damned new design, wrote a nicer post and hit the wrong button... So here's my main points:

touch_the_sky hit it pretty well, but don't update statuses like that. Player hits 'Create Building', create a DB entry with 'building_complete_time', and use that. You don't have to touch the entry again for maintenance purposes: queries like 'GET player_X_buildings WHERE completed_time > NOW' gets you incompletes, queries like 'GET player_Y_buildings WHERE completed_time < NOW' gets you all active/complete buildings. Calculate remaining time with completed_time - NOW. No issues here with long no login times, no extra DB queries/updates, almost no time/date functions (or, hell, math! just addition/subtraction) if you use *nix timestamps.

CygnusX has a point on realtime gold/energy/people/etc from buildings. Buildings producing goods is a simple compounding interest problem you can best solve by putting in a once-a-day/login/whatever time for those benefits to be gained (or cron, if you're so inclined, especially if you need to run other external maintenance/cleanup that way). If you HAVE to have those gains in realtime, your best bet is probably a separate process/DB to maintain everything separate from the game load, but that's still going to be slightly off and hard to maintain. You're basically running/writing banking software and/or stock markets at that point, and while it's not impossibly hard, it's probably more of a headache than you really want (unless you're that kind of math geek! :-P)

Just think in terms of data for now. Many large games (even running in realtime almost identically to what's described above) end up using regularly scheduled cronjobs and such but it's often a byproduct of load balancing or maintenance (meaning account security, checking for h4ckz, pruning old data, etc). Since those tasks end up getting optimized to hell and back and have to touch every account anyway, some things can be put in there to get a net gain (slower scheduled task, faster per user) in performance. None of that should matter at 1000 (or even 10000, sometimes even 100000 depending on DB size and host) users, though. Splitting any turn-based game (meaning you do X tasks over Y time) into chunks crunchable by an optimized cronjob is typically preferable, though, as it's a few minutes of server strain versus a constant moderate load (visible in page loading).

In Topic: A new sort of development environment

04 October 2010 - 05:48 AM

I don't get it.

I mean, I understand the parse tree storage (is that different from Intellisense/all other similar functions?), but that doesn't seem new. You could keep your asset/source/update/etc information in a database with that information already -- using many existing version control systems.

How are you ditching the "file system?" Those "files" still exist SOMEWHERE. You still have to reference them somehow. Say someone writes a class that will load, parse, and play music files: How do I use that in my code? #include "jbob/music" ? use "music by jbob" ? I suppose you could automate grabbing the necessary sources from your parse tree DB, but is that really much of an improvement? How would you handle conflicting/redundant naming? I can't be the only person who's had to use several different IManagers in a single project. Wouldn't you end up doing things like jbobs::SoundManager vs local::SoundManager?

AFAIK real-time builds are restricted by server availability and dependency/asset matching and good structures automate tests now.

Basically, I don't get it. What does this environment help me do better?

In Topic: Separating game logic, input and display

02 October 2010 - 08:47 AM

I think most MVC (for GUIs) explanations leave out the "you need to design around your input" bit. They rarely say you need to figure out what your internal logic needs to get from the user and there's your model (the logic + open-ended input). Ideally, that bit of code can be totally decoupled from the VC and tested separately.

Since I do a lot of web programming, I like to think of the Model as my application, the View as the page shown to the user, and the Controller the link or <--> between View<-Controller->Model. Again to use chess, the model should take in moves and spit out what happens (eg: move rook->rook takes pawn). The controller takes input (eg: "E5 to E2", or "Tile33821 to Tile43832"), changes it to what the model needs ('BR@E5 to E2'), receives the response ('BR@E5 takes WP@E2'), and finally changes that into whatever the view needs ('Black rook takes white pawn', 'Animate Tile33821 to 33,23,53;Tile33821->AttackPawn'). Your text view may simply echo the response and wait for input, your graphical version may have a castle stomping a screaming pawn into oblivion. The point is that those actions are totally separated from the logic. With a proper MVC, all you need is the input information to easily add new views OR logic. One can even be coded without the other: you use the controller to make sure the back and forth is "as expected."

Where lots of people seem to have trouble is that oftentimes the View requires more code than just GUI. Don't be afraid to add separate code to the View -- for instance, when the page loads 'IMPORTANT_MESSAGE_A' it should flash on top of the page, all others should appear normally. This will require a logic check, but also BELONGS in the View (or an overdesigned Controller). The graphics rendering loop SHOULD animate attacks and movement and such, even if it requires checking logic similar to the Model (that is, doing more or different things depending upon what the Model says). The Model shouldn't be doing any of your graphical work.

That all seems to be a longwinded way for me to recommend overengineering the Controller (!). If you write a solid Model that runs your game and an awesome View/interface (or 4) to show it off, then you can get a bit hacky with the translator/Controller to make them fit together. Your code is still organized and easy to debug* even if the design feels messy.

* - By using this checklist:

Correct data leaving the View? (No: View, Yes: Continue)
Correct data entering the Model? (No: Controller, Yes: Continue)
Correct data leaving the Model? (No: Model, Yes: Continue)
Correct data entering the View? (No: Controller, Yes: View)

You know exactly what piece of the code has the problem and can independently test any section.

In Topic: Separating game logic, input and display

29 September 2010 - 09:16 AM

If I'm reading your description correctly, you can separate the controller and view in the graphical display by having the display maintain itself until the model decides something needs to change. I'd image a board game could just continue showing the last frame, adjusting for input (eg: mouse movement, selection highlighting) -- though arguably that kind of behavior should be handled by the model.

Realistically, particularly for complex graphical environments, you'll need a "graphics model" of some kind to handle all the extra processing the visual representation needs. Much of that (if not all) can be decoupled from the game logic but it still has to happen somewhere. In other applications, I've included that code towards the 'view' end of MVC. The renderer (if you know what I mean) needs to keep track of ongoing animations or visual cues or whatever but my game routine doesn't care.

My way of figuring out how to handle generic input is to figure out what I need to do (using the application) and what my logic needs to know. I'll use chess as an example:

Playing the game in text, I say '3A to 4B'.
Playing the game visually, I click a piece and click the square to move.

My game loop needs to know piece or original location, and new location.

I have a one step (text) and two step (graphic) system that needs to be standardized for my game logic. So, I can add a "piece selection" step to the text display (making it two steps), where I send 'selected piece', receive possible locations, then send new location; or I leave it at one step (A to B, OK or NO) and leave the visual cues to that display.

The two step solution is probably the purest MVC solution, but I'd use whichever fit best. Don't get too hung up on an elegant solution if you can find one that makes sense for you.

In Topic: [web] 2 player turn battle script crashes.

29 September 2010 - 06:37 AM

Since the browser is crashing after running out of available memory, your problem is in your ajax responses. You are either sending too much data or the JS is hanging somewhere. Try watching your network traffic and the live DOM to see what's actually going on during each load using Firebug or whatever dev tool you prefer.

Glancing over your code, you've got some strange things going on I don't understand. For instance, this block:

<script type='text/javascript'>

function turnlistener() {

$(function() {


You keep resending turnlistener() unnecessarily. You only need it once.

Use the $(document).ready() method OR the passing a function as an argument to jQuery method, having both is messy and redundant. But actually, use neither: The initial page load can directly insert the opening battle sequence. Your second player should begin longpolling at that point, waiting for the first player to act. Your response to the first action should start that player longpolling, after the second player sees the action you should stop polling and allow him to act.

You have a lot of XHTML/HTML/CSS mistakes along with the goofy JS structure. Try removing all the backend logic to test your interface/ajax. Make a simple backend in PHP that simulates a typical battle (just generates the next stage of results whenever a player acts) and watch what happens.

You say you're using JSON, but you aren't. That's not how .load() works and not what battlegetnextunit.php responds.

I'm assuming your combat logic works (haven't looked hard at the code), your weak spot (and the bug) lies with your client-side code and server responses. Read over the jQuery API and some ajax/HTML/CSS tutorials to fix your logic and make your life easier.

Hope that helps.


While there are many reasons classes are good, the example Cygnus gave isn't one of them. The reason is option 3:

function round($x, $precision=0);

round() will continue to work as expected in the legacy code but now include a precision option. This is also how you would want to change your $Math->round() method, not by setting member variables in the constructor.

Rewriting your code to include a player class to get rid of all your duplicated loops and hard-to-read code is a spectacular idea. Game units lay very neatly into the objects that OOP is meant to express, take advantage of it!