next »

[ITS_Mike]

Woah, I love the style of your iso graphics so far; it looks nice and dark. The mechs look a little out of place with all the desaturated colors though.  Was that a design decision to make them stand out more?

[Gregg Williams]

Thanks lad for keeping us in the loop, hope it brings money on the table

Cheers It should, though I'd much rather be working on M.I.N.T

Woah, I love the style of your iso graphics so far; it looks nice and dark. The mechs look a little out of place with all the desaturated colors though.  Was that a design decision to make them stand out more?

My partner does the art, so take this as a fine grain of salt, but yes I'm sure thats the reason. Also the palette is not finalized, and the game will certainly be featuring different army/player color schemes as well. With hopefully in the final end, the ability for you to build your own custom army palette as well.

[Gregg Williams]

Frustration..

http://blog.retromite.com/2013/08/weekly-update-08212013.html

Hope to be back here soon..

[Gregg Williams]

Alright Gravitum is wrapped up, and live!

Oh let me fly back to M.I.N.T and have its armour shield me from such future distractions.

[Gregg Williams]

Returned to work on M.I.N.T today, man what a couple weeks away from the code base can do to you..

Started to try an work on wrapping up the whole command queue thing, but hit a few mental road blocks and ended up penciling out some more architecture and design notes. So now I think I have a decent plan to actually implement things come tomorrow.

Going a bit more abstract than I like to do at times, as I'll end up making an actual command class, and subclassing it for specific commands. The benefit of this being that I can keep the client's main loop clean, and put the bulk of custom logic in the command classes.

So something like a MoveUnitCommand, would know how to use the client camera to fly to the unit to move, then start all the moves, and so forth until it finally reports that the command is done, and can be discarded. Theres a lot of state stuff to track at times, so I think the command class approach will likely pay off in the long run.

[Gregg Williams]

Alright client retrofit to be command based is completed, and several commands like NewTurn/AddUnitToMap have been created and ported from the old packet handling code. The command queue system is also now in place on both the client and server side, though needs further testing.

Moving on to actual server side movement verification/allowance and updates to connected clients.

[Belimoth]

Neat

[Gregg Williams]

ARGH! Universe hates me working on M.I.N.T... Jeep transmission is now not upshifting right..

[gokimen]

Hey, seems like you have made progress but forgot to update your progress bar, just want to remind you 

oh, nice looking game btw, animation is smooth and appealing. and sure MECHS! 

[karlozalb]

Meechsssss yieah!

[Gregg Williams]

Hey, seems like you have made progress but forgot to update your progress bar, just want to remind you 

oh, nice looking game btw, animation is smooth and appealing. and sure MECHS! 

Cheers, 10% huh? hmm. I guess that might be fair, especially when once you hit 90% game dev percentage flops back to 0%.

[Gregg Williams]

Oh well 12 hour day working on the jeep, but after changing fluid, filter, adjusting throttle cables, redoing electrical bits, and re-adjusting throttle position sensors and so forth the jeep transmission seems to be behaving so far.

I'm hoping that it continues to do so, the fluid was pretty dark, but surprisingly the tranny itself was quite clean and there wasn't much metal stuck to things. This is on a 210k mile transmission that I have no idea if the fluid was ever changed on.

Back to the glory of M.I.N.T

[Conker534]

Back to the glory of M.I.N.T

every time you say this something breaks, its bad luck!

[Gregg Williams]

Back to the glory of M.I.N.T

every time you say this something breaks, its bad luck!

=/ you may indeed be right, one might even look at all of it as a sign that the project isn't suppose to happen. Screw that the show must go on

[Conker534]

You'll get back on track eventually, I used to work on Witch Princess every day, now I haven't even touched it in a week, makes me sad, but its proof that there is ups and downs in production!

[Gregg Williams]

You'll get back on track eventually, I used to work on Witch Princess every day, now I haven't even touched it in a week, makes me sad, but its proof that there is ups and downs in production!

Yeah lots of shit happens, especially when your also doing contract work at the same time or going to school, etc. Although we don't have any more games sitting around in auction for months to suddenly interrupt me for a few weeks now Just the occasional possible secondary license, which is hard to pass up as often those work out to 100-150/hr to do.

[Pemanent]

Yeah man my development consistency cycles a lot. Really what it comes down to is my love for games... I just know that eventually I'll come back. Taking a break isn't bad, as long as you come back.

[Gregg Williams]

Worked on the server side portion today. Ran into a few C++ problems, no doubt due to some in-experience in using stack allocated objects and references vs pointers for most everything. Which is something I've been trying to do more often overall to make bits of code simpler to use.

Like most packets can just be declared as something like NewTurnPacket p; Then sent to a connected client like netstate->send(p); and the packet when leaving scope will be deallocated, release buffers back into pools and so forth.

Its been great, right until I added the server side command queue packet which I designed to hold packets inside of it.. Played with that a bit, but ended up just going back to pointers in the end. Oh well

Coded up a bunch of server side map specific functionality for movement and pathfinding. Also coded up all the movement request, acknowledgement, rejection packets, and coded up the initial super early server side movement flow.

Overall should be within close striking distance of networked movement working happily along with the whole networked command style architecture.

Although I expect to be pulling my hair out a bit more once things like visibility and player specific information goes in.

[Gregg Williams]

Alright lost about an hour or two due to a packet being off by a byte, and also an error with sending a single packet to multiple players, where after the first send, the packet length could be returned incorrectly, thus causing the client side handler to not recognize the packet stream.

So after those joys.. (Networking is a joy always remember that.) network movement is working in its super basic form Now to make the units actually animate/slide properly with networked based movement, and hammer out some more client interaction state logic.

[Gregg Williams]

*Grumble*

So movement is working, but apparently some of the pathfinding and move map systems are having problems dealing with units blocking tiles and are behaving in interesting ways..

Very interesting ways given that the debug hues there show correct blocked/unblocked tile data, yet both the movement map and path preview are whack.