Gaming

Holiday gaming competition with Mozilla and Goo Technologies

The web has come a long way, and especially lately it is amazing what great opportunities this means for game creators. To use open technologies to reach as many users as possible across multiple web browsers and platforms.

Looking at what WebGL, Web Audio API, Emscripten, asm.js and more have brought to the table, and what we’ve covered in articles here on Mozilla Hacks about gaming, WebGL, Audio etc, we are very excited to see the progress for gaming on the web.

Thinking about all this, we wanted to find an interesting way to encourage you to see what kind of games you could create! Together with Goo Technologies, we’re bringing you Goo’s Game Creator Challenge.

You will be using the Goo platform to create your games, which consists of:

  • Goo Engine – a 3D JavaScript gaming engine entirely built on WebGL/HTML5
  • Goo Create – a visual editing tool running on top of the engine

Categories

There are three different categories you can enter in:

  • Best Amateur Interactive Game Scene – Create a visually stunning interactive game scene using only the built in object primitives (simple 3D shapes, such as cubes, spheres, and so forth, that can be manipulated and combined together to create characters or other objects in a scene). This category is for those with little to no previous experience of game creation.
  • Best Desktop Game – Create an immersive game level for the desktop browser using Goo Create in combination with the Goo Engine JavaScript API.
  • Best Mobile Game – Create an immersive game level for the mobile Web using Goo Create in combination with Goo Engine JavaScript API – extra credit will be awarded for cross-platform games that also work on desktop.

Getting started

If you need inspiration to get started, a good place to start is Build an interactive scene in Goo Create or look at the Creating a Goon in Goo Create video:

Other good resources are:

Also, if you need help, you can go to the forums for Goo Technologies.

Prizes

As with any challenge, there are prizes! For the people entering the Best Amateur Interactive Game Scene category, the top 5 contributions will win:

  • $1,000 in cash
  • 5 year access to Goo Create Pro ($2900 value)

For the Best Desktop Game and Best Mobile Game categories, the prizes are:

  • A trip for two people to the GDC Conference in San Francisco, scheduled for March 17 – 21, 2014 or to GamesCom in Cologne, August 13-17 (maximum value $10,000) or $5,000 cash, at the winner’s option.
  • 5 year access to Goo Create Pro ($2900 value)
  • Guest post on the Mozilla Apps blog

Judges

Judging the challenge are people from Rovio (know for Angry Birds and more), Mozilla (Brendan Eich, CTO and inventor of JavaScript, Vlad Vukicevic, Engineering Director and inventor of WebGL) and Goo Technologies (Rikard Herlitz, CTO). They will pick the winners by January 17th.

Deadline for entry

Deadline for submitting entries is Tuesday, January 14 at midnight PT. Submit your entry by sending the url of your finished scene or game to mozgoocreate@mozilla.com.

For more information:

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Fast retro gaming on mobile

Emulation is the cool technique that makes retro gaming possible, i.e. play old video games on modern devices. It allows pixel lovers to revive gaming experiences from the past. In this article we will demonstrate that the web platform is suitable for emulation, even on mobile where by definition everything is limited.

Emulation is a challenge

Emulation consists of recreating all the internals of a game console in JavaScript. The original CPU and its functions are totally reimplemented. It communicates with both video and sound units whilst listening to the gamepad inputs.

Traditionally, emulators are built as native apps, but the web stack is equally powerful, provided the right techniques are used. On web based OSes, like Firefox OS, the only way to do retro gaming is to use HTML and JavaScript.

Emulators are resource intensive applications. Running them on mobile is definitely a challenge. Even more so that Firefox OS is designed to power low-end devices where computational resources are further limited. But fear not because techniques are available to make full speed retro gaming a reality on our beloved handhelds.

In the beginning was the ROM

Video game emulation starts with ROM image files (ROM files for short). A ROM file is the representation of a game cartridge chip obtained through a process called dumping. In most video game systems, a ROM file is a single binary file containing all aspects of the game, including:

  • The logic (player movements, enemies’ artificial intelligence, level designs…)
  • The characters and backgrounds sprite
  • The music

