|
323
|
Developer / Technical / Re: Picking out a Linux distribution for development
|
on: March 09, 2013, 07:18:14 AM
|
|
Isn't Fedora recommanded for development because they are always up to date with libs?
I used Ubuntu but didn't use it these last years. I want to use it later but the instabilities reported here and in other threads makes me think it might not be a good idea.
|
|
|
|
|
324
|
Player / Games / Re: Torment: Tides of Numenera
|
on: March 09, 2013, 03:32:19 AM
|
idk what you guys are doing but i just went into offline mode from the client 3 times in a row then i disconnected my internet and tried it again and it still worked.  i read deleting clientregistry.blob supposedly helps if ur having trouble Actually it was doing this on my last computer, but on my current one it don't. Maybe you didn't update the Steam client?
|
|
|
|
|
326
|
Developer / Business / Re: Project Scheduling
|
on: March 08, 2013, 01:00:42 PM
|
|
I did this like 6 years ago but it wasn't really useful in the end, I mean it's the same as sending yourself emails. The only difference is if there are other people who will join your team which was not my case. But the discussion thread concept is good, I keep emailing myself with this.
|
|
|
|
|
327
|
Player / Games / Re: Torment: Tides of Numenera
|
on: March 08, 2013, 05:16:09 AM
|
|
That being said, it's the basics of the story that totally convinced me that it might be a game I really really want to play.
|
|
|
|
|
329
|
Developer / Business / Re: Project Scheduling
|
on: March 07, 2013, 01:19:18 PM
|
|
Holy shit I just figured that I now have a smartphone that can live more than one day without dying and there is a Trello app! That might partially fix my need for paper... I'll try see how it goes.
|
|
|
|
|
330
|
Developer / Business / Re: Project Scheduling
|
on: March 07, 2013, 12:45:49 PM
|
Well, I think you can always print out the checklists if you need to work off of them on the train, and if you to add stuff it's not too hard to just jot it down and add it to your online worksheet later.
Really it's more me not having a way to make sure I can work regularly at the same place, or even print something or even be connected when I'm using my laptop. Once I got a desktop and a more permanent place to live, I'll certainly setup a Trello. Don't bother about paper if you don't feel like it. That being said, I like to make drawings, use my hands (to write, you pervert) when I'm brainstorming or just listing my needs. So I'm inclined to use paper or a drawing board first. By the way, I've used and mastered tons of issue trackers before, even learnt linux server setup doing so. So I know that working alone on a project with an issue tracker is very time consuming and not a good idea in the end. However Trello works great because it's instantaneous setup and you organize it immediately without configuration.
|
|
|
|
|
331
|
Developer / Business / Re: Project Scheduling
|
on: March 07, 2013, 03:02:24 AM
|
|
I've been considering Trello for some time too, but I kind of fear having everything online, in particular todolists. Which is why I still use paper. It's unperfect but can use it in the train or somewhere I don't get internet access. But I guess I'll use Trello in the future.
|
|
|
|
|
332
|
Developer / Technical / Re: Best Practices for Saving Game State
|
on: March 05, 2013, 03:40:51 PM
|
|
Just a general advice about the subject: if (it's not always necessary) and once you figured that you need saving game state AND after you pass the prototyping stages (when you start to make the game more seriously), then DO IT AS SOON AS POSSIBLE.
As soon as you have the first versions of the game state working, do the saving code NOW. It's so helpful both in debugging and in fixing now problems that you might discover only at the end, when you're crunching to release your game.
It is not mandatory, but if you manage to have a simple way to update the game state saving code when you add new state data, having started early writing this code and upgrading it progressively by reflex will help you a lot. The best way (but it can make things complex if you use a language with no complete reflection like C++) is just to setup the code that save so that you write it once and it's automatically in sync with your game state data. But as said, in some languages it can make things only complex.
|
|
|
|
|
334
|
Developer / Technical / Re: Is having no offline support frowned upon?
|
on: March 03, 2013, 12:19:15 PM
|
Yeah other platforms are available but my previous research seems to get to this point: - the ones the most usable are not cross-platform; - most forces you to use a ugly application for updating, while what I need is just a library; - there are libraries, but most of them are not finished or not tested enough yet; - some platforms provide stores and apt-get which don't match the game's use; So basically if I want to sell games from my own website, that is, not Steam, not Desura etc., there is not yet a sure way to do it. I'm tempted to use Karazeh as it seem to match my needs but Amireh told me he can't work on it for some time so it's not sure it's production-ready yet. In my eyes the scariest thing about the autoupdater vulnerability is the prospect of being held liable or getting a bad reputation in the wake of a mass-hack. While it's only hypothetical, it seems like that kind of publicity could tank an indie's career. :/ Yeah, legal stuffs can crush you hard. :/
|
|
|
|
|
335
|
Developer / Technical / Re: Is having no offline support frowned upon?
|
on: March 03, 2013, 07:55:49 AM
|
A serious, important warning: Autoupdaters are dangerous. Hijacking them is the easiest.
This is both true and depressing me more each time I think about it because the game I'm making relies on updating regularly the game content with binaries. Consider implementing a scripting language in your engine. Eg: drop LUA in, but not LUA w/ JIT (that runs as machine code). There are other langs available. Lots of folks make their own with flex/lex and yacc/bison from a BNF grammar. The point is that the game logic updates could then be all sandboxed as 'op-codes' that your engine supports, not raw hardware access. Obviously! But can't work for this specific project. I wouldn't have this problem otherwise.
|
|
|
|
|
336
|
Developer / Technical / Re: Is having no offline support frowned upon?
|
on: March 03, 2013, 06:27:55 AM
|
I agree with what these guys say -- account for situations where your server goes down or your user doesn't have internet. Honestly I'd ship *some* version of the resources with the initial download, just so users who aren't connected when they later unzip aren't messed over.
Anyway.
A serious, important warning: Autoupdaters are dangerous. Hijacking them is the easiest, most effective way for a blackhat to distribute malware -- in one move they can bypass system security for every user of your app. Unless you have extremely strong security measures in place (certificate-based encrypted connection between game and server, server administration is extremely secure) you want to make sure no code is being downloaded. Binary code (EXE, DLL, JAR) is the largest risk, but scripting languages such as Python with access to system functions are also a problem.
If the autoupdater downloads arbitrary filetypes, it could be possible to install a second EXE or other runnable file such as JAR to the game folder which ends up getting executed through the user's confusion or some other means. Do not overlook these risks.
I make a point of fussing about this stuff on a regular basis because it's important. Like, really damn important. Games are capable of a lower ratio of programmer experience to software desirability than anything and are a really easy target for attacks like this. When they do occur, people are that much less trusting of indie games as a result. So consider nixing your autoupdating or outsourcing it to a proven, secure platform like Steam, Desura, Adobe Air or the like. Unlike you (or me!) they know how to do this stuff right.
This is both true and depressing me more each time I think about it because the game I'm making relies on updating regularly the game content with binaries. I think it would be ok to just ask the user to update the software himself, as I plan to provide updates every 3-4 months aproximatively, but it feels less than idea. As I can't rely on Steam for example, I think I'll be forced to do this for now, as I don't have skills or money to pay someone with skills to make the updater and server very secure.
|
|
|
|
|
337
|
Developer / Technical / Re: The grumpy old programmer room
|
on: March 03, 2013, 06:21:35 AM
|
Outside some exercises from Project Euler and other very tiny bits of code I tested into online compilers, I spent the last few weeks working on migrating one of my project to github and writing documentation. What's hard about migrating to Github? Clone the repo and copy over all the code... Unless of course you want to retain all the commit history. But then it should be as easy as adding a new remote (Github) to your existing Git repo and pushing everything to it. Indeed cloning a repo to github is not hard nor slow at all, but that's not the whole story of my project's migration which is really a complex set of projects working together. Making sure all the doc is correctly accessible, visible, organized as you need it to be just takes a lot of time. Also, importing issues and linking things together. The work for this migration also involved splitting a big mercurial repo into several smaller git ones (so to simplify I didn't even tried to convert history, it's ok for now), setting up correctly a super-repo (using subrepos), updating some of the documentation which were wrong now (this takes a lot of time because you have to read all the doc and rewrite some parts), changing the documentation formatting to markdown (which I could have avoided but I wanted a more generic syntax for docs so it was the right time to do it) - knowing that there are tons of wiki doc; setting up a dev website front, which means still more doc to write; updating cmake scripts so that each project can work independently (not totally ok yet BTW) etc. and other little operations that added together just take time. There are still work to be done which are not directly related to the migration, like the current website texts are no good (too big, too confusing) so I'm almost finished redacting new simpler and understandable texts; then I will have to redact some new documentation that are missing for people to start getting involved into helping, including a file format specification that is not "easy" to write at all; and another more human-readable explanation of this format which would be like a big illustrated tutorial. Also, UI design documents (which I guess I'll make just by scanning drawings or making drawing in photoshop) Once I've done all that, I still need to fix some bugs in one of the most important sub project, then work hard to get an alpha out so that people can start to see where I'm going exactly and start contributing. So, to sum up, it's not a simple project, it's complex, needs tons of docs for people to help on it and as I'm alone on it and I still have a game to work on it's taking a lot of time to do all this. Fortunately I spent the last weeks full time on this, so it went faster than it should have, even if I was stuck to bed several days because from sickness. But yeah, just migrating a repo into github really was the easy and quick part. I wish I wasn't alone on this v__v;
|
|
|
|
|
338
|
Developer / Technical / Re: The grumpy old programmer room
|
on: March 03, 2013, 04:58:06 AM
|
|
Outside some exercises from Project Euler and other very tiny bits of code I tested into online compilers, I spent the last few weeks working on migrating one of my project to github and writing documentation.
So I'm grumpy because I want to get back to code ;__;
|
|
|
|
|
339
|
Community / Townhall / Re: Art Of Sequence (Digital Comics Toolset)
|
on: March 01, 2013, 10:27:42 AM
|
Why it take so long to be released ?
Because it's not 1 project but 8, with different programming languages and opposite purposes. (note that 3 of the projects first versions have been released already, see the previous messages - if you're talking about the editor, then remember that the other projects need to be done first) And the team is only me, not full time. Also, it's apparently really "bleeding-edge" way of thinking, so not everybody understand what it is. You should pick a team sometimes.
It's an open source project, anyone can help if he wants. It's not me not picking a team, there is not team to be picked, unfortunately. There are some people in the mailing list that are getting interested in it (a forum will be setup soon). If you know people who wants to help, be my guess and point them to the project. If they have questions, just give them my contact or point them somewhere I'm looking at.
|
|
|
|
|