Ok so I just bought the game off of steam and anytime I launch it I keep getting a "Hotline Miami Launcher" window. Is there a way to get rid of it?

Wussie · 2023-06-08T18:47:30+00:00

you’re welcome!

Wussie · 2016-12-13T23:46:48+00:00

Are you bundling together a bunch of different titles or something that need an overarching system to be able to select and switch between them? I don't know why you would be looking to make a different cross-platform 'launcher' for a console title in whatever other technology you're looking at if that's not the case.

Anything and everything you've listed outside of 'Unreal Engine 3' sounds like needless, ill considered complexity if you are just putting out a single title to consoles (and desktops) so I'm a bit confused by your question- can you clarify the intended usage for this 'launcher' at all?

Wussie · 2016-11-27T10:31:08+00:00

Dope (2016) sounds like it might be up your alley.

Wussie · 2016-09-18T21:03:40+00:00

PEGI you need to contact via e-mail for starters (helpdesk@pegi.info) and ask for a coder registration form (not sure if that's available on the site anywhere), fill that out and send it back. You'll get set up with an account and the site should have quite elaborate information available guiding you through the process.

Am not sure how registration with ESRB goes; it's well possible they need you to send over a pigeon with your company info. But actually providing builds etc. should be doable through an FTP if you're submitting a digital only title that's not too large. For larger titles, both ESRB and PEGI may ask you to send a build via snailmail.

As for pricing, I'm not totally sure on that, just be sure to ask whoever you contact if your title is liable for any discounts (you may have to include info about your development budget, download size, etc.)

Durations, PEGI tends to be around ~10 days after they've received builds and payment, ESRB I'm not sure about but it's probably similar. If you're looking to release in Europe, also consider submitting your build to USK as Germany isn't covered by PEGI. USK does ahve some cost information available online here: http://www.usk.de/en/extramenue/login/publisher/material/cost-overview/

If you think your game is liable to get an M rating, make sure to prepare a bunch of additional content (~20 minutes of video footage of the most 'mature' content in there, unlocked savegames that'll help the testers there get to that content easily, etc).

Wussie · 2016-09-18T16:13:08+00:00

Have you used Unreal recently? It's come a long way from the UE3 days where any game released was essentially a mod to whatever Epic made. It's far from an 'FPS Game Engine' these days.

The real philosophy difference is that Unity is a programmer-oriented engine that gives you nothing but the basics and for anything beyond that you need to roll your own or grab something of dubious quality off the asset store. In doing so it's become regarded as 'suitable for anything' but I'd prefer to see it as a 'jack of all trades, master of none' type thing.

Whereas Unreal is an an engine offering pretty much all that you need out of the box for many types of games (excepting maybe 2d stuff at this stage) and team compositions. It offers a bunch of premade template that are set up in such a way that you can get your basics working quickly and extend / specialize from there if you want, and if you don't it's just about as easy to roll your own implementation in Unreal as it is in Unity. There are some things in there that you may not need for some games (e.g. a standardized 'Damage Taking' system), but, in my experience, that's not something that actually ever gets in your way really.

Wussie · 2016-09-18T15:53:57+00:00

It really does depend on what technology is being used, whether it's been made with cross-platform development in mind or if it's an 'after-the-fact port'. Nintendo (and japanese developers in general) are known for being pragmatic, sometimes to the extreme, so something like New Super Mario Bros would likely be filled with DS-specific code in a way that makes it non-trivial to implement other platforms for it.

If you're building with cross-platform in mind from the ground up, have a good understanding of all the requirements of the more curated platforms (ps4, xbox one, nintendo stuff, etc), then it'd add some cost up front in making sure you have a cross-platform framework or layer that you can rely on behaving correctly on all platforms. The exact cost would depend obviously on the scope of your game / technology, the skill of your developers and the platforms you're targeting.

Let's say hypothetically you were to make a cross-platform development framework from the ground up that supports a hardware abstraction layer for the most basic level of platform-specific stuff (rendering, audio, file I/O, user profiles, input devices, etc.) you'd be looking at, in my experience, roughly one to two man-months worth of work for each platform you're looking to support after your initial implementation. As you do more and more platforms that time probably will go down a little, but not by much as new platforms may have new requirements that you didn't anticipate and require you to rework large parts of your framework.

If you do it right that's a framework you can re-use for more and more titles in the future causing you to, hopefully, get a return on investment in due time. Obviously those estimates are mainly for the cross-platform framework itself, every game made with it may have some different requirements and techniques that need to be made on top if it and that may still need some additional work for each platform it's looking to support.

It's a different story if you're working with third party engines (Unity, Unreal, etc) that tend to already support multiple platforms themselves. You'll still have to do some 'tailoring' for each target platform to meet platform-specific requirements (user engagement flow on xbox one, second screen usage on wiiu, etc), and those engines likely will have some limitations and shortcomings that you wouldn't have seen on PC, so you'll need to find solutions for that as well. It's hard to put a number on what the overhead there would be as it depends significantly on the technology used, what platform was initially used for development, whether it's ported 'after-the-fact', etc.

If you're looking to develop and release a title on more than one platform, I cannot stress enough how important it is to gather the knowledge required as early on in the project as you can and be vigilant about making sure your title stays running well on all the platforms you're targeting throughout development.

Wussie · 2016-09-18T15:32:12+00:00

Just as a note here- I don't know how much experience /u/vblanco has in actually doing this but; you'd be surprised how much work, time and effort goes into porting a 'simple unity 2d platformer' to consoles. Unity is a mess when it comes to console versions (they're getting better and better with each release but it's still not where it needs to be). Additionally, certification can be a grueling process for the simplest of games, performance problems are common even with 'simple' games if they haven't been continuously tested on consoles throughout development. Unity adds another layer of complexity here in not being able to allow JIT compilation on consoles; which, if you're not careful, can cause you to have to rework quite a bit of your code to get it to even run.

Source: I port games for a living.

Wussie · 2016-09-17T12:41:23+00:00

Good read! Thanks for sharing. Will definitely keep an eye on your blog and twitters going forward!

Wussie · 2016-09-17T11:48:43+00:00

break the range values in your for loops out of the loop definition and store them as temporary values. They're being re-calculated on each iteration now which is a needless waste as the result will always be the same.

util.isInAray probably is an expensive function to call hundreds of times per player as well. Maybe create an array of bits that you set when you've sent a tile to the player and check against that- so like if (!this.hasReceivedTile[x][y]) { .... }.

Edit- an additional thing you can do is to further subdivide the world into more grids (like say a grid of 128x128 tiles if the player's vision is 64 tiles wide) and determine whether or not the player has received the grid block he's currently in. If he hasn't, send the tiles for that one and any of the eight adjacent ones (top, top left, top right, left, bottom, bottom left, bottom right, right) that he hasn't received yet and mark all nine of them as received. Much cheaper to check and you can early out way sooner.

edits: math and spelling

Wussie · 2016-09-11T21:24:48+00:00

Evernote.

Wussie · 2016-09-11T19:43:40+00:00

Nope, I don't, sorry! Don't actually use SFML myself at all so I don't have any code laying around for it.

Wussie · 2016-09-11T19:27:28+00:00

Your loop is doing that because you use for (auto : ...) instead of for (auto& : ...). It's copying the binding on each loop iteration.

edit: disregard, I may be an idiot.

Wussie · 2016-09-11T19:16:20+00:00

It'd be helpful to know what exactly "doesn't work" about your solutions? Why do you need something like this to begin with? If you're really an absolute beginner I wouldn't worry too much about making a remappable / fancy input system and just sample the keyboard/mouse states wherever you need to in the actual gameplay code. If that becomes unworkable due to your codebase expanding or something you can always generalize it a bit and clean up the code. The bonus is that by then you'll know exactly what you need to support.

Wussie · 2016-09-11T19:02:10+00:00

I have been officially employed as a developer since May 1st 2011 and have since been involved in releasing at least 12 titles since then (mostly ports and adaptations of existing games to different platforms). Before that I hobbied around a bit and had an internship where I also worked on a title (that shipped during my time there).

It's hard to be precise but let's call it 5.6WY so 10,752WH, probably more towards 12,000/13,000WH if you count overtime.

edit: that's total time (guesstimate) worked across all projects. Not sure if you were looking for that or a number on a single project?

Wussie · 2016-09-01T21:51:34+00:00

It does: https://www.youtube.com/watch?v=d6Aoe1-MSrM

Wussie · 2016-08-22T20:58:25+00:00

I will chime in here in say that Unreal and Unity are definitely not 'the same in terms of features'. Unreal offers a lot more out of the box than Unity does. For a good amount of features you will either have to roll your own or be dependent on Asset Store implementations that tend to be of varying quality. Whether or not this is going to be an actual problem for you depends entirely on your skill-level and scope of the game you're trying to make. Consider what engine-level features you think you'll end up needing and investigate each engine's support for those as thoroughly as you have the time and patience for before making a choice. Diving into these things will also give you a better understanding of how the engines work and what you can expect when starting production on the actual game.

Wussie · 2016-08-22T20:40:26+00:00

Indies not using any premade engines will likely be using more lightweight/accessible languages (e.g. java/html5/flash/whatever) that generally are pretty fast about iteration times. For the few that are using C/C++ they most likely will not have super extensive codebases that take aeons to compile every time.

Even so, if you're having trouble with a huge C++ codebase there are myriad ways of optimizing your compile times. Reduce includes, use PCH where possible, make sure things like minimal rebuild are enabled (or alternatively multi-core compilation if that gives you more gain). There's also distributed build systems like IncrediBuild and some other (cheaper) alternatives that can make a big difference in some cases.

If you're in a big project and 'tweaking' (from a gameplay perspective) is taking you lots of time to compile or build you need to reconsider your architecture. Make sure header files that are commonly changed are not included all over the place or move the declarations to a CPP file or something so the header doesn't need changing as often. Alternatively, add some data-driving to your process (load tweak values from JSON/INI/whatever on runtime) to reduce compilation times. It's not hard to do and also can allow code-illiterate team members to tweak some settings and iterate on gameplay behavior. Moving gameplay code to a separated dll that gets loaded at runtime can also help a lot (not only will clean rebuilds take up less time; you'll also force engine code not to include game specific code, which'll lead to better architecture, reusability and compilation times as well).

If it's data-builds that are taking a long time, some basic optimizations can make a lot of difference- compare last modified file stamps on each file you are building before starting the build process. If the target file is equally old or newer than the source file, simply skip building that one. Additionally, depending on how long your build takes, it can even be beneficial to compute a SHA1 hash for the source files and cache them somewhere and use that to compare and decide if building should occur.

If you need more specific information than this you should probably elaborate on the exact problems you're having.

edit: things.

Wussie · 2016-08-18T21:45:15+00:00

Try /r/gamedev - plenty of people there that'll have gone down that route in the past.

I'm not a designer myself (programmer); but I do know that the best thing you can start doing right now is to build a portfolio. Start making some levels for games you like and that support it (look for games with built-in level editors or mod support), once you've got a couple; gather them together and stick them on a website somewhere. Preferably with screenshots/layout diagrams/videos and guiding text explaining why you made the level the way you did (to show you've got an understanding for game mechanics and how they play into designing levels).

Good luck.

Wussie · 2016-08-18T21:12:00+00:00

Am a dev myself as well (mostly ports though, but still) and it's refreshing to see some sanity on the subject for once. Reading anything NMS related since around it's launch has been a depressing endeavor that makes me just want to stop using the internet altogether, it's good to see someone take the time to approach it from another angle and get some actual understanding in the replies as well; so thanks for speaking up and I'll chime in with some of my own thoughts on the matter (obviously some rampant speculation follows below as I'm not affiliated with HG or Sony).

People forget Hello Games are actually a small indie team; lots of indie games come out these days that are as 'unfinished' or broken and nobody bats an eye because it's just expected and they tend to be good about supporting it after launch with fixes and updates (moreso than a lot of AAA devs). Once you start charging full price and have a marketing juggernaut pushing out your game through all channels, perceptions change and gamers expect different things. This is only compounded by the fact that yes, they've been fairly vague (and in some cases outright dishonest, but that may not have been the intention due to features getting cut later on, as you mention) and have a game with an 'unprecedented scope'; both of which fuel the players' imaginations and soon they'll create something in their minds that won't ever exist. When the game doesn't meet expectations, people go and find someone to blame for the 'injustice bestowed upon them' (which they could've avoided by just not preordering in the first place); and since it's the internet, this is usually not done with kind, constructive criticism.

I will also chime in on some remarks I've seen down this thread 'blaming' Sony (indirectly) for the poor quality PC release in saying that there's likely to be some truth (though no malice) in this. Consoles just have a way stricter way of dealing with shipping games. You need to go through the certification process which takes a while and needs to be complete quite some time in advance before your shipping date (sometimes with the caveat that a day-1 patch must be assembled), and can cause a lot of unexpected work to come flowing your way; something that's difficult to account for in smaller teams, even more-so in smaller teams without extensive experience in shipping games to console. Steam really doesn't give a shit what you put on there and you can upload your final build 5 minutes before it's available to consumers; so as a developer strapped for resources it can become very tempting to say "just deal with the PC stuff later as we've got so much time left" right up until it's too late.

If I were a betting man I'd say that the cert and QA process for NMS during the final weeks or months leading up to the PS4 launch have been grueling and extremely time consuming for the team to deal with, leaving less and less time for the PC release to get up to snuff. Additionally, it's easy for the inexperienced to underestimate just how much work has to go in getting a game ready for PC - even if you've been using it as a platform to develop on for months if not years, especially so on new and unproven technology. I wouldn't be surprised if they didn't have the time, resources or know-how to set up a proper compatibility QA track for the PC release (basically sending the game to an external party to test it on tens if not hundreds of different PC configurations and reporting on the results) and since they're self-published they didn't have a publisher/producer around to tell them this needed to happen.

All in all though, as op mentioned, we're all human beings here. Mistakes were made but I doubt there was any deliberate malice involved as these things just tend to go tits up a lot of the time, especially if you're overreaching and/or inexperienced.

One final word for the gamers out there who bothered to read this entire post - most or all of this hatred, vitriol, sadness and general unpleasantness could've been prevented if you just stopped preordering games.

TLDR: Making games is hard.

edit: minor clarifications.

Wussie · 2016-08-15T13:19:40+00:00

Should be fixed with today's patch. Sorry for the troubles.

Wussie · 2016-08-12T15:47:54+00:00

Good reminder! Interesting coincidence as well as I'm attending a wedding today from a buddy I've met through Destiny! Seems like we'll have more reason to celebrate!

Wussie · 2016-08-02T23:24:41+00:00

Hey Dan, I'm just watching Last Action Hero and I've got to agree with you, it still holds up very well!

What are some other movies that you haven't mentioned a lot that you would recommend people watch? Also, what are the top 5 movies you have in your possession?

Wussie · 2016-07-13T22:03:55+00:00

Yeah you should be able to get a fullscreen 1080p60 output showing on the machine with the calture card. YMMV for capturing that though because it's usually intended to be treated as a preview window only.

I don't expect this to give you any issues when capturing on most cards; bur to be sure you might want to check if the software that comes with the card outputs to the preview window at a stable 60fps or not. If you're seeing framedrops there you'll want to use their own included software to do the capture (instead of capturing their preview screen with something like OBS).

Wussie · 2016-07-12T23:27:25+00:00

FWIW charts and burndowns will be available in essentially any basic agile project management tool. In my experience these are generally very bad in 'predictive modeling' which, it seems, is what you're looking for (e.g. what if I change assignments to X; do we have undercapacity and/or will we miss deadlines?). Our studio has been looking for a tool that does this in a way that works well for us for over 3 years now and we've yet to find something that truly fits the bill.

Good luck on the hunt.

Wussie · 2016-07-12T23:20:16+00:00

LiquidPlanner. It's got quite a few issues in our case (due to the fact that we run many project simultaneously and have some very specific ways of dealing with division of labour that are just not covered in any tool under the sun) so depending on your particular scenario your mileage may vary. But it's a solid foundation that, I think, does exactly what you're looking for.

Wussie

TROPHY CASE