Let’s now consider the Sega Master System and Game Gear consoles. Take the homebrew game Blockhead as an example and examine the beginning of the file:

0xF3 0xED 0×56 0xC3 0x6F 0×00 0x3F 0×00 0x7D 0xD3 0xBF 0x7C 0xD3 0xBF 0xC9 0×00
0x7B 0xD3 0xBF 0x7A 0xD3 0xBF 0xC9 0×00 0xC9 0×70 0×72 0x6F 0×70 0×70 0×79 0×00
0xC9 0×00 0×00 0×00 0×00 0×00 0×00 0×00 0xC9 0×62 0x6C 0x6F 0×63 0x6B 0×68 0×65

The elements listed above are mixed together in the ROM. The difficulty consists of telling apart the different bytes:

  • opcodes (for operation code, they are CPU instructions, similar to basic JavaScript functions)
  • operands (think of it as parameters passed to opcodes)
  • data (for example, the sprites used by the game)

If we highlight these elements differently according to their types, this is what we get:

0xF3 0xED 0×56 0xC3 0x6F 0×00 0x3F 0×00 0x7D 0xD3 0xBF 0x7C 0xD3 0xBF 0xC9 0×00
0x7B 0xD3 0xBF 0x7A 0xD3 0xBF 0xC9 0×00 0xC9 0×70 0×72 0x6F 0×70 0×70 0×79 0×00
0xC9 0×00 0×00 0×00 0×00 0×00 0×00 0×00 0xC9 0×62 0x6C 0x6F 0×63 0x6B 0×68 0×65
Caption
Opcode Operand Data

Start small with an interpreter

Let’s start playing this ROM, one instruction at a time. First we put the binary content into an ArrayBuffer (you can use XMLHttpRequest or the File API for that). As we need to access data in different types, like 8 or 16 bit integers, the easiest way is to pass this buffer to a DataView.

In Master System, the entry point is the instruction located at index 0. We create a variable called pc for program counter and set it to 0. It will keep a track of the location of the current instruction. We then read the 8 bit unsigned integer located at the current position of pc and place it into a variable called opcode. The instruction associated to this opcode will be executed. From there, we just repeat the process.

var rom = new DataView(romBuffer);
 
var pc = 0x0000;
while (true) {
  var opcode = rom.getUint8(pc++);
  switch(opcode) {
    // ... more to come here!
  }
}

For example, the 3rd instruction, located at index 3, has value 0xC3. It matches opcode `JP (nn)` (JP stands for jump). A jump transfers the execution of the program to somewhere else in the ROM. In terms of logic, that means update the value of pc. The target address is the operand. We simply read the next 2 bytes as a 16 bit unsigned integer (0x006F in this case). Let’s put it all together:

var rom = new DataView(romBuffer);
 
var pc = 0x0000;
while (true) {
  var opcode = rom.getUint8(pc++);
  switch(opcode) {
    case 0xC3:
      // Code for opcode 0xC3 `JP (nn)`.
      pc = rom.getUint16(pc);
      break;
    case 0xED:
      // @todo Write code for opcode 0xED 0x56 `IM 1`.
      break;
    case 0xF3:
      // @todo Write code for opcode 0xF3 `DI`.
      break;
  }
}

Of course, for the sake of simplicity, many details are omitted here.

Emulators working this way are called interpreters. They are relatively easy to develop, but the fetch/decode/execute loop adds significant overhead.

Recompilation, the secret to full speed

Interpreters are just a first step to fast emulation, using them ensures everything else is working: video, sound, and controllers. Interpreters can be fast enough on desktop, but are definitely too slow on mobile and drain battery.

Let’s step back a second and examine the code above. Wouldn’t it be great if we could generate JavaScript code to mimic the logic? We know that when pc equals 0×0000, the next 3 instructions will always be executed one after another, until the jump is reached.

In other words, we want something like this:

var blocks = {
  0x0000: function() {
    // @todo Write code for opcode 0xF3 `DI`.
    // @todo Write code for opcode 0xED 0x56 `IM 1`.
    // Code for opcode 0xC3 `JP (nn)`.
    this.pc = 0x006F;
  },
  0x006F: function() {
    // @todo Write code for this opcode...
  }
};
pc = 0x0000;
while (true) {
  blocks[pc]();
}

This technique is called recompilation.

The reason why it is fast is because each opcode and operand is only read once when the JavaScript code is compiled. It is then easier for the JavaScript VM to optimise the generated code.

Recompilation is said to be static when it uses static analysis to generate code. On the other hand, dynamic recompilation creates new JavaScript functions at runtime.

In jsSMS, the emulator in which I implemented these techniques, the recompiler is made of 4 components:

  • Parser: determines what part of the ROM is opcode, operand and data
  • Analyser: groups instructions into blocks (e.g. a jump instruction closes a block and open a new one) and output an AST (abstract syntax tree)
  • Optimiser: apply several passes to make the code even faster
  • Generator: convert the AST to JavaScript code

Generating functions on the fly can take time. That’s why one of the approaches is to use static recompilation and generate as much JavaScript code as possible before the game even starts. Then, because static recompilation is limited, whenever we find unparsed instructions at runtime, we generate new functions as the game is being played.

So it is faster, but how faster?

According to the benchmarks I ran on mobile, recompilers are about 3-4 times faster than interpreters.

Here are some benchmarks on different browser / device pairs:

  • Firefox OS v.1.1 Keon
  • Firefox OS v.1.1 Peak
  • Firefox 24 Samsung Galaxy S II
  • Firefox 24 LG Nexus 4

Optimisation considerations

When developing jsSMS, I applied many optimisations. Of course, the first thing was to implement the improvements suggested by this article about games for Firefox OS.

Before being more specific, keep in mind that emulators are a very particular type of gaming app. They have a limited number of variables and objects. This architecture is static, limited and as such is easy to optimise for performance.

Use typed arrays wherever possible

Resources of old consoles are limited and most concepts can be mapped to typed arrays (stack, screen data, sound buffer…). Using such arrays makes it easier for the VM to optimise.

Use dense arrays

A dense array is an array without holes. The most usual way is to set the length at creation and fill it with default values. Of course it doesn’t apply to arrays with unknown or variable size.

// Create an array of 255 items and prefill it with empty strings.
var denseArray = new Array(255);
for (var i = 0; i < 255; i++) {
  denseArray[i] = '';
}

Variables should be type stable

The type inferrer of the JavaScript VM tags variables with their type and uses this information to apply optimisations. You can help it by not changing the types of variables as the game runs. This implies the following consequences:

  • Set a default value at declaration. ‘var a = 0;` instead of `var a;` Otherwise, the VM considers that the variable can be either number or undefined.
  • Avoid recycling a variable for different types. E.g. number then string.
  • Make Boolean variables real Boolean. Avoid truthy or falsey values and use `!!` or `Boolean()` to coerce.

Some syntaxes are ambiguous to the VM. For example, the following code was tagged as unknown arithmetic type by SpiderMonkey:

pc += d < 128 ? d : d - 256;

A simple fix was to rewrite this to:

if (d >= 128) {
  d = d - 256;
}
pc += d;

Keep numeric types stable

SpiderMonkey stores all JavaScript numeric values differently depending on what they look like. It tries to map numbers to internal types (like u32 or float). The implication of this is that maintaining the same underlying type is very likely to help the VM.

To target these type changes, I used to use JIT inspector, an extension for Firefox that exposes some internals of SpiderMonkey. However, it is not compatible with the latest versions of Firefox and no longer produce a useful output. There is a bug to follow the issue, but don’t expect any changes soon: https://bugzilla.mozilla.org/show_bug.cgi?id=861069.

… and as usual profile and optimise

Using a JavaScript profiler will help you in finding the most frequently called functions. These are the ones you should focus on and optimise first.

Digging deeper in code

If you want to learn more about mobile emulation and recompilation, have a look at this talk in which the slides are actually a ROM running inside the emulator!

Conclusion

Mobile emulation shows how fast the web platform is, even on low-end devices. Using the right techniques and applying optimisations allows your games to run smoothly and at full speed. The documentation about emulation on the browser is scarce on the net, specially using modern JavaScript APIs. May this article address this lack.

There are so many video game consoles and so few web based emulators, so now, enough with the theory, and let’s start making apps for the sake of retro gaming!

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

The Game On Competition – using the web as an open gaming platform

Interested in creating games? Are you a designer or developer? Then let me tell you more about the Game On competition from Mozilla!

What it’s about

As I’m sure you know, we at Mozilla say that The web is the platform because we believe that everyone gains from open technologies. Naturally this applies to games too, and we’ve talked about it before in Mozilla and Games: Pushing the Limits of What’s Possible.

As the tagline for the competition says:

Show what’s possible using the web as an open gaming platform for the world.

The Game On competition comprises of three different categories:

  • Hackable Games
  • Multi-Device Games
  • Web-Only Games

We are looking for what you can do, and how you can create gaming experiences that push the limits of what Open Web technologies can do!

Prizes

As if creating good games for the Open Web isn’t enough, there are also prizes!

  • An all-expense paid, red carpet trip to San Francisco for GDC 2013.
  • The chance to have your game featured in the Firefox Marketplace
  • The opportunity to show your game to the awesome folks at Chillingo for potential publishing on their network
  • One year membership to top industry associations IGDA and UKIE
  • Promotion of your game in the Game On Gallery and across Mozilla networks
  • Plus special edition Mozilla swag

Submit a game!

If you are looking for team members or inspiration, there are game jams taking place in New York and London, or you can create your own game jam.

The deadline for submissions is Feb 24, 2013, so what are you waiting for? 🙂

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

One reason why HTML5 gaming is limping along

TD;TR: Converting games to HTML5 is hurting the cause. We need more games written in web technologies.

OK, I might be a bit late to the party but the latest “web version” of Angry Birds, “subtly” advertising this time not itself but Wonderful Pistachios was the talk of the day on some of my mailing lists.

The main thing was that it requires Chrome to run. This is nothing new, but I really enjoyed the ingenious way of testing for Chrome in the first place:

if (Modernizr.testProp('-webkit-box-shadow')) {

So the box shadow (which will soon be deprecated with the vendor prefix in Chrome) is the main identifier. Not bad. So let’s hack around the detection with:

var l = document.createElement('link');l.rel = 'stylesheet';
l.href = 'http://wac.5DC0.edgecastcdn.net/805DC0/site/static/css/style.css';
document.getElementsByTagName('head')[0].appendChild(l);
GetCrackin.init();

Which leads us to a JSP file that detects on the server side and writes out a lot of inline webkit only code OK, never mind.

I am less annoyed that this is Chrome only. It was never claimed that this game runs everywhere (other than the Angry Birds released on Google IO). I am more annoyed about the bad performance the game has in Chrome and Safari on this Macbook Air. And I know the reason for this: conversion instead of dedicated development.

A look back in time – games on Commodore 64

As I have mentioned before, I used to work on some games on Commodore 64. In its heyday there was no way to have a game without writing it by hand – in assembly language and knowing what all the chips do. Perusing the memory map and the ROM allocations was part of the game of writing one.

When computers got more ubiquitous and better in terms of sound and graphics a lot of companies started building games on the other machines first – Amiga mostly. And to make extra money and sell even more copies, they also made C64 versions as conversions afterwards. These were most of the time shoddy at best and weren’t tested much. The C64 was the machine that is not where the money was made – the new hardware was the one to support.

The thing that got lost – and later on even more so – was the tinkering with the hardware and finding tricks to work around limitations. Out of the box the C64 had 8 sprites and a resolution of 160×200 pixels in 16 colours or 320×200 in 2 colours per 8×8 pixels. Using interrupts (executing code whilst the screen was painted by the TV or monitor) people came up with multiplexers that allowed for hundreds of sprites. With overlaying techniques we produced 256 colors at a interlaced 640 pixel resolution and so on.

A few of those tricks made it into the conversion tools from the “higher” computers to C64 code, but most were deemed to costly and time consuming and didn’t make sense to do any longer.

HTML5 gaming without the web stack?

This is happening now with “HTML5” games, too. Angry Birds is done with Google Web Toolkit, converted from Java I presume. It is made to work quickly and not show off what a web game can do, but instead how easy it can be to convert a game from Java to the “web”. And when that fails to bring the results it should, then we limit the web to one browser. And even fail at that as Angry Birds – in this case created to promote Chrome as a HTML5/games platform – doesn’t work on my Chrome book – the hardware dedicated to the browser.

Seeing this makes me frustrated, and it causes a lot of sniggering up to outright laughter from the Flash community. And they have all the right to. Flash games perform well, and showed that they can be easily changed and rebranded and extended when you build them the right way.

The HTML5 game engine vanishing act

Of course there are great minds on the case already and a lot of people build great demos and JavaScript frameworks to build HTML5 games in the technology rather than converting to it. The interesting thing about that is that every games engine released open source very quickly gets bought and un-opensourced and then vanishes from sight. The optimist in me thinks that this means there is great stuff afoot. The cynic in me sees the talent behind and the engines rotting away in a corporate environment as they were seen as a threat instead of an opportunity.

What HTML5 gaming needs to impress

I would love to see more real web games. Built in open technologies, with source available (or not, this is a nice to have) and really using the web. A web version of Angry Birds to me wouldn’t have a very long loader and ask me to sign in to Google to use it. It would be snappy and load the levels on demand, storing the ones I played and the next one locally in my browser while I am playing the current one. It would also allow me to build my own levels and share them on Twitter to see if I can build awesome stuff in the game that other people enjoy. All of this would be a total pain to make work on a mobile and a 3G connection, but is very much fine in a browser on a laptop with a good connection.

In other words, HTML5 games should be fit for the environment and use it to its strengths.

What about WebGL?

WebGL is an awesome opportunity for game developers to get into web gaming without needing to learn a new skillset. It is pretty obvious that an openGL developer could take it up much easier than a web developer would. Right now, WebGL is great for demos, but we have the issue of hardware access. If the biggest sound of the game is the fan of your processor and video card then this diminishes the experience. I for one never started gaming on PC as every new game coming out told me I need to buy new hardware in order to play it. This is not what I could afford. And this is not what we should force onto people on the web. A web app saying I need a certain browser or that my video card is not good enough to use it is not much better than the old “best viewed in IE4 with 800×600 pixels”.

We should think less World Of Warcraft and more Doodle Jump when it comes to HTML5 gaming.

Maybe I am a dreamer, and this is so not how the games market works. That is fine, though. A new market could emerge that takes the best of offline gaming and online experiences. But, we need to make that happen.


View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Ask MDN follow-up: HTML5 Gaming & Creative JavaScript

Just over a week ago we gathered 8 experts in the field to answer your questions about HTML5 gaming and creative JavaScript. This was our first Ask MDN event and, although it had a couple of teething problems, it went really well.

In this post I want to follow up on the previous event and outline our plans for the future, taking into consideration all the lessons that we’ve learnt so far.

Thanking the developer community

Without you the first Ask MDN would have been completely pointless, so I’d like to thank those who submitted questions and took part in the discussion. You keep our experts on their toes and sparked some great conversations on Twitter.

We were actually a little overwhelmed with the amount of questions coming in, so we’re sorry for not answering them all. It’s one of the things we want to improve on, which you can see in the section further on on this post.

Thanking the experts

Our intrepid group of experts did a fantastic job at answering the questions as they came in. I’d particulary like to thank them for their patience as we dealt with changes in procedure during the event.

Find out more about our experts:

Learning from our mistakes

We learnt a lot from the first event, so much so that we’re taking steps to make sure we don’t repeat the same mistakes. Here are just a few of them.

Tweaking the format

Originally we wanted Ask MDN to be a weekly event, and we still do, but we’ve decided to move to a bi-weekly format for the near-future. This will allow us more time to work on the other issues we encountered, with the ultimate aim of making the event even more awesome.

We’ll move to a weekly format once we’ve got everything working how we’d like. It shouldn’t be too long.

Archiving the event

We’re going to start archiving each event ourselves, but in the meantime you can check out this great transcript from Andrzej Mazur. Thank you!

Tracking the live conversation

Related to the archival of the event is tracking the conversation on Twitter as it happens live. We noticed that a lot of people were finding it hard to know which questions were being answered, particularly as there were often more than one question being answered at a time.

We plan to make the conversation on Twitter easy to follow with a dedicated Ask MDN dashboard website. This will aggregate all the information you need to know about the conversation; like the current questions and their hashtags, answers to each question displayed in a threaded format, the ability to submit questions directly, and more!

Cutting redtape

Originally we thought that a solid procedure for answering questions would be best. This was wrong and it meant that more time was being spent delegating questions to experts and waiting around than actually answering questions.

In the future we plan to relax the procedure and allow the experts to answer any question they want at any time within the hour.

Dealing with unanswered questions

Something we hadn’t thought about was what to do with all the questions that didn’t get answered during the hour. In the future we will be posting these all online, probably on the dashboard, for experts and the community to answer at a later date.

Have feedback?

We’re doing this for you, so please let us know if you have any feedback about how Ask MDN could be better. Leave a comment below and we’ll consider them all as we evolve the event in the future.

Next up: The History API

This Friday we’re convering the History API, which is also the focus of this month’s Dev Derby.

We’re now open for questions, so send them to us now on Twitter or use the the #askmdn hashtag.

This event will occur at the following times around the world:

  • 10am in San Francisco (PDT)
  • 1pm in New York (EDT)
  • 7pm in Paris, Berlin and Madrid (CEST)

Find the time where you live to make sure you don’t miss out.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

7 in 10 Smartphone and Tablet Users Pay Attention to Mobile Ads When Surfing Web, But Not When Gaming or Watching TV …

A recent mobile survey conducted by Prosper Mobile Insights™ included 203 smartphone and tablet users from the SSI Panel who completed the survey on their devices. The survey was collected from 7/20 – 7/22/11. 48% of the sample was male while 52% was female, and the average age of the sample was 40. The data reveals that mobile users’ attention spans for advertisements viewed on their devices …

View full post on web development – Yahoo! News Search Results

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Test Opportunities with Mobile and Gaming Applications

WA-Bellevue,   ·   Responsible for executing daily self-host test coverage including manual and automated test cases. ·   Required to debug scripts and .Net test automation and perform first-level analysis and log bugs based on findings. ·   Perform ad-hoc testing on phone and gaming systems. ·   Reproduce and validate bug reports filed during Beta testing. ·   C# automation, command scripting and HTML/Javascr View full post on Monster Job Search Results (mobile)

View full post on WebProJobs.org

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Lead Architect – Growing Mobile Gaming Company

CA-San Mateo, Lead Architect – Amazon Cloud Services – Ec2 – RDS – S3 – PHP – LAMP – MySQL – Relational Database Design – Startup – Leading Mobile Gaming Company We are a rapidly growing and successful mobile gaming development company with a proven track record. If you are extremely passionate about games (frequently find yourself browsing gaming industry news sites) and want to contribute to a dynamic and ene View full post on Monster Job Search Results (mobile)

View full post on WebProJobs.org

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Web Designer for Mobile Gaming Company

CA-San Jose, Job Title: Graphic/Web designer The Creative Group is looking for a marketing web designer to work with one of our mobile gaming companies. You should love games, illustration and have a terrific eye for design! Essential Duties and Responsibilities Execute design projects for games, media and entertainment partners Provide support to marketing, product management and business development Develop View full post on Monster Job Search Results (mobile)

View full post on WebProJobs.org

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

SW Engineer (hands-on director) – Gaming background

The Recruiting Spa Los Angeles, CA
Job description: …process. * Lead by example, able to roll up your sleeves and help developers in the code. * Work closely with Marketing, Sales and Product in order to integrate their needs into our development. * Help build an open, positive, and energized… View full post on Dice.com – Web Marketing

View full post on WebProJobs.org

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